Migrate Azure Cache for Redis to Azure Managed Redis Before Retirement

To migrate from Azure Cache for Redis to Azure Managed Redis, you create a new Azure Managed Redis instance sized at least as large as the existing cache's real memory use, move or rehydrate the data, and repoint clients to the new hostname on port 10000. Basic, Standard and Premium caches retire on 30 September 2028 and Enterprise caches on 31 March 2027, so the work is a planned cutover rather than an in-place upgrade. Microsoft also offers preview tooling that moves the old hostname to the new cache for you, with several limitations.

Who this is for and what you will have at the end

This guide is for Azure administrators and developers who run Azure Cache for Redis in the Basic, Standard or Premium tiers and need to plan the move before retirement. Enterprise-tier caches follow a separate Microsoft guide with similar steps; the dates and connection differences are noted here, but the walkthrough focuses on the Basic, Standard and Premium tiers.

At the end you will have:

• A clear picture of what changes for your applications: hostname, port, clustering, databases and networking.
• An Azure Managed Redis instance sized from actual memory usage, not the nominal cache size.
• Data migrated with a method that matches your tolerance for data loss.
• Clients cut over, verified, and the old cache deleted.

Retirement dates and what happens afterwards

Existing caches keep running and receive maintenance until their retirement date. Reservations for Basic, Standard and Premium are honoured until 30 September 2028, and you can cancel or exchange them earlier under the standard reservation policies. Microsoft's guidance is not to wait for the deadline.

What changes when you move to Azure Managed Redis

Azure Managed Redis runs on the Redis Enterprise software stack rather than the open-source Redis fork used by Azure Cache for Redis. Most commands and client libraries work unchanged, but several platform differences need decisions before you create the new cache.

Connection differences

A Basic, Standard or Premium cache can accept TLS on 6380 and plain text on 6379 at the same time. Azure Managed Redis supports one mode per cache, chosen at creation, and every client must use it. TLS is the default.

Platform differences that affect design

