Azure Cache for Redis Migration, the [Rollback] button

Question

Azure Cache for Redis Migration, the [Rollback] button

John Wong Yek Hon 275

I recently tested the Redis [Migration], migrate from the Azure Cache for Redis (ACR) to the new Azure Managed Redis (AMR).

After the migration completed, i pump in some new data still via the old URL (hostname). Everything looks OK.

There's the [rollback] button. I have tried on that button, and I noticed that together with the URL (hostname), the data are also restored back to my old Azure Cache for Redis.

Well, I am abit confused. Ain't those new pumped in data should be on the new AMR only? The [Migrate] button doesn't carry any data, but the rollback do carry data.

Please some expert share to me exactly how should I use this Migrate & Rollback action here.

Manoj Kumar Boyini 17,060 Reputation points Microsoft External Staff Moderator

2026-06-19T11:33:09.46+00:00
Hi @John Wong Yek Hon

The migration tooling is primarily an endpoint/hostname migration mechanism rather than a data synchronization feature.

During migration, the Azure Cache for Redis hostname is updated to point to the Azure Managed Redis instance so that client applications can continue using the same hostname and access key.

One important limitation of the migration tooling is that data sync is not supported. The documentation states that the tooling orchestrates hostname/endpoint migration but does not provide data synchronization between the source Azure Cache for Redis instance and the target Azure Managed Redis instance.

Because of this:

After migration, requests sent to the original hostname are routed to Azure Managed Redis.

Rollback restores the hostname mapping back to the original Azure Cache for Redis instance within the supported rollback window.

The migration tooling should be viewed as an endpoint migration workflow rather than a data replication workflow.

Based on the public documentation, there is no documented mechanism that automatically synchronizes post-cutover writes back to the source cache during rollback.

To better understand the behavior you observed, could you clarify:

Was the new data written after the migration had fully completed?

Approximately how long after migration did you perform the rollback?

Did you verify the data directly against the original Azure Cache for Redis instance after rollback, or through the hostname endpoint?

This will help determine whether the observed behavior is expected or whether additional investigation is required.

Reference:
https://learn.microsoft.com/azure/azure-cache-for-redis/migrate/migration-options-basic-standard-premium
John Wong Yek Hon 275 Reputation points

2026-06-19T13:03:44.5466667+00:00
I use the RIOT-X to constantly replicate data from old to new redis.

I run a script to keep pump in data to the old cache every 200ms.

The RIOT-X instantly replicate data to the new redis as expected.

While the script keep running, now I perform the [Migrate]

As soon as migration success, the RIOT-X throw exception because the new AMR has password changed to same as the old ACR. Well, this one is fair enough, a valid behaviour.

My script still running, pump in data to the "old" redis. well I believe its actually now pointed to the new AMR, though its using the old ACR hostname.

My script completed. I can see all pumped in data in the new AMR actually.

One day later, i try with the [Rollback].

Rollback success. I expect the old ACR shall have no data. Surprisingly, it consist of all data I pumped in after the migration.

And what about the new AMR? Seems the data has been "moved back" to the old ACR, they disappear from the new AMR. Still some data remained in the new AMR, those that replicated with RIOT-X

1 answer

Your answer

Manoj Kumar Boyini 17,060 Reputation points Microsoft External Staff Moderator

2026-06-19T11:33:09.46+00:00

Hi @John Wong Yek Hon

The migration tooling is primarily an endpoint/hostname migration mechanism rather than a data synchronization feature.

During migration, the Azure Cache for Redis hostname is updated to point to the Azure Managed Redis instance so that client applications can continue using the same hostname and access key.

One important limitation of the migration tooling is that data sync is not supported. The documentation states that the tooling orchestrates hostname/endpoint migration but does not provide data synchronization between the source Azure Cache for Redis instance and the target Azure Managed Redis instance.

Because of this:

After migration, requests sent to the original hostname are routed to Azure Managed Redis.

