The Azure Cache for Redis retirement is not a SKU cleanup and it is not a rename. It is a forced platform transition to Azure Managed Redis (AMR) with a deadline attached. If you treat it as a connection-string change, you will miss the real work: clustering, private endpoints, authentication, tenant isolation, and cutover risk. And the two “do nothing” outcomes are not the same — one hands control of your cutover to Microsoft, the other is an outage.

Here is the unvarnished version: what is retiring and when, what AMR really is under the hood, where the migration bites, and a decision framework you can defend in an architecture review.

The Azure Cache for Redis retirement timeline

The single most important thing to internalize is that the Azure Cache for Redis retirement schedule and the consequence of inaction differ by tier. Treat them separately.

A caveat that matters: Microsoft’s own documentation is inconsistent about what happens to Enterprise caches after the deadline. The What’s New page and the preparation blog say Microsoft migrates remaining Enterprise and Enterprise Flash caches to Azure Managed Redis; the retirement FAQ says Microsoft disables them on 1 April 2027. Do not treat either as a safe fallback — one hands your cutover to Microsoft’s schedule and configuration choices, the other is an outage. For Basic, Standard, and Premium the two sources agree: Microsoft turns the caches off on 1 October 2028 and runs no automatic migration.

What inaction costs, by tier

The practical reading: Enterprise inaction means losing control of the cutover at best and an outage at worst; Basic/Standard/Premium inaction means the lights go off. The two tiers demand different urgency, and a single “we have until 2028” narrative catches teams out. Plan your own migration before 31 March 2027 (Enterprise) or 30 September 2028 (Basic/Standard/Premium), and confirm the post-deadline behavior with Microsoft support for your subscription and region.

Microsoft honors existing reservations until the respective retirement dates (30 Mar 2027 for Enterprise, 30 Sep 2028 for Basic/Standard/Premium), and you can cancel or exchange them earlier. Factor the reservation accounting into the migration business case — it is not a footnote.

What Azure Managed Redis actually is

AAzure Managed Redis went GA in May 2025 (public preview was November 2024). The naming similarity hides a genuine platform change:

• Different engine. Azure Cache for Redis runs on a fork of Redis OSS; AMR runs on Redis Enterprise software. That difference drives both the new capabilities and the migration friction.
• First-party, no Marketplace. Unlike Azure Cache for Redis Enterprise — which transacted through Azure Marketplace — AMR is a native Azure resource. You provision, manage, and pay for it like any other Azure service.
• The quorum node is gone. Removing it lowers overhead and cost and lets AMR reach regions the old Enterprise tier couldn’t.
• Zone-redundant by default, with up to 99.999% availability when you add active geo-replication.
• Microsoft Entra ID by default. A new cache disables access-key authentication out of the box. This is a security upgrade, but also a behavioral change your clients and pipelines must account for.
• Clustered by default across all tiers and SKUs — including the small ones.

That final point is where most migration pain originates, so it gets its own section.

Why “lift and shift” is the wrong way to migrate to Azure Managed Redis

The migration tooling will swap your endpoint with only a brief DNS blip, and most client libraries connect to AMR without drama. That convenience masks several architectural changes that are not automatic. These are the ones to validate before you commit a date.

1. Clustering by default → CROSSSLOT errors

Because AMR is clustered by default, multi-key commands that touch keys on different shards will throw CROSSSLOT errors. If your application issues multi-key operations (transactions, MGET/MSET across related keys, Lua scripts spanning keys), they can break the moment you point at a clustered instance.

The mitigation is hash tags: wrap the common portion of related keys in braces — for example {tenantId}:profile and {tenantId}:settings — so Redis routes them to the same shard. Cluster-aware clients like StackExchange.Redis handle the topology transparently, but your key design has to cooperate. This is a code-and-data-model review, not a connection-string change.

2. The cluster policy is a real architectural choice

AMR offers three cluster policies, and the default is not always what you want:

• OSS (default): best performance, but requires a cluster-aware client library.
• Enterprise: a single endpoint that is simpler to configure, but it can become a throughput bottleneck at scale.
• Non-clustered: available only up to 25 GB, and primarily useful when migrating from a non-clustered Azure Cache for Redis instance to minimize client changes.

