First question: is it a cache or a database?
| Use | Migration approach |
|---|---|
| Pure cache (can be rebuilt from the source of truth) | No data migration: point apps at the new cache and let it warm up (stagger the cut-over to avoid a thundering herd) |
| Sessions with short TTL | Dual-write for one TTL period, or accept users logging in again |
| Data you can't rebuild (queues, counters, leaderboards, primary data) | RDB import, or replicate/dual-write |
Many Redis migrations need no data copy at all.
1. Choose the target
| Need | Azure | AWS |
|---|---|---|
| Managed Redis with HA and zones | Azure Managed Redis (tiers by memory/compute) | ElastiCache (node-based or Serverless) |
| Redis modules (JSON, Search) | Azure Managed Redis (supported modules per tier) | Check ElastiCache support; Valkey-based features differ |
| Private networking | Private endpoint | VPC subnet group |
On Azure, new deployments should generally use Azure Managed Redis. Check Microsoft's current retirement schedule for Azure Cache for Redis tiers before building anything new on them.
Size memory for: dataset + replication/fragmentation overhead (plan ~25–30% headroom), and check ops/sec and connection limits per tier.
2. Clustering mode
Managed services often run clustered (sharded) Redis. Clients must be cluster-aware, and multi-key commands must hit keys in the same hash slot:
MGET user:1 user:2 -> may fail with CROSSSLOT in cluster mode
MGET {user}:1 {user}:2 -> same slot thanks to hash tag
Check for MULTI/EXEC, Lua scripts and multi-key commands across unrelated keys. Some managed options offer a non-clustered policy/proxy mode to avoid app changes; check what your chosen tier provides.
3. Move the data (when needed)
RDB export/import:
redis-cli -h old-redis --rdb /tmp/dump.rdb # take an RDB snapshot from the source
- Azure: upload the RDB to a blob container and use the cache's Import function (premium/enterprise-class tiers and Azure Managed Redis support import; check your tier).
- ElastiCache: put the RDB in S3 and create the cluster seeded from it (
--snapshot-arns).
This is a point-in-time copy. Writes after the snapshot are lost unless you freeze writes or dual-write.
Online tools: RIOT (Redis Input/Output Tools) can replicate live data between Redis endpoints, including key-by-key sync. Test it with your data types.
Dual-write: the app writes to both old and new for a period, reads from old; then switch reads to new; then stop writing to old.
4. Client changes
- TLS: managed services use TLS (port 6380 for Azure Cache for Redis, 10000 for Azure Managed Redis; check your endpoint). Update connection strings and enable TLS in the client.
- Authentication: Entra ID (Azure) or IAM auth / AUTH tokens (ElastiCache) instead of a shared password where possible.
- Cluster awareness: enable cluster mode in the client library.
- Timeouts and retries: managed services patch and fail over during maintenance windows; clients must reconnect.
5. Cut-over and check
- Watch hit rate (cache warm-up), latency, memory and evictions on the new service.
- Keep the old Redis running read-only for a short rollback period, then decommission VMs and Sentinel.
Warning
KEYS *and other O(N) commands that were "fine" on a small VM can block a busy managed shard. Replace withSCANbefore migrating.
Checklist
- Cache vs data decided per Redis instance
- Target tier, clustering mode and networking chosen
- Multi-key and cluster compatibility checked
- Data moved (RDB/RIOT/dual-write) where needed
- Clients on TLS, auth and cluster mode; retries tested