In June 2022, I wrote about Azure Cache for Redis as Microsoft’s fully managed way to run Redis in Azure. That post remains a useful snapshot of the service at the time: choose a tier, obtain a connection string, point an application at the hosted cache, and let Microsoft manage the underlying infrastructure.
The core idea has not changed. Applications still benefit from placing frequently accessed data in memory to reduce latency and relieve pressure on databases and other back-end systems. The product direction, however, has changed significantly. Azure Cache for Redis is on a retirement path, and Azure Managed Redis is now Microsoft’s recommended destination for Redis workloads in Azure.
Azure Cache for Redis is being retired
Microsoft has published separate retirement timelines for the different Azure Cache for Redis tiers. Enterprise and Enterprise Flash instances retire on March 31, 2027, while Basic, Standard, and Premium instances retire on September 30, 2028. Microsoft says existing instances will continue to receive regular maintenance until their applicable retirement date, but recommends moving sooner rather than treating those dates as migration targets.
The distinction matters. An organization using an Enterprise cache has a much shorter runway than one using Basic, Standard, or Premium. The first task is therefore not simply “migrate Redis,” but to inventory every instance, record its tier, region, size, clustering policy, network configuration, authentication method, persistence settings, and dependencies. Microsoft’s retirement FAQ should be the source of truth as plans develop.
More than a new product name
Azure Managed Redis is based on Redis Enterprise software while preserving compatibility with Redis clients and familiar Redis usage patterns. Microsoft operates it as a native Azure service, and applications inside or outside Azure can use it. The familiar caching scenarios remain—data caching, content caching, and session storage—but the platform also supports broader Redis use cases such as message queuing, deduplication, leaderboards, transactions, analytics acceleration, and search.
The newer service brings capabilities that previously required the Enterprise side of the Azure Cache for Redis family, including Redis modules and active geo-replication. Microsoft also highlights zone redundancy by default and Microsoft Entra ID authentication as important parts of the service’s reliability and security posture.
The SKU model is different as well. Azure Managed Redis organizes in-memory offerings around Memory Optimized, Balanced, and Compute Optimized tiers, plus a Flash Optimized tier that combines memory with NVMe storage for very large data sets. This makes the selection conversation more directly about memory capacity, compute needs, throughput, availability, and cost rather than finding a one-for-one replacement based only on the old tier name.
Migration details that deserve attention
Azure Managed Redis is designed to minimize application changes, but migration is not an in-place rename. Applications must use the new hostname and credentials. Microsoft also configures Azure Managed Redis as clustered by default, so teams should verify that their client library and application behavior are compatible with a clustered deployment.
That cluster check is especially important for workloads that issue commands spanning multiple keys. Redis Cluster distributes keys across hash slots, and cross-slot operations can require changes to key naming, hash tags, command selection, or transaction design. Some clients, including StackExchange.Redis, handle cluster discovery without special setup, but that does not remove the need to test application behavior under real traffic patterns.
A migration plan should also confirm that the required region, instance size, management operation, networking option, and feature are available in Azure Managed Redis. Microsoft notes that some regions, sizes, and management capabilities may not yet have exact equivalents. A gap discovered during a production cutover is expensive; the same gap found during an inventory or pilot is manageable.
A practical path forward
- Inventory the estate. Record every cache, its tier, owners, consumers, configuration, data-retention requirements, and retirement deadline.
- Choose the target deliberately. Match capacity and performance requirements to the Azure Managed Redis tiers instead of assuming a direct SKU translation.
- Test client and cluster behavior. Validate timeouts, connection resiliency, key distribution, multi-key commands, authentication, private networking, and failover.
- Plan data movement and cutover. Decide how data will be preserved or repopulated, how endpoint and credential changes will be deployed, and how rollback will work.
- Migrate before the deadline becomes pressure. Leave enough time for performance testing, operational runbooks, observability, security review, and cost validation.
Microsoft provides separate migration guidance for Basic, Standard, and Premium caches and for Enterprise caches. Those guides should anchor the technical work, while application owners supply the workload-specific knowledge that no automated migration tool can infer.
The next chapter for Redis on Azure
My 2022 Azure Cache for Redis post belongs to a particular chapter in Azure’s history, and it is worth keeping for posterity. It shows how approachable the managed-service model had become and how little application code needed to change when moving from a local Redis instance to Azure.
Azure Managed Redis continues that managed experience but gives Microsoft a new foundation for performance, enterprise features, security, and future Redis workloads. For new architecture work, it is the clear path forward. For existing Azure Cache for Redis users, the question is no longer whether to move, but how to make the transition deliberately, test it thoroughly, and complete it comfortably ahead of the applicable retirement date.