Azure Cache for Redis Migration, the [Rollback] button

John Wong Yek Hon 295 Reputation points
2026-06-19T09:45:03.5366667+00:00

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.

Azure Cache for Redis
Azure Cache for Redis

An Azure service that provides access to a secure, dedicated Redis cache, managed by Microsoft.

Answer accepted by question author
Manoj Kumar Boyini 19,590 Reputation points Microsoft External Staff Moderator
2026-07-02T04:52:55.48+00:00

Hi @John Wong Yek Hon

The new data won't be pumped to AMR using Migration tool. You needs to perform import/export operation. The migration tool is just the DNS switch, it won't migrate the data.

Since the data in OSS is retained, they will be charged.

We don't have any specific guidance for RIOT-X to migrate, the only migrate options we have is mentioned either a self-service migration (Plan execution - Migrate from Basic, Standard, and Premium tiers to Azure Managed Redis - Azure Man…) or migration using tooling (Migrate with tooling - Migrate from Basic, Standard, and Premium tiers to Azure Managed Redis - Azu…)

Was this answer helpful?

1 person found this answer helpful.

2 additional answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Manoj Kumar Boyini 19,590 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.

    Was this answer helpful?

    0 comments

  2. AI answer

    2026-06-19T09:45:23.3133333+00:00

    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:

    1. 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.
    2. 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:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.