Azure Resource Mover / ARM Move Operations Occasionally Stuck for Hours – Request for Self-Service Recovery Option

Hello Tanishq Bansal,

Below is the investigation provided by our support team.

1. Problem Statement What: Customer is attempting to move Azure resources from one subscription to another and is asking whether there is any way to manually cancel, delete, or reset the move operation while it is stuck in an In Progress state instead of waiting for the timeout period.

Where: Azure Resource Manager (ARM) resource move operation across subscriptions.

When: Issue observed starting around 03/06/2026 18:30 UTC, during an active resource move request.

Who: Customer using Azure Portal / ARM under Azure Support Plan – Developer.

2. Support Boundaries & Success Criteria Desired Outcome: Customer wants to manually cancel or intervene in an ongoing ARM move operation without waiting for the automatic timeout.

In Scope:

Clarifying supported ARM behavior for resource move operations

Explaining timeout behavior and retry options after completion/failure

Setting correct expectations based on platform design

Out of Scope:

Manual cancellation, reset, synchronization, or backend intervention for active ARM move operations

Anyx backend or Product Group recovery actions not exposed or supported

Success Criteria: Customer understands that ARM move operations cannot be manually canceled or forced and that the only supported behavior is to wait for the automatic timeout before retrying. 

3. Business Impact Urgency: Low to Medium

Deadline: Dependent on ARM automatic timeout (~4 hours per design).

Impact: Operational delay while waiting for the move operation to time out before retrying the action.

4. Troubleshooting Data Required:

Subscription ID: <Provided by customer in support ticket>

Tenant ID: <Provided by customer in support ticket>

Move operation status showing In Progress

Repro Steps:

Initiate a resource move from one Azure subscription to another.

Observe the move operation remaining in In Progress state.

Attempt to find a way to manually cancel or reset the operation before timeout.

 

Hello Tanishq Bansal,

Thank you for reaching out to the Microsoft Q&A forum.

Your understanding of the situation is largely correct: Azure Resource Mover operations are executed as Azure Resource Manager (ARM) long-running operations, and when the operation state in ARM becomes inconsistent, support engineers run internal repair/sync workflows that are not exposed to customers. Below is the realistic picture based on how ARM and Resource Mover work internally.

1. Is there a customer-side way to trigger an “ARM Sync”?

No — there is currently no supported API, CLI, or PowerShell command that performs the backend “ARM Sync” or state repair.

The operation that support calls ARM Sync is an internal Azure control-plane repair action used when:

• The ARM async operation record is stuck
• The Resource Provider (RP) state and ARM state diverge
• The operation lock in ARM’s transaction layer isn’t released

These repair operations are restricted to Microsoft backend tooling because they can modify ARM transaction records directly.

2. Can customers cancel a stuck move operation?

Unfortunately not reliably once the operation enters the ARM transaction stage.

Once MoveResources or Resource Mover commit move begins, ARM treats it as a transactional long-running operation.

Available actions are limited.

What you can do

You can inspect the operation:

CLI

az monitor activity-log list --correlation-id <correlationId>

Check ARM async operation

GET https://management.azure.com/providers/Microsoft.Resources/operations/{operationId}?api-version=2021-04-01

Check deployment operations

az deployment operation group list \    --resource-group <rg> \    --name <deploymentName>

If the operation eventually fails, you regain control automatically.

 

3. Why this happens (common root causes)

From real migration scenarios, stuck moves usually occur due to:

1. Resource provider lock contention

When multiple providers are involved:

• Compute
• Network
• Storage
• Managed Identity
• Key Vault

If one RP does not respond to ARM's commit callback, the move remains pending.

 

2. ARM async operation record desync

The backend systems that track operations include:

• ARM Frontdoor
• ARM LRO store
• Resource Provider operation state
• ARM transaction manager

If any state becomes inconsistent, the operation remains “In Progress” forever until repaired.

3. Cross-subscription policy evaluation delays

Large enterprise tenants often have:

• Azure Policy
• Deny assignments
• RBAC propagation delays

During move commit these are reevaluated.

4. Dependent resource graph complexity

Moves with many dependencies can trigger long locks:

Example:

VM NIC Public IP NSG Load Balancer Disk Managed Identity Private Endpoint

Resource Mover orchestrates these sequentially.

4. Operational practices that reduce the risk

These are the most effective mitigations used by large Azure migration teams.

1. Reduce batch size

Avoid moving large resource sets at once.

Recommended:

10–20 resources per move group

Instead of:

100+ resources in one transaction

This drastically lowers ARM transaction complexity.

2. Separate network resources

Network resources often cause the most issues.

Move in phases:

