Azure Cache for Redis to Azure Managed Redis Planning — when and how should I migrate?
Decide whether to migrate to Azure Managed Redis, self-host Valkey, or move to another managed cache now that Azure has put legacy Azure Cache for Redis tiers on a retirement path.
Blockers
- requires_version: package/azure-managed-redis → runtime/redis-7-4
- package/azure-cache-for-redis — EOL 2027-04-01
- package/azure-cache-for-redis — EOL 2028-10-01
- Lock-in via vendor/azure
- Lock-in via vendor/azure
- Lock-in via vendor/azure
Who this is for
- low-ops
- enterprise
- cost-sensitive
- real-time
Candidates
Migrate now to Azure Managed Redis
Azure Managed Redis is GA, uses Redis 7.4, is clustered by default, and its pricing page exposes memory/performance SKUs such as B0-B1000, M10-M2000, X3-X700, and preview A250-A4500, but check official docs for current regional prices. Azure docs also state it supports all Redis functionality offered in existing Azure Cache for Redis SKUs, while noting some management operations, regions, and SKU sizes are not yet available.
When to choose
Use this when you want the Microsoft-supported path off the retirement schedule with the least platform churn. It is the default choice if your workload can accept clustered-by-default behavior, single database only, Private Link instead of VNet injection, and Azure Managed Redis port and hostname changes.
Tradeoffs
Best alignment with Azure's published migration guidance and retirement path. Tradeoffs are application changes for clustered clients, networking changes, single-database refactoring, and feature gaps where Azure says some management operations, regions, or SKU sizes are still unavailable.
Cautions
Blockers called out by Microsoft include clustered-by-default behavior, only database 0, no VNet injection or IP firewall rules, no Microsoft Entra ID RBAC yet, scheduled updates still in preview, different DNS suffix, and port 10000 instead of 6380/6379. Microsoft has already put all Azure Cache for Redis SKUs on a retirement path. As of 2026-04-01, creation of new Enterprise and Enterprise Flash caches is already blocked, and creation of new Basic, Standard, and Premium caches is already blocked for new customers; existing Basic, Standard, and Premium customers are blocked from creating new caches on 2026-10-01. If you are on Enterprise and do nothing, Azure says those caches are disabled starting 2027-04-01; if you are on Basic, Standard, or Premium and do nothing, remaining caches are disabled starting 2028-10-01.
Self-host Valkey
Valkey is an open source BSD-licensed key/value datastore backed by the Linux Foundation. As of 2026-04-01, the Valkey project homepage shows 9.0.3 as the current 9.x release, with 8.1.6 and 7.2.12 also listed as latest supported versions of past releases. Valkey documentation says it can run standalone or in a cluster, with replication and high availability options. Pricing is infrastructure-dependent, so check your VM, storage, and operations costs rather than expecting a managed-service list price.
When to choose
Use this when license posture and exit from vendor retirement risk matter more than low-ops convenience. It fits teams that can operate their own HA, patching, backups, failover, monitoring, and security controls.
Tradeoffs
BSD licensing and broad ecosystem momentum are the main advantages. The cost is that you own the operational surface that Azure Managed Redis or another managed provider would otherwise absorb.
Cautions
Do not treat this as a drop-in zero-ops replacement. You need your own design for persistence, clustering, failover, upgrades, observability, and private networking before migration.
Use another managed Valkey-compatible cache
If Azure Managed Redis has a blocker, the Valkey project site already lists managed offerings from vendors including AWS ElastiCache, Google Cloud Memorystore, Aiven, Oracle Cloud Infrastructure Cache, Heroku Key-Value Store, DigitalOcean Managed Caching, and Instaclustr. As of 2026-04-01, this is the fastest way to leave Azure's retirement path without taking on full self-hosting. Pricing and exact engine/version policy vary by provider, so check official vendor docs before committing. This option is mainly about avoiding Azure-specific migration blockers while keeping a managed operations model.
When to choose
Use this when Azure Managed Redis is blocked by region, SKU, networking, or feature gaps, but you still want a managed service instead of running the cache yourself. It is also the cleanest fallback if you want Valkey alignment specifically.
Tradeoffs
You keep a managed control plane and avoid self-host ops, but you add another vendor and must re-evaluate networking, SLA, auth, replication, and migration tooling from scratch.
Cautions
Do not assume compatibility details are identical across vendors. Validate cluster mode behavior, TLS defaults, private connectivity, failover model, module support, import or export path, and billing before migration.
Try with your AI agent
$ npm install -g pocketlantern $ pocketlantern init # Restart Claude Code, Cursor, or your MCP client, then ask: # "Azure Cache for Redis to Azure Managed Redis Planning — when and how should I migrate?"