Rollback restores the hostname mapping back to the original Azure Cache for Redis instance within the supported rollback window.

The migration tooling should be viewed as an endpoint migration workflow rather than a data replication workflow.

Based on the public documentation, there is no documented mechanism that automatically synchronizes post-cutover writes back to the source cache during rollback.

To better understand the behavior you observed, could you clarify:

Was the new data written after the migration had fully completed?

Approximately how long after migration did you perform the rollback?

Did you verify the data directly against the original Azure Cache for Redis instance after rollback, or through the hostname endpoint?

This will help determine whether the observed behavior is expected or whether additional investigation is required.

Reference:
https://learn.microsoft.com/azure/azure-cache-for-redis/migrate/migration-options-basic-standard-premium
John Wong Yek Hon 275 Reputation points

2026-06-19T13:03:44.5466667+00:00

I use the RIOT-X to constantly replicate data from old to new redis.

I run a script to keep pump in data to the old cache every 200ms.

The RIOT-X instantly replicate data to the new redis as expected.

While the script keep running, now I perform the [Migrate]

As soon as migration success, the RIOT-X throw exception because the new AMR has password changed to same as the old ACR. Well, this one is fair enough, a valid behaviour.

My script still running, pump in data to the "old" redis. well I believe its actually now pointed to the new AMR, though its using the old ACR hostname.

My script completed. I can see all pumped in data in the new AMR actually.

One day later, i try with the [Rollback].

Rollback success. I expect the old ACR shall have no data. Surprisingly, it consist of all data I pumped in after the migration.

And what about the new AMR? Seems the data has been "moved back" to the old ACR, they disappear from the new AMR. Still some data remained in the new AMR, those that replicated with RIOT-X

Answer 1

Migration and rollback behave differently because the built‑in tooling only orchestrates endpoint/hostname cutover; it does not continuously synchronize data.

From the documented behavior of the migration tooling:

For Azure Cache for Redis → Azure Managed Redis migrations, the tooling:
- Updates the old Azure Cache for Redis hostname to point to the new Azure Managed Redis instance so that clients reconnect automatically using the same hostname and access key.
- Does not migrate or sync data between the old and new caches. Any data you want on the new cache must be migrated separately using one of the documented data‑migration strategies.
For Basic/Standard/Premium tiers, there is an explicit note that:
- “Data sync not supported. This tooling will orchestrate hostname/endpoint migration but does not migrate any data.”
- There is a limited window for rollback after migration starts; rollback is about reversing the endpoint change, not about replaying or syncing data.

How this applies to the scenario:

After migration completes, the old hostname now points to the Azure Managed Redis instance. Any “new pumped in data” written via the old URL is actually being written to the new AMR cache, not to the original ACR resource.
The migration tooling does not copy data back and forth. When using rollback (where supported), the tooling is switching which cache the hostname points to. If data appears to “come back,” it is because the hostname is now pointing back to the original cache that still has whatever data it had at the time you last used it, not because the tooling copied new data from AMR to ACR.

Practical guidance for using Migrate & Rollback:

Treat Migrate as an endpoint/hostname cutover only. Plan and execute data migration separately (for example, using one of the self‑service data migration strategies described in the docs).
Assume no automatic data sync in either direction:
- Before cutover, ensure the target AMR cache has the data needed (copied from the source) or that the application can repopulate it.
- After cutover, any new writes via the old hostname are going to AMR.
Use Rollback only within the documented limited window as a safety net to point traffic back to the original cache if application validation fails. Do not rely on rollback to move or merge data.
After validating that applications work correctly with AMR, update them to use the new Azure Managed Redis hostname (<cachename>.<region>.redis.azure.net) and decommission the old ACR hostname as recommended.

If the observed behavior suggests that data is actually being copied during rollback (beyond simply switching which cache the hostname targets), open a support case with Azure, as that would be outside the documented, supported behavior.

References:

Share via

Azure Cache for Redis Migration, the [Rollback] button

1 answer

Your answer