Azure Cache for Redis resource move stuck in provisioning state for over 72 hours

Morné Zaayman 91 Reputation points
2026-03-23T08:17:58.2166667+00:00

I initiated a resource move for an Azure Cache for Redis instance from one Resource Group to another, but the operation has been completely stuck for over 72 hours.

Fortunately, the data plane remains unaffected, and my applications can still connect to the cache. However, because this control-plane operation is hanging, Azure Resource Manager has permanently locked both my source and destination Resource Groups. I am currently unable to perform any management operations on the resources within either of those groups.

Since it has been more than 3 days, it appears the backend ARM operation is permanently stuck in a Moving provisioning state. I cannot force-cancel or restart this move from the Azure Portal without risking further issues.

I need assistance from a Microsoft support engineer to manually release the backend ARM locks and reset the Redis cache's provisioning state.

Service: Azure Cache for Redis

Operation: Resource Move (Resource Group to Resource Group)

Duration: > 72 hours

I am happy to provide my Subscription ID, the specific Resource Group names, and any other data related to the operation in a private message as soon as someone reaches out.

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
SAI JAGADEESH KUDIPUDI 3,650 Reputation points Microsoft External Staff Moderator
2026-04-14T13:41:42.22+00:00

Hi Morné Zaayman,
We sincerely understand the impact this issue may have caused and truly appreciate your patience while we worked on resolving it.

On March 18 around 05:38 UTC, the Azure Managed Redis cache (us-appn) encountered an issue where the cache became stuck in the Moving state. During this time, only the initial step of the move operation was completed, which set the cache provisioning state to Moving.

Due to a backend provisioning regression, the cluster move request was not processed further. As a result, the cache remained in the Moving state indefinitely, even though no active migration was actually in progress.

Our backend engineering team has successfully mitigated the issue by correcting the cache backend provisioning state. This allowed the cache to exit the Moving state and resume normal operations.

As a precautionary step, we are proactively monitoring for any reoccurrence of this behavior and are working towards implementing a permanent fix to prevent similar issues in the future.

Was this answer helpful?


0 additional answers

Sort by: Newest

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.