• Clustering. Azure Managed Redis is clustered by default and offers OSS clustering (the default and Microsoft's recommendation for performance) and Enterprise clustering. If you run a non-clustered Basic or Standard cache today, your client must be cluster-aware and handle MOVED redirections. Non-clustered mode exists only up to 25 GB.
• One database. Azure Cache for Redis supports multiple databases (16 by default, up to 64 on Premium). Azure Managed Redis supports database 0 only. Refactor to a single database or use key prefixes before you migrate.
• Network isolation. Virtual network injection and IP-based firewall rules aren't supported. A VNet-injected cache has to move to Azure Private Link.
• Authentication. Microsoft Entra authentication is enabled by default on new caches, and the Azure CLI reference states that access-key authentication defaults to disabled. If your applications still use access keys, enable them deliberately or move the applications to Entra ID first. The migration guide also notes that Entra ID RBAC isn't currently supported in Azure Managed Redis.
• Operations that disappear. There is no manual reboot (use the Flush management operation if you rebooted to clear data) and no explicit geo-replication failover command; with active geo-replication your application switches to another linked cache when a region is down.
• Keyspace notifications. The migration guide lists them as unavailable, while a separate Azure Managed Redis article describes them as a preview feature. Test before you depend on them.
• Features you gain. Zone redundancy (when high availability is on and the region has zones), data persistence, RDB import and export, active geo-replication and Redis modules such as RediSearch and RedisJSON are available on every Azure Managed Redis size, rather than only in Premium.

Prerequisites

• Permission to create resources in the resource group that will hold the new cache.
• Azure CLI 2.75.0 or later, which the current redisenterprise extension reference requires. The extension, which manages Azure Managed Redis, installs on first use of an az redisenterprise command.
• Access to Azure Monitor metrics for the existing cache (you need the Used Memory metric).
• For RDB migration: a Premium source cache and a storage account without a firewall or private link, because Azure Managed Redis import and export don't support those storage settings.
• A list of every application, function app and job that connects to the cache, with where its connection string lives.

Step 1: Inventory and size the target

Start by listing the caches you need to replace.

az redis list --query "[].{name:name, rg:resourceGroup, sku:sku.name, size:sku.capacity, location:location, nonSsl:enableNonSslPort}" --output table

For each cache, decide on two things: memory size and performance tier.

Memory size. Azure Managed Redis reserves about 20% of memory for system overhead. The B10, M10 and X10 SKUs offer 12 GB of total memory but roughly 9.6 GB usable. If a workload needs 10 GB of usable memory, choose a SKU with at least 12.5 GB total. Rather than matching the nominal size of the old cache, check the peak Used Memory metric over the last month; a cache that's mostly empty can move to a smaller SKU. For a clustered Premium cache, add up the memory across all shards.

Performance tier.

If you're migrating a Basic cache, which has no replication or SLA, disable high availability on the new cache. Microsoft notes this halves the cost and gives a comparable dev/test setup. Non-HA caches carry no SLA and can lose data during maintenance.

Step 2: Choose a migration path

Microsoft documents two paths and recommends the first for most customers.

The tooling doesn't copy managed identities, firewall rules, persistence, update schedules or keyspace notification settings, and it blocks other management operations while the cache shows Migrating. After it completes you have a limited window to roll back, and the old hostname will eventually be deleted, so you still have to update clients later.

Step 3: Create the Azure Managed Redis instance

Update your ARM, Bicep or Terraform definitions to deploy Azure Managed Redis instead of Azure Cache for Redis. The equivalent Azure CLI command looks like this:

az redisenterprise create \
  --name redis-contoso-prod \
  --resource-group rg-cache-prod \
  --location "East US" \
  --sku Balanced_B10 \
  --clustering-policy OSSCluster \
  --client-protocol Encrypted \
  --minimum-tls-version 1.2 \
  --high-availability Enabled

Key parameters, all from the CLI reference:

• --sku takes values such as Balanced_B10, MemoryOptimized_M20 or ComputeOptimized_X10.
• --clustering-policy accepts OSSCluster (default), EnterpriseCluster or NoCluster. It's set at creation.
• --client-protocol accepts Encrypted (default) or Plaintext.
• --access-keys-authentication Enabled turns on key-based access if your clients still need it; the CLI reference lists the default as disabled.
• --eviction-policy defaults to VolatileLRU; set it to match the policy you use today.

If the old cache used a private endpoint or VNet injection, create a private endpoint for the new cache with the group ID redisEnterprise. A private DNS zone privatelink.redis.azure.net is created, and clients should still connect to <cachename>.<region>.redis.azure.net, not the privatelink name.

Step 4: Migrate the data

If the cache is a look-aside cache that your application can rebuild from its source of truth, skip this step and let it warm up. Otherwise pick one of these strategies.

RDB export and import (Premium only)

This gives a point-in-time snapshot; writes after the export aren't captured. Export from the Premium cache to a storage container using a SAS URL:

az redis export \
  --name redis-contoso-old \
  --resource-group rg-cache-prod \
  --prefix contoso-export \
  --container "<container-SAS-URL>"

Then import the blob into the new cache:

az redisenterprise database import \
  --cluster-name redis-contoso-prod \
  --resource-group rg-cache-prod \
  --sas-uris "<blob-SAS-URL>"

The new cache is unavailable to clients during the import and any existing data in it is deleted. Keys larger than 2 GB make the import fail. The SAS token for import needs read, add, create and list permissions, and the operation must start within 15 minutes of opening the import pane in the portal or it fails with a SAS time error.

Dual write

For no data loss and no downtime, change the application to write to both caches, keep reading from the old cache until the new one is sufficiently populated, then switch reads and writes to the new cache. The cost is running two caches for a period.

Programmatic copy

Run a copy tool such as RIOT-X from a VM in the same region as the source cache. Flush the new cache first so it's empty, and never flush the source.

Step 5: Update the application connection settings

At a minimum, change three things:

• Hostname: from <name>.redis.cache.windows.net to <name>.<region>.redis.azure.net.
• Port: from 6380 to 10000.
• Credentials: use the new cache's access key, or preferably Microsoft Entra ID with a managed identity.

A StackExchange.Redis connection string changes from the first form to the second:

redis-contoso-old.redis.cache.windows.net:6380,password=<old-key>,ssl=True,abortConnect=False
redis-contoso-prod.eastus.redis.azure.net:10000,password=<new-key>,ssl=True,abortConnect=False

StackExchange.Redis needs no extra configuration for a clustered cache. For other libraries (Lettuce, Jedis, node-redis, redis-py, go-redis), check that you're using the library's cluster client when the cache uses OSS clustering. Also review outbound firewalls and proxies: allow *.redis.azure.net on port 10000, plus the 85xx node ports if you use OSS clustering. Microsoft notes that the 85xx ports can change over time, so don't hardcode them in the application.

Using the preview migration tooling instead

If you chose the tooling path, the sequence after creating the target cache is:

1. Configure managed identities and permissions on the new cache first if you use Entra ID, and copy data with one of the methods above if you need it.
2. In the Azure portal, open the old cache, go to Overview and select Migrate on the command bar.
3. Select the target Azure Managed Redis instance and select Validate. Warnings (for example, persistence enabled on the source but not the target) can be bypassed; errors (for example, a VNet-injected source) block migration.
4. Select Migrate. The status changes to Migrating and clients see a connection blip similar to maintenance, then reconnect to the new cache using the old hostname and access key.
5. Validate the application, delete the old cache (the old hostname keeps pointing to the new cache), and then update clients to the new <cachename>.<region>.redis.azure.net hostname.

Verification

Test connectivity from the Azure CLI with Microsoft Entra authentication:

az redisenterprise test-connection --cluster-name redis-contoso-prod --resource-group rg-cache-prod --auth entra

To test access-key authentication instead, use --auth access-key. From a client machine, use redis-cli with TLS and, for OSS clustering, the -c option:

redis-cli -p 10000 -h redis-contoso-prod.eastus.redis.azure.net -a <access-key> --tls -c

Run PING (expect PONG) and a SET/GET pair. Then confirm the new cache's metrics show the expected connected clients, memory use and error rates, and that the old cache's connected clients drop to zero before you delete it.

Troubleshooting

CROSSSLOT errors on multi-key commands. With OSS clustering, all keys in a multi-key command must hash to the same slot. Use hash tags in key names or restructure the command. With Enterprise clustering, only DEL, MSET, MGET, EXISTS, UNLINK and TOUCH work across slots.

MOVED errors or keys "missing" from some shards. The client isn't cluster-aware. Switch to the library's cluster client, or for redis-cli add -c.

Data that lived in database 1 or higher isn't found. Azure Managed Redis supports database 0 only, so code that selects another database doesn't work as before. Consolidate into one database with key prefixes.

Clients can't connect over a private endpoint. Run nslookup for the cache hostname from inside the linked virtual network and confirm it resolves to the private IP. Make sure the connection string uses <name>.<region>.redis.azure.net, not the privatelink hostname.

Import fails with "The SAS token end time (se) must be at least 1 hour from now". The import or export pane was open for more than 15 minutes before the operation started. Restart it promptly. Exports also fail to storage accounts with firewall exceptions or private links.

Authentication fails with an access key. Access keys may be disabled on the new cache. Enable them with az redisenterprise database update --cluster-name <cache> --resource-group <rg> --access-keys-authentication Enabled, or switch the client to Entra ID.

For a wider view of sequencing several platform moves together, see the enterprise Azure cloud migration playbook.

Checklist

• Every Azure Cache for Redis instance inventoried, with its tier, size, non-TLS port use and consumers.
• Multiple databases consolidated to database 0; clients confirmed cluster-aware.
• Target SKU chosen from peak Used Memory plus the 20% reservation; HA disabled only for former Basic caches.
• VNet injection replaced with Private Link; firewalls allow port 10000.
• Authentication decided: Entra ID, or access keys explicitly enabled.
• Data migrated or rehydration accepted; cutover tested in a non-production environment.
• Clients repointed to the new hostname and port, old cache drained and deleted well before 30 September 2028.

References

• FAQ on the retirement of Azure Cache for Redis
• Migrate from Basic, Standard, and Premium tiers to Azure Managed Redis
• Understand the differences
• Migration options
• Plan migration execution
• Migrate with tooling (preview)
• Manage an Azure Managed Redis cache using the Azure CLI
• az redisenterprise reference
• az redis reference
• Import and export data in Azure Managed Redis
• Azure Managed Redis client libraries
• Azure Managed Redis with Azure Private Link
• Connectivity troubleshooting with Azure Managed Redis
• Use the Redis command-line tool with Azure Managed Redis
• Enable Redis keyspace notifications (preview)