Azure Resource Mover: Fix Errors, Dependencies & Move Issues
Why This Is Happening
So you've opened Azure Resource Mover, selected the resources you want to shift to a new region, and hit a wall. Maybe it's a dependency validation error that gives you zero actionable detail. Maybe the move is stuck in "Prepare pending" and nothing you do unsticks it. Or maybe you're just staring at a greyed-out "Move" button wondering what invisible prerequisite you're missing. I've seen all of these , and I know exactly how maddening it is when your timeline depends on getting those workloads into a new region by end of quarter.
Here's the thing about Azure Resource Mover that nobody tells you upfront: the service is genuinely excellent at what it does, but it enforces a strict sequencing model. Every resource you want to move has a graph of dependencies, and the mover won't let you touch a resource until every dependency in that graph is either moved to the target region or explicitly replaced by an equivalent resource in that region. Miss one NIC, one NSG rule, one virtual network , and the whole operation stalls.
The most common reasons Azure Resource Mover fails or throws errors:
- Unresolved dependencies, you added VMs to the move list but not the virtual network or availability sets they depend on. Azure Resource Mover catches this during validation, but the error message doesn't always name the specific blocking resource clearly.
- Unsupported resource types, Azure Spot VMs, for example, are explicitly not supported. If you've selected one without realizing it, the move will fail at validation with no path forward except removing that resource from the move set.
- Region availability gaps, not every Azure service is available in every region. You might try to move an Azure SQL elastic pool to a target region that doesn't yet offer the tier you're running. The portal error for this is often generic.
- Cross-subscription confusion, many admins assume Azure Resource Mover handles subscription changes alongside region changes. It doesn't. Resource Mover moves resources across regions within the same subscription. Cross-subscription moves require a separate two-step process using Azure Resource Manager (ARM) after the regional move is complete.
- Public IP address retention expectations, this one catches people off guard constantly. Public IP addresses are not retained when you move across regions. Your resource gets a new public IP in the target region. If you have DNS records, firewall rules, or applications hard-coded to the old IP, those will break the moment you commit the move.
- Encryption configuration mismatches, Azure Resource Mover does support moving encrypted VMs, including those with Azure Disk Encryption and VMs using server-side encryption with both platform-managed and customer-managed keys. But if your key vault configuration isn't set up correctly in the target region, the move will fail mid-operation.
The frustrating reality is that Azure's error messages for Resource Mover issues tend to be high-level. You'll see "Move failed" or "Validation error" without the specific detail you need to fix it quickly. That's what this guide is for.
I've put together everything you need, from the fastest single fix to get a stalled move unstuck, through a complete step-by-step walkthrough of the correct Azure Resource Mover process, to advanced troubleshooting for enterprise environments. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If your Azure Resource Mover operation is failing and you don't want to read through a full guide right now, here's the single action that resolves the majority of move errors: run the dependency resolution tool from inside the Resource Mover hub before you attempt any move operation.
Here's how to do it fast:
- Open the Azure portal and search for Resource Mover in the top search bar.
- Select Azure Resource Mover from the results and click into the hub.
- In your active move collection, look at the resource list. Any resource showing a warning icon or "Issues" status has unresolved dependencies.
- Click the resource with issues, then click "Resolve dependencies" from the toolbar at the top of the resource list panel.
- The portal will scan the dependency graph and surface every blocking resource. You'll see a list, some items will be recommended for inclusion in the move, others will ask you to map to an existing resource in the target region.
- Work through each item. For most standard VM moves, you'll just click "Add to move" for each dependency and the hub handles the rest.
- Once all dependencies show a green checkmark, the Prepare button becomes active. Click it.
That sequence alone fixes the vast majority of Azure Resource Mover validation errors and "Prepare pending" hangs. The dependency resolution isn't optional, it's the engine that makes the whole process work. Skipping it or trying to work around it is why most moves fail.
If after resolving dependencies you're still seeing failures, keep reading. The steps below cover the full process in detail, including what to do when the dependency resolver itself throws an error.
Before anything else, you need to get your resources into a move collection inside the Resource Mover hub. This is where most people make their first mistake: they add only the top-level resources (say, a VM) and skip the supporting infrastructure. Let me walk you through doing this right from the start.
Navigate to the Azure portal and search for Resource Mover. On the main Resource Mover page, click "Move across regions". You'll be prompted to select:
- Your Source subscription
- Your Source region, the region your resources currently live in
- Your Destination region, where you want them to end up
Select your target region carefully. Not every Azure service is available in every region. If you're moving to a newly launched region specifically because it now offers something your workload needs, double-check that all your resource types are supported there before committing. A partially moved workload, VMs in the new region but SQL elastic pool stuck because the target region doesn't support that tier, is a painful situation to untangle.
Once you've set source and destination, click Next: Resources to move. You can add resources individually or filter by type. Add every resource you know you want to move. Then, and this is the key, click "Validate dependencies" immediately after adding your initial selection. Don't wait. The earlier you run validation, the more time you have to sort out what's missing.
You should see a status panel showing either green checkmarks (dependency resolved) or warning icons (issues to fix). Any resource in a warning state will block the move from progressing. Note down the resource names and types showing issues, you'll need that list for Step 2.
If validation completes cleanly on the first run, great, you're ahead of the curve. If not, that's normal. Proceed to Step 2.
This is the step that separates a successful Azure cross-region migration from a three-day debugging session. Dependency resolution in Azure Resource Mover is not a one-click thing, it's an iterative process, and you need to understand what you're deciding for each item.
In the Resource Mover hub, select all resources showing issues, then click "Resolve dependencies" in the top toolbar. The panel that appears shows you a dependency map. For each dependency, you have two choices:
- Add the dependent resource to the move, this brings it into your move collection so it gets relocated to the target region alongside everything else. This is the right choice when the dependent resource (say, a virtual network) exists only in the source region and needs to be recreated in the target.
- Use an existing resource in the target region, if you already have a virtual network or NSG set up in the destination region that the moved VM can connect to, you can map the dependency to that existing resource instead of moving the source one. This is useful when you're doing a phased migration and the target environment is already partially built out.
Work through every dependency. Common ones for Azure VM moves include: the VM's associated disks (moved automatically as part of the VM, you don't select disks separately), Network Interface Cards (NICs), the virtual network the NIC connects to, Public IP addresses, Network Security Groups, and any Availability Sets.
For Azure SQL database and elastic pool moves, the dependencies are different, primarily the logical SQL server the databases live on. You'll need to include the server in the move or have an equivalent in the target region.
After you've addressed every item in the dependency panel, click "Validate" again. Run it a second time as I mentioned in the Pro Tip above. Once every resource in your collection shows a green status, you're ready to prepare.
One thing to sort out now rather than later: your Public IP addresses. Moving across regions means your existing public IPs are not retained, the documentation is explicit about this. Before you move, document every public IP you're currently using, what DNS records point to them, and which applications or firewall rules reference them. You'll need to update all of those after the move commits.
With dependencies resolved and all resources showing clean validation, you're ready for the Prepare phase. This is where Azure Resource Mover creates the infrastructure definitions for your target region, it does not actually move anything yet. Think of it as drawing the blueprint for what will exist in the destination before a single byte is transferred.
In the Resource Mover hub, select all your resources and click "Prepare". The portal will show a confirmation panel, review it, then click Prepare to confirm. This kicks off a background job that typically takes several minutes for small resource sets and longer for larger ones. You can watch the status column update in real time.
During this phase, you also get the chance to configure target-specific settings. For each resource in the move list, click into it to see its Target configuration panel. This is where you can:
- Change the target resource name (by default Resource Mover appends "-move" to the source name)
- Select the target resource group, either an existing one in the target region or create a new one
- For VMs: choose whether to move to a specific availability zone or availability set within the target region, or to no specific zone
- For virtual networks: review and adjust address spaces and subnets as needed for the target environment
This is your last clean opportunity to adjust names and configurations before the actual move begins. Once resources move to the target region, renaming or restructuring them requires additional operations.
If the Prepare operation fails, the most common causes are:
- Insufficient permissions on the target subscription or resource group, you need Contributor role or higher
- Resource quotas exceeded in the target region, check your subscription's quota for the target region in Subscriptions > Usage + Quotas
- Policy violations, if your organization has Azure Policy assignments blocking certain resource configurations in the target region
Once Prepare completes successfully, all resources should show status "Prepare succeeded". You're now ready for the actual move operation.
Here's where the actual cross-region move of Azure resources happens. Azure Resource Mover's design gives you a safety valve here that I genuinely appreciate: you can kick off the move, see that everything landed correctly in the target region, and then decide whether to commit permanently or discard and roll back. That testing window is one of the best reasons to use Resource Mover over manual migration methods.
In the hub, select all resources showing "Prepare succeeded" and click "Initiate move". Confirm in the panel that appears. This is the operation that actually creates and populates resources in your target region. For VMs, this can take anywhere from a few minutes to over an hour depending on disk sizes and region pair proximity.
While the move is running, watch the status column. You want to see each resource transition through:
- Move initiated
- Move in progress
- Commit pending
When resources reach "Commit pending," they exist in both the source and target regions. This is your testing window. Open the target region resources in the portal, validate connectivity, check that your applications start correctly, verify disk data integrity. If you have a test plan, run it now.
If everything looks good: Select all resources in "Commit pending" and click "Commit move". This finalizes the move. The resources are now permanently in the target region.
If something is wrong: Click "Discard move" instead. This rolls back and removes the target-region resources that were created. Your source-region resources remain untouched. You can then diagnose the issue, adjust your configuration, and try again. This is risk-free, use the discard option without hesitation if you're not satisfied with the result.
After commit, all resources should show "Commit succeeded". Your workloads are now running in the target region.
After a successful commit, your resources exist in the target region and, unless you've already decommissioned them, they also still exist in the source region. You're paying for both right now. Resource Mover gives you an automated cleanup path, but you should validate before you delete.
Before touching source resources, run through this checklist:
- Update all DNS records that pointed to old public IP addresses to the new IPs assigned in the target region
- Update any firewall rules, Network Security Group rules, or third-party security appliances that referenced the old IPs
- Verify application connection strings point to the new resource locations, especially critical for Azure SQL database moves where the server endpoint changes
- Confirm backup policies are configured in the target region (Azure Backup vault configurations don't move automatically)
- Check monitoring and alerting, Azure Monitor alert rules tied to source-region resources won't automatically transfer
Once you're satisfied, return to the Resource Mover hub. Select the resources showing "Commit succeeded" and click "Delete source". Review the list carefully, this operation is not reversible. Confirm, and Azure will delete the source-region instances of those resources.
You can also choose to skip the automated delete and handle source cleanup manually through the source resource groups if you prefer more granular control. Either approach works.
After cleanup, verify your move collection in the Resource Mover hub shows all resources as completed. Check your billing in Cost Management to confirm you're no longer being charged for the source-region resources. Cross-region Azure Resource Mover moves are now complete.
If you're planning to move the resources to a different subscription now that they're in the correct region, that's your next step, use Azure Resource Manager (ARM) through the standard resource group move process. Azure Resource Mover handles the region portion; ARM handles the subscription change after.
Advanced Troubleshooting
If the standard steps above didn't resolve your Azure Resource Mover issue, here's where to dig deeper. These scenarios come up less often but they're significantly harder to diagnose without knowing where to look.
Move Stuck in "Prepare Pending" or "Move Pending" for Hours
This usually means a background ARM operation is hung. Open the Azure portal, go to Subscriptions > [your subscription] > Activity log, and filter by the time range of your move attempt. Look for failed or "Running" operations tied to the Resource Mover resource group (it creates a resource group called ResourceMoverRG or similar in your source region). If you see a stuck operation, you may need to cancel it explicitly via Azure CLI:
az resource-mover move-collection initiate-move \
--name "YourMoveCollection" \
--resource-group "ResourceMoverRG" \
--move-resources "/subscriptions/{sub-id}/resourceGroups/{rg}/providers/Microsoft.Compute/virtualMachines/{vm-name}"
NSG and Virtual Network Dependency Deadlocks
Virtual networks with complex NSG configurations sometimes create circular dependencies in the resolver, the VNet needs the NSG, and the NSG is scoped to the VNet. The workaround is to create a placeholder NSG in the target region manually before running the move, then map the dependency to that existing NSG rather than moving the source NSG. After the move completes and the VMs are running in the target region, apply your full NSG rules to the target NSG.
Encrypted VM Move Failures
Azure Resource Mover supports moving encrypted VMs, including those with Azure Disk Encryption and server-side encryption with customer-managed keys, but key vault access must be set up in the target region first. The move will fail if the VM's encryption key can't be accessed during the replication phase. Set up your key vault in the target region, grant the Resource Mover managed identity access, and then retry the Prepare operation.
Quota Limits in Target Region
If your Prepare step fails with a quota error, go to Subscriptions > Usage + Quotas in the portal. Filter by the target region and the resource type failing (usually compute cores or public IP addresses). Submit a quota increase request, Microsoft typically processes these within one business day for standard increases. Don't attempt to move resources you don't have quota for; the move will fail mid-operation and leave partial resources in the target region that need manual cleanup.
Azure Policy Blocking the Move
Enterprise subscriptions often have Azure Policy assignments that enforce naming conventions, tag requirements, or allowed resource configurations. If a policy in the target region's management group blocks the resource configuration you're trying to create, the move will fail at Prepare or at Commit. Check Policy > Compliance filtered to the target resource group to see which policies are non-compliant. Either adjust your target resource configuration to meet the policy, or work with your governance team to create a policy exemption for the duration of the migration.
Escalate to Microsoft Support when: your move has been in "Move in progress" for more than 24 hours with no status change; when the Activity Log shows an internal ARM error (HTTP 500) rather than a configuration error; when you've lost access to the Resource Mover hub after a move failed mid-operation; or when resources appear to exist in both regions but neither the commit nor discard option is available in the portal. Have your move collection name, source/target region names, and the specific resource names ready when you open the case, it cuts resolution time significantly.
Prevention & Best Practices
The best Azure Resource Mover experience is one where you've done the preparation work before you ever click "Initiate move." I know that sounds obvious, but the planning phase is where most cross-region migration problems actually originate, the move just surfaces them later at the worst possible moment.
Map your full dependency graph before you start. Before you even open the Resource Mover hub, draw out (or document in a spreadsheet) every resource you plan to move and its dependencies. For a standard three-tier application this means: VMs, their NICs, the virtual network and subnets, NSGs, load balancers, public IPs, availability sets, and any Azure SQL databases. Going in with a complete picture means you add everything in one shot and the dependency resolver confirms your list rather than surprising you with additions.
Check target region service availability first. Before you commit to a target region, verify that every resource type and tier you're running is available there. Some newer Azure services or specific VM SKUs have limited regional availability. A quick check in Azure documentation or the portal's region picker for each resource type saves you from discovering a blocking incompatibility after you've started the move.
Plan for the public IP change. Since public IPs are never retained across regions, treat the IP change as a known, planned event rather than a surprise. Build a pre-move runbook that lists every external system that references your current IPs and what needs updating. Schedule DNS TTL reductions a day before the move so propagation is faster after commit.
Do a test move on non-production first. If you have a staging or development environment running a similar architecture, move that one first. The process is identical and you'll discover any environment-specific issues, policy conflicts, quota gaps, encryption config problems, without risking production. The discard option means there's zero permanent impact if the test move reveals something unexpected.
Document the two-step process for cross-subscription moves. If your eventual goal is both a region change and a subscription change, get the order right from the start: use Azure Resource Mover for the region change first, then use ARM for the subscription change afterward. Trying to do both simultaneously is not supported and will cause confusion and errors.
- Reduce DNS TTL to 60 seconds at least 24 hours before your move date so IP changes propagate quickly after commit
- Pre-create the target resource group and apply your tags and naming conventions before starting, it's faster than configuring them per-resource in the mover
- Set up Azure Monitor alerts in the target region before committing the move so monitoring is active from minute one
- Screenshot or export your source NSG rules and routing table configurations before moving, recovery is much faster if you need to re-create anything in the target region
Frequently Asked Questions
Why should I use Azure Resource Mover instead of just rebuilding my resources in the new region manually?
Manual rebuilds work, but they're slower, more error-prone, and you carry 100% of the dependency tracking burden yourself. Azure Resource Mover gives you a single hub where everything related to your move, dependencies, status, commit/rollback, is in one place. The dependency validation catches things you'd miss manually, and the discard option lets you test the move before it's permanent. For anything beyond a single VM, the time savings from using Resource Mover over manual methods are real. That said, for resource types not supported by Resource Mover (anything outside VMs, disks, NICs, availability sets, virtual networks, public IPs, NSGs, load balancers, and Azure SQL databases/elastic pools), you'll need manual methods or alternative migration tooling.
What resources can I actually move with Azure Resource Mover, is my resource type supported?
Azure Resource Mover currently supports: Azure VMs and their associated disks (including encrypted VMs), Network Interface Cards, Availability Sets, Azure Virtual Networks, Public IP addresses, Network Security Groups, internal and public load balancers, and Azure SQL databases and elastic pools. Azure Spot VMs are explicitly not supported, if you have Spot VMs in your move set, you'll need to remove them and handle those separately. For anything outside this list, Microsoft publishes availability zone migration guidance and Azure services relocation guidance that covers manual and alternative migration paths for other resource types.
Can I move Azure resources to a different subscription at the same time as moving them to a different region?
Not in a single operation, no. Azure Resource Mover handles region changes within the same subscription only. If you need both a region change and a subscription change, it's a two-step process: first move the resources to the target region using Azure Resource Mover, then use Azure Resource Manager (ARM) to move them to the target subscription once they're in the right region. The good news is that ARM's cross-subscription move capability is solid and well-documented, it's just a separate operation you do after the Resource Mover step is complete and committed.
Can I move Azure resources to any region, or are some regions blocked?
You can move resources between any public Azure regions and within regions in China. Azure Government moves are also supported, specifically US DoD Central, US DoD East, US Gov Arizona, US Gov Texas, and US Gov Virginia. However, US Sec East, US Sec West, and US Sec West Central are not currently supported by Resource Mover. The metadata that Resource Mover uses during the operation is stored in specific regions: East US2, North Europe, Southeast Asia, Japan East, UK South, Australia East, and for China operations, China North2. This doesn't affect where your resources end up, it only affects where the mover's operational data is temporarily stored.
Can I move Azure managed disks independently using Resource Mover?
No, you can't select disks as standalone resources to move in Azure Resource Mover. Disks are automatically included and moved as part of their parent virtual machine move. When you add a VM to your move collection and the dependency resolver runs, it handles the disk inclusion automatically. If you need to move a disk that isn't attached to a VM, that falls outside Resource Mover's scope and you'd need to use snapshot-based methods or Azure Backup to get the disk data into the target region.
What happens if I discard a move after initiating it, do I lose anything?
No, discarding a move is safe. When you initiate a move, Azure Resource Mover creates new resource instances in the target region but leaves your source-region resources completely intact and running. The "Commit pending" state is your opportunity to validate everything in the target region. If something isn't right, wrong configuration, application issues, connectivity problems, click Discard and the target-region resources that were created during the move are removed. Your source-region resources continue running as if nothing happened. You can then adjust your configuration and try the move again. This testing capability is one of the strongest reasons to use Resource Mover over any manual migration approach.