Azure Cache for Redis Retirement: Dates, Changes and Options

Microsoft is retiring Azure Cache for Redis. The Basic, Standard and Premium tiers retire on 30 September 2028, and any instances still running are disabled from 1 October 2028. The Enterprise and Enterprise Flash tiers retire sooner, on 31 March 2027, and are disabled from 1 April 2027. Until then Microsoft keeps applying regular maintenance and security updates to every existing Azure Cache for Redis instance. After that the choice is Azure Managed Redis, Redis or Valkey that you run yourself, or a different platform, and each one changes something in your application.

The Azure Cache for Redis retirement timeline

The dates come from Microsoft's retirement FAQ, on Microsoft Learn, which recommends upgrading every existing cache now rather than waiting for the deadline.

• Azure Cache for Redis Basic, Standard and Premium tier: retire 30 September 2028; remaining instances disabled from 1 October 2028.
• Azure Cache for Redis Enterprise and Enterprise Flash tier: retire 31 March 2027; remaining instances disabled from 1 April 2027.

Teams on the Enterprise tier have months, not years. Teams on the Premium tier with virtual network injection, multiple databases or keyspace notifications have the most application work to do, so they should start first regardless of tier.

Option 1: Azure Managed Redis

Microsoft's recommended path is Azure Managed Redis (AMR), a fully managed service run by Microsoft and built on Redis Enterprise software, which Microsoft describes as multi-threaded, with higher throughput and lower latency than the open source Redis behind the old tiers. It is sized on two dimensions, memory size and performance tier (Balanced, Memory Optimized or Compute Optimized), it is clustered by default, and it adds features that most Azure Cache for Redis tiers lacked: data persistence, RDB import and export, active geo-replication, and Redis modules such as RediSearch, RedisJSON, RedisBloom and RedisTimeSeries. Microsoft offers two migration options, a manual switchover to a new Redis instance or Azure's migration tooling.

It is not a drop-in replacement. According to Microsoft's migration guide, the differences that reach your application are:

• New endpoint and port. The DNS suffix changes from .redis.cache.windows.net to <region>.redis.azure.net, and the cache listens on port 10000 in either TLS or plain-text mode, not 6380 and 6379 side by side.
• Clustering. The new service is a Redis cluster by default, with OSS or Enterprise clustering policies. A client configured for a non-clustered Basic or Standard cache may need changes.
• One database. Only database 0 is supported. Applications that use several Redis databases need a new key design.
• Networking. Virtual network injection and IP-based firewall rules are not supported; Azure Private Link replaces them.
• Redis version. The existing cache runs Redis 6; the new service runs Redis 7.4, so test any Redis command or client behaviour that changed between them.
• Missing features. Keyspace notifications are not currently available, Microsoft Entra ID authentication works but Entra ID RBAC is not supported, and manual reboot is replaced by managed node operations.
• Sizing. About 20% of memory is reserved for system overhead, so a workload that needs 10 GB of usable memory needs a SKU with at least 12.5 GB.

Choosing a tier and high availability

Sizing has two steps: pick a memory size, then a performance tier. Balanced is the starting point when you are unsure, Memory Optimized suits workloads that run out of memory before CPU, and Compute Optimized suits throughput-intensive or latency-sensitive workloads. Base the size on the peak Used Memory metric of the old cache over the past month, not its nominal size. High availability is optional: an instance without it, and without a replica, carries no SLA and is meant for dev and test, which is why Microsoft suggests disabling high availability when replacing a Basic tier cache.

Azure Managed Redis vs Azure Cache for Redis

Side by side, using Microsoft's retirement FAQ and migration guide. The rows that most often force application changes are the endpoint and port, clustering, the single database and networking.

Option 2: Run Redis or Valkey yourself

You can run Redis Open Source or Valkey on Azure Kubernetes Service or virtual machines in your own subscription. That keeps the things Azure Managed Redis drops, such as multiple databases, keyspace notifications and virtual network deployment, and it keeps the version and licence decision with you: Valkey remains BSD licensed, while Redis 8 and later are available under RSALv2, SSPLv1 or AGPLv3. The cost is operations. High availability, failover, patching, backups, monitoring and on-call become your team's job, or the job of whoever you hand them to.

Option 3: Move platform

If the application is moving to another cloud anyway, Amazon ElastiCache or Google Cloud Memorystore are the equivalents there. It is rarely worth moving an application for its cache alone. The trade-offs between hosted and operated Redis are compared in managed Redis options compared.

How to plan the migration

• Inventory every cache. Tier, size, peak used memory from Azure Monitor, and whether it uses virtual network injection, more than one database, keyspace notifications, persistence or geo-replication.
• Check every client. Connection strings, port, TLS, cluster-aware configuration and retry behaviour, in every application that connects.
• Size on real usage. Match peak used memory plus the 20% reserve, not the nominal cache size.
• Test the cutover. Decide whether the data must move or the cache can warm from empty, and rehearse the switch in a non-production environment.
• Start with the Enterprise tier caches. Their deadline comes first.

Where AceMQ fits

AceMQ helps teams choose between Azure Managed Redis and running Redis or Valkey in their own subscription, then plans and runs the migration. For teams that want to keep open source Redis in their own subscription without the operations, AceMQ managed Redis runs Redis or Valkey in your Azure subscription with a 15-minute emergency response, and Redis support covers clusters your team operates, including Azure Managed Redis.