Azure Managed Redis migration tooling (preview) with data migration: migrate, cancel and rollback all fail after ~90 min, source stuck in a migration state

shri-7895 0 Reputation points
2026-10-28T21:15:29.6533333+00:00

I used the portal migration tooling (preview) to migrate an Azure Cache for Redis cache to a pre-created Azure Managed Redis cache, with the copy-data option selected. The migration, a cancel, and a later rollback from the portal all failed with a generic OperationFailed after about 90 minutes. The source is stuck in a migration state, so it can't be migrated again, and the portal's Migrate pane offers no target. The source still serves traffic normally. Support case 305831e6-1b8b1cb0-38c56600-5f13-4873-9db3-f184fa889ba5 was routed here.

Environment

  • Source: Azure Cache for Redis, Standard C3, Redis 6.0, North Central US. Not clustered, no VNet injection, no private endpoint, no geo-replication, persistence off, no firewall rules, TLS 1.2 only, access keys enabled.
  • Target: Azure Managed Redis, Balanced_B10, North Central US, created before the migration. Non-clustered, HA disabled, persistence off, access-key auth disabled, TLS. Provisioning Succeeded / Running.
  • Migration resource: skipDataMigration=false, switchDns=true. Validation passed twice.

Timeline (UTC) 2026-10-27

  • 17:27:38 Migration started from the portal Migrate pane
  • 17:27, 17:58, 18:28 On the source, configureMigrationAccess, getMigrationInfo and updateMigrationStatus ran at each 30-minute cycle and all succeeded
  • 18:59:40 Migration failed. The target never received any data (0 keys, 0 set commands).
  • 20:37:19 Cancel requested; disableMigrationAccess on the source succeeded at 20:38:43
  • 21:09, 21:39, 22:09 updateMigrationStatus on the source succeeded
  • 22:09:22 Cancel failed; the source moved to MigrationCancellationFailed 2026-10-28
  • 18:39:04 Rollback started once from the portal
  • 18:39, 19:09, 19:39 updateMigrationStatus on the source succeeded
  • 20:09:38 Rollback failed. The source never received a final status update and still shows MigrationCancelling.

Every attempt follows the same pattern: the status updates on the source every 30 minutes all succeed, then the operation on the target fails at about the fourth cycle (~90 minutes).

Errors (all on the target's migration resource)

  • migrations/write, Failed, 2026-10-27T18:59:40Z, correlationId 6c026531-0a75-47f6-bc50-7bdff50895f4
  • migrations/cancel/action, Failed, 2026-10-27T22:09:22Z, correlationId 1c728ecc-dc44-4a23-aed3-baec725106c8
  • migrations/cancel/action (rollback), Failed, 2026-10-28T20:09:38Z, correlationId dd440a69-22bb-41d5-828e-a110eb0cf4b7
  • All three: ResourceOperationFailure, "The resource operation completed with terminal provisioning state 'Failed'", details OperationFailed "The operation failed.", statusDetails null.

Current state (2026-10-28 21:09 UTC)

  • Migration resource: provisioningState CancellationFailed
  • Source cache: provisioningState MigrationCancelling
  • DNS was never switched: the source hostname still resolves to the source cache.

Questions

  1. Can the stuck migration state be cleared from the service side? Cancel and rollback both fail, and there is no other customer action for it.
  2. What do the backend logs show for the three correlation IDs above?
  3. Is data migration supported for a Standard source? The Learn page "Migration options - Basic, Standard, Premium" (updated 2026-08-18) says the tooling does not migrate data, but the portal offered a copy-data option, and Microsoft's amr-migration-skill repo documents data migration as opt-in for Azure Cache for Redis sources since 2026-10-12 (Private Link and clustered caches excluded).
  4. Is it safe to delete the target while the source is in this state?
Azure Cache for Redis
Azure Cache for Redis

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

0 comments No comments

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.