Pick deliberately. The “simpler” Enterprise policy can quietly cap a high-throughput workload; the “faster” OSS policy assumes your client stack is cluster-ready.

3. No VNet injection — private endpoints only

This is the one that turns a migration into a re-architecture. AMR does not support virtual network injection. Private endpoints deliver the network isolation instead. If your current Azure Cache for Redis Premium relies on VNet injection — common in regulated, healthcare, or otherwise network-segmented environments — you cannot lift and shift the network design. You move to a private-endpoint model, which pulls in private DNS resolution, conditional forwarding, and your hub-spoke and Private Link topology. If you have already done that work for other PaaS services as part of your landing zone, this is familiar ground; if not, scope it as its own workstream.

4. No key-level access control yet

With Entra ID authentication, an authenticated identity currently receives full data access to all keys in the cache. AMR does not yet support data-access policies that scope an identity to specific keys or key patterns. For a shared cache serving multiple tenants, this means you cannot enforce per-tenant isolation at the cache level — isolation has to live in your application logic, or you provision a cache per tenant. ACLs are on the roadmap with no committed ETA, so do not design around a date.

5. In-memory data is not encrypted by the service

AMR encrypts data in transit (TLS) and supports customer-managed keys for disk encryption, scoped per instance. The service does not encrypt data in memory. If you cache sensitive fields and your compliance posture requires encryption at rest in all layers, apply application-level encryption before writing to the cache.

6. Modules are a creation-time decision

If you use Redis modules — RediSearch, RedisJSON, RedisBloom, RedisTimeSeries — select them at cache creation. You cannot add them later. And RedisTimeSeries is not available on the Flash Optimized tier, which matters if you cache per-tenant telemetry.

Choosing the tier and SKU

AMR replaces the old capacity-and-scale-factor juggling with three performance tiers defined by their memory-to-vCPU ratio:

• Memory Optimized — large datasets, lighter compute.
• Balanced — the general-purpose default.
• Compute Optimized — high-throughput, compute-heavy workloads.

There is also a Flash Optimized tier for very large datasets at a lower price point. Note that the smallest balanced SKUs (B0 and B1) do not support active geo-replication, so if geo-distribution is a requirement, it constrains your floor. Larger SKUs (up to 500 GB across the in-memory tiers) have been rolling out through 2026, so confirm size availability in your target region before you lock a design.

Migration mechanics

The phased CLI migration tooling lets you migrate the cache endpoint while keeping the same hostname and access key, so the transition is mostly seamless from the client’s perspective — expect a connection blip of a few seconds when the DNS record updates, comparable to a maintenance event. For the data itself, Microsoft documents an export/import path and recommends RIOT-X for live data migration between instances.

The minimum application-side checklist:

1. Repoint hostname and credentials to the AMR instance (and plan for Entra ID auth, since keys are off by default on new caches).
2. Confirm your client library is cluster-aware and your key naming uses hash tags where multi-key operations exist.
3. Choose the cluster policy intentionally.
4. Re-do network isolation as private endpoints if you were on VNet injection.
5. Decide per-tenant isolation strategy given the absence of key-level ACLs.
6. Add application-level encryption if in-memory sensitive data is in scope.

A decision framework

Migrate now if you are on Enterprise/Enterprise Flash (you lose the ability to create new instances after 1 Apr 2026, and you want the cutover on your own terms rather than the forced April 2027 migration), or if you want the cost and reliability gains and your client stack is already cluster-ready.

Plan deliberately — but don’t stall — if you are on Basic/Standard/Premium. The Azure Cache for Redis retirement gives you until 2028, but the work is front-loaded: VNet-injection redesign, multi-key/CROSSSLOT remediation, and the auth model change are engineering efforts, not flips of a switch. Existing customers also lose creation rights on 1 Oct 2026, which quietly limits scaling-by-new-instance well before the retirement date.

Validate before you commit a date — the five things most likely to bite: VNet injection vs private endpoints, multi-key commands vs clustering, per-tenant isolation vs the missing ACLs, in-memory encryption requirements, and any module or region that isn’t yet available in AMR. If a blocker exists, raise it with Microsoft support early rather than discovering it during cutover.

A note on multitenant caches

