Failed to start virtual machine 'sh-avd-0'. Error: The resource group 'rg-avd' is being updated and cannot perform this operation.

When you encounter the error stating that the resource group 'rg-avd' is being updated and cannot perform the operation, it typically indicates that the resource group is still undergoing a move or update operation. This can happen if the move process is taking longer than expected, or if there are dependencies that are still being resolved.

Here are some steps you can take to troubleshoot this issue:

1. Check the Provisioning State: You have already done this using the command az group show -n rg-avd --query "properties.provisioningState" -o tsv. If it shows MovingResources, it confirms that the operation is still in progress.
2. Wait for Completion: Sometimes, the operation may take longer due to various factors such as the size of the resources being moved or the current load on Azure services. It is advisable to wait for a while and check the provisioning state again.
3. Review Activity Logs: Check the Azure Activity Logs for any errors or warnings related to the move operation. This can provide insights into what might be causing the delay.
4. Contact Azure Support: If the resources remain in the MovingResources state for an extended period, consider reaching out to Azure support for assistance. They can provide more detailed information about the status of the operation and help resolve any underlying issues.

In summary, the error indicates that the resource group is still being updated, and it may require some time to complete the operation before you can start the virtual machines again.

Hello Joey Verlinden

Thank you for posting your query on Microsoft Q&A platform.

You used the native Azure Resource Manager move ("Move to another subscription/resource group” in the portal). During this operation, Azure locks both the source and the target resource groups. While locked, write/update/delete operations are blocked (starting a VM is a write), even though the resources continue to run. The lock can last up to four hours and is lifted when all provider notifications complete. This behavior is by design.

The REST path you quoted that includes moveResources/{yourMoveCollectionName}/cancel is for Azure Resource Mover (region moves), which uses move collections. It does not apply to the native subscription/resource‑group move (no move collection exists in that scenario).

As a resolution let the platform complete or timeout (max ~4 hours):

The RG lock should automatically clear when the move finishes or fails in backend notification phases. If you are still seeing MovingResources beyond the four‑hour window, proceed with steps 2–4.

Check control‑plane evidence in Activity Log:

Use the Activity Log to confirm whether the move operation succeeded, failed, or is still running for rg-avd.

In the portal: Monitor → Activity log, filter on the resource group and the last 6–8 hours.

 az monitor activity-log list \   --resource-group <> \   --max-events 50 \ 

Eliminate common blockers and confirm eligibility:

Locks/Policies: Ensure there are no read‑only locks on source/destination RGs/subscriptions and no policy/deny assignments preventing updates. The move cannot proceed if a read‑only lock exists.

Same tenant & provider registration: Verify both subscriptions are active and under the same Microsoft Entra tenant, and that the destination subscription is registered for the relevant resource providers.

Starting a VM requires an update on a resource group. Because the RG is locked by the in‑progress move, Azure blocks the operation until the lock is cleared or the move times out.

Thanks,

Suchitra.