Phase 1 - VNets - NSGs - Route tables Phase 2 - NICs - Public IPs Phase 3 - VMs - Disks

3. Pre-validate dependencies

Run:

az resource invoke-action \    --action validateMoveResources \    --ids /subscriptions/<sub>/resourceGroups/<rg> \    --request-body @resources.json

This catches hidden dependencies.

4. Avoid parallel move operations

Running multiple move operations in the same subscription increases lock contention.

Recommended:

One move commit per subscription at a time

5. Monitor the ARM operation directly

Capture the operation ID when executing moves.

Example response header:

Azure-AsyncOperation Operation-Location x-ms-correlation-request-id

Track it using:

GET Azure-AsyncOperation URL

This helps detect stuck states earlier.

6. Is Microsoft planning self-service recovery?

There is no public roadmap yet for exposing this capability.

The challenge is that ARM sync operations can:

• Override resource provider state
• Break transactional guarantees
• Cause partial moves

So Microsoft keeps it internal for safety.

However, large enterprise customers have been requesting this, especially migration teams.

7. Workaround used by large migration teams

Teams that migrate hundreds of subscriptions typically build automation that:

Detects stuck operations automatically

Example logic:

If operation state = InProgress AND duration > 45 minutes THEN   trigger escalation workflow

Automation:

• Collect correlation ID
• Capture activity logs
• Open support ticket automatically

This reduces manual delay.

8. What would help you the most (recommended feature request)

Many Azure architects recommend Microsoft expose:

POST /providers/Microsoft.Resources/operations/{id}/repair

Or

az resource repair-operation

This would allow safe resync of ARM operation state.

You may want to submit this to:

• Azure Feedback Portal
• Microsoft Account Team / CSA
• Resource Mover product team

9. One important hidden check (often missed)

Before large migrations ensure all providers are registered in the destination subscription:

az provider list --query "[?registrationState!='Registered']"

If any required RP registers during the move, it can stall operations. 

Let me know if you have any questions?

 

Hi Siva shunmugam Nadessin,

Thanks for the answer.

But the issue still persists. I grabbed 80% of this info from the Copilot.

And sorry to intervene but your below point is wrong.

Separate network resources Network resources often cause the most issues. Move in phases: Phase 1 - VNets - NSGs - Route tables Phase 2 - NICs - Public IPs Phase 3 - VMs - Disks

This is wrong because we cannot move resources in phases without their dependencies.

For example- If we need to move VM, we must select disk, nsg, nic, ip, vnet alongwith.

I totally understand the situation over here that this is an internal control plane repair option, and not exposed to the public/customers.

But there must be some workaround to refresh the resources/resource groups so that their state is drawn out of the move operation. Or somehow if we can set the Auto Cancel/Sync if the move operation is not completed in 15 mins.

Because as per my knowledge, Azure auto runs ARM Sync every 4-5 hours. So if somehow, if we can arrange a Auto Cancel/Sync for the duration of the migration maintenance window [even if a support ticket is required prior to the window], that will work. Because the issue is that Microsoft support to too slow even with Severity A support.
Engineer is assigned , we make him understand the issue, he forwards the query to ARM support department, they run ARM SYNC, this whole process takes 2-3 hours. So it's of no use, because it will be getting auto solved in an additional hour automatically by the periodic Auto Sync of 4 hours.

We need a solution because this issue is becoming regular, instead of rare case. Even yesterday we had 3 migrations scheduled for clients at different times and we faced this issue 8-10 times in total in a single day.

Our business is getting hampered too much.

Please suggest me something-

But there must be some workaround to refresh the resources/resource groups so that their state is drawn out of the move operation. Or somehow if we can set the Auto Cancel/Sync if the move operation is not completed in 15 mins.

Hello Tanishq Bansal,

You mentioned you have created Sev-A support ticket kindly share us the support ticket # for us to check with correct team from backend?

Hello Tanishq Bansal,

After reviewing this scenario internally, I would like to clarify the supported behavior of Azure Resource Manager (ARM) move operations.

When a resource move becomes stuck in an In Progress state, there is no supported customer‑side or backend mechanism to manually reset, synchronize, or force complete the operation. ARM move requests are long running transactional operations and are designed to automatically time out after approximately 4 hours.

Once the timeout occurs, the operation either fails or completes, after which the move can be retried if required. There is no supported way to cancel or intervene in an active move request before this timeout.|

Any references to manual “ARM sync” or backend recovery actions are not part of a supported or exposed recovery process.

Please let us know if you have any questions or further requests regarding this behavior; our support engineer will be waiting for your feedback, and if there are no additional questions or actions required, please confirm.