If you run a shared cache across tenants, the AMR changes compound. Clustering means you should adopt {tenantId} hash tags so a single tenant’s keys land on one shard. The absence of key-level ACLs means AMR cannot enforce cache-level per-tenant authorization — you either isolate in the application or move to a cache-per-tenant model (there is no subscription limit on the number of caches, but each cache is a separate billing and operational unit). Because billing happens per instance, per-tenant cost attribution on a shared cache needs application-level metering. And the classic noisy-neighbor risk applies: monitor CPU and memory, and be ready to scale up or shard out by tenant or by subsystem.

Pre-migration architecture checklist

Before you commit a cutover date, confirm each of these — they are the items most likely to turn a “simple” migration into a project:

• Networking: Are you on VNet injection today? If so, design the private-endpoint model, private DNS resolution, and approval flow before anything else.
• Clustering: Inventory multi-key commands, transactions, and Lua scripts. Introduce {hashTag} key naming wherever operations must stay on one shard.
• Cluster policy: Choose deliberately — OSS (performance, needs a cluster-aware client) vs Enterprise (single endpoint, throughput ceiling) vs Non-Clustered (≤25 GB, migration convenience).
• Authentication: Plan the switch to Microsoft Entra ID; access keys are off by default on new caches. Update clients and pipelines accordingly.
• Tenant isolation: With no key-level ACLs, decide between application-enforced isolation on a shared cache or a cache-per-tenant model.
• Encryption: If sensitive data sits in memory, add application-level encryption — the service does not encrypt in-memory data.
• Modules and region: Select modules at creation (they can’t be added later), and confirm your SKU size and target region are available in AMR.
• Reservations: Reconcile existing Azure Cache for Redis reservations (cancel or exchange) into the business case.

The bottom line

Azure Managed Redis can be a better platform than what it replaces — stronger availability defaults, Enterprise capabilities, native Azure billing, and potentially better price/performance, depending on tier, region, and workload. But the migration cost is real, and the “it’s just an upgrade” framing understates the work. The Azure Cache for Redis retirement is real, the dates differ by tier, and the inaction outcomes — a loss of cutover control or an outage for Enterprise, lights-off for Basic/Standard/Premium — should set your urgency. Scope the networking and access-control changes now, treat the multi-key/clustering remediation as application work, and pick your cutover window before Microsoft picks it for you.

The architect’s take

The hardest part of this migration is unlikely to be the Redis endpoint itself. The cache moves quickly; the assumptions around it do not. The real effort lives in the surrounding architecture — private DNS and the private-endpoint approval flow, client authentication switching to Entra ID, and the key design that clustering forces you to revisit. Budget your engineering time there, not on the endpoint swap.

FAQ

What is the Azure Cache for Redis retirement timeline?

Enterprise and Enterprise Flash tiers retire on 31 March 2027; Basic, Standard, and Premium tiers retire on 30 September 2028. Microsoft blocks creation of new instances for all customers from 1 April 2026 (existing Basic/Standard/Premium customers can still create until 1 October 2026).

What happens if I do nothing?

For Enterprise and Enterprise Flash, Microsoft’s documentation is inconsistent: some pages say Microsoft migrates remaining caches to Azure Managed Redis around the 31 March 2027 deadline, while the retirement FAQ says Microsoft disables them on 1 April 2027. Treat neither as a safe fallback. Microsoft does not auto-migrate Basic, Standard, and Premium instances — it turns them off on 1 October 2028, which means an outage and potential data loss. Plan and execute your own migration ahead of the deadline.

Is moving to Azure Managed Redis a simple lift and shift?

No. AMR is built on Redis Enterprise rather than Redis OSS. It is clustered by default (which can cause CROSSSLOT errors on multi-key commands), does not support VNet injection (only private endpoints), uses Microsoft Entra ID authentication by default, and does not yet offer key-level access control. Each of these may require application, network, or security changes.

Can I keep using access keys?

On a new AMR cache, access-key authentication is disabled by default in favor of Microsoft Entra ID. Plan for the identity-based model in your clients and pipelines rather than assuming key-based connection strings will carry over unchanged.

Sources

• Azure Cache for Redis retirement FAQ
• What is Azure Managed Redis?
• Multitenancy and Azure Managed Redis (Azure Architecture Center)
• Azure Cache for Redis Retirement: What to Know and How to Prepare
• Migrate to Azure Managed Redis (overview)