Plan execution - Redis Enterprise

This article provides step-by-step instructions for both migration paths:

• Self-service migration for caches without geo-replication
• Self-service migration for caches with geo-replication

We highly recommend performing the migration during off-business hours, as it will result in a brief connectivity blip similar to behavior during regular maintenance operations.

Self-service migration for caches without geo-replication

Step 1: Update deployment scripts

Once you have identified the appropriate Azure Managed Redis SKU, update your deployment scripts (such as ARM templates, Bicep files, or Terraform configurations) to provision Azure Managed Redis instead of Azure Cache for Redis Enterprise.

Step 2: Create a new Azure Managed Redis instance

Using the size and performance tier you identified earlier, create the instance by following the Quickstart: Create an Azure Managed Redis Instance. You can alternately use list-skus-for-scaling command on your Redis Enterprise instance to determine the recommended Azure Managed Redis instance. az redisenterprise list-skus-for-scaling --resource-group rg --cluster-name clustername.region.redisenterprise.cache.azure.net

Step 3: Migrate your data

Choose a data migration strategy based on your tolerance for downtime and data loss.

Export and import data using an RDB file

Best for creating a point-in-time snapshot of your data.

• Pros: Preserves data snapshot, straightforward process.
• Cons: Data written after the snapshot is taken isn't captured.

Steps:

1. Export the RDB file from the existing Enterprise cache to your Azure Storage account.
2. Import the data from the Azure Storage account into the new Azure Managed Redis instance.
3. For detailed instructions, see Import and Export data in Azure Managed Redis.

Dual-write strategy

Best when you need zero data loss and can tolerate running two caches temporarily.

• Pros: No data loss, no downtime, uninterrupted operations.
• Cons: Requires running two caches for an extended period.

Steps:

1. Modify your application to write to both the existing Enterprise cache and the new Azure Managed Redis instance.
2. Continue reading from the Enterprise cache while data populates in the new instance.
3. After sufficient data sync, switch reads to Azure Managed Redis.
4. Proceed to Step 4: Update your application.

Programmatic migration using RIOT

RIOT provides a way to migrate content from Enterprise to Azure Managed Redis. For more information, see Data Migration with RIOT-X for Azure Managed Redis.

• Pros: Full control, customizable.
• Cons: Requires development effort.

Step 4: Update your application

Update your application's connection configuration to point to the new Azure Managed Redis instance. At a minimum, you need to update:

• Hostname: The DNS suffix changes from redisenterprise.cache.azure.net to redis.azure.net.
• Access key: Use the access key from the new Azure Managed Redis instance.

Step 5: Validate and decommission

1. Verify your application works correctly with the new Azure Managed Redis instance.
2. Monitor the new cache for expected behavior, performance, and error rates.
3. Once you're confident the new instance is working as expected, delete the old Enterprise instance.

Self-service migration for caches with geo-replication

Use these steps if you have a set of geo-replicated Redis Enterprise caches that you want to migrate to Azure Managed Redis.

1. Identify the appropriate Azure Managed Redis SKU using the list-skus-for-scaling command in the Azure CLI: az redisenterprise list-skus-for-scaling --resource-group --cluster-name.
2. Ensure that all Redis Enterprise caches in your geo-replication group are the same SKU and size.
3. Create a new Azure Managed Redis instance and during creation, add it to the geo-replication group which contains the Redis Enterprise instances that you wish to migrate.
4. If you use private endpoint, then provision a new private DNS Zone for *.redis.azure.net in the same virtual network and create a new private endpoint for this new Azure Managed Redis instance.
5. Verify that the new Azure Managed Redis instance is accessible and update your application to include the new Azure Managed Redis endpoint.
6. Once Azure Managed Redis instance has replicated all the dataset, remove one Redis Enterprise instance from the geo-replicated group.
7. Repeat the preceding steps for every remaining Redis Enterprise cache in your geo-replication group.

Limitations/callouts

1. Once an Azure Managed Redis instance is added to an existing geo-replication group of Redis Enterprise instances, you cannot add new Redis Enterprise instances to that geo-replication group. You can only add Azure Managed Redis and only remove Redis Enterprise instances.
2. Scaling is blocked when a geo-replication contains a mix of Azure Managed Redis and Redis Enterprise instances.
3. While geo-replication groups have a limit of 5 Redis instances, we allow up to 6 Redis instances for geo-replication group containing a mix of Azure Managed Redis and Redis Enterprise to facilitate migration.

Related content

• Migration overview
• Understand the differences
• What is Azure Managed Redis?
• Azure Managed Redis architecture
• Scale an Azure Managed Redis instance