Azure Resource Mover: What Actually Moves, What Doesn’t

Shannon
Dec 12, 2025
5 min read

Updated: Feb 20

All sample PowerShell companion code for this blog can be found here.

Azure has plenty of tools that do one thing really well, and Azure Resource Mover fits right into that category. If you need to move supported resources across regions without rebuilding from scratch, this is your tool. The trick is knowing what it was built for, what it refuses to touch, and how to use it without creating a surprise outage.

This guide walks through what Resource Mover is good at, what it is not, how to use it step by step, and how to take it from “basic region move” to “repeatable and automated process your future self will actually thank you for.”

What Azure Resource Mover Is Good For

Resource Mover handles the messy logistical parts of region to region relocation. You pick your source region, pick your target region, and let Azure handle the creation of matching resources on the other side.

Great scenarios include:

Region consolidation
Moving workloads closer to users or dependencies
Shifting resources after organizational or compliance changes
Migrating from older to newer Azure regions

Services that tend to behave well in Resource Mover:

VMs
VNets, NSGs, subnets
Public IPs
Load balancers
Availability sets
Some storage accounts
Private endpoints
Key Vaults in limited cases

This tool shines when you stay inside supported territory.

What Azure Resource Mover Is Not Meant To Do

Here is the stuff it does not do, no matter how charmingly you ask.

It does not move tenants or subscriptions.
Different tools. Different workflows.
It does not move every PaaS service you know and love.
App Services, Cosmos DB, Synapse, and anything with complex identity or networking layers usually require a manual pattern.
It does not handle data replication for you.
Metadata moves. Your data must be copied, restored, or replicated by you.
It does not orchestrate end to end migrations.
Think of this tool as region relocation. Not an enterprise migration engine.

If you treat it as a focused tool instead of a magical one, it works extremely well.

How To Use Azure Resource Mover

Here is the flow in a way that mirrors what you actually do in PowerShell. Note, I've just been in PowerShell a bunch as of late, which is why my hands on example surrounds PowerShell for this blog. If you want to view alternate instructions, please reference the links at the end of this blog!

Step 0. Get Your Subscription GUID and Set the GUID as a Variable

Get-AzSubscription
$subId = (Get-AzSubscription -SubscriptionName "MySubName").Id

Step 1. Register the provider

Register-AzResourceProvider -ProviderNamespace Microsoft.Migrate

Step 2. Create a Move Collection

New-AzResourceMoverMoveCollection `
  -Name "eastus-to-centralus-move" `
  -ResourceGroupName "rg-move" `
  -Location "EastUS"

Step 3. Add resources to the collection

Add-AzResourceMoverMoveResource `
  -MoveCollectionName "eastus-to-centralus-move" `
  -ResourceGroupName "rg-move" `
  -Location "EastUS" `
  -ResourceId "/subscriptions/$subId/resourceGroups/app-rg/providers/Microsoft.Compute/virtualMachines/app01"

Step 4. Resolve dependencies

Resolve-AzResourceMoverMoveCollectionDependency `
  -MoveCollectionName "eastus-to-centralus-move" `
  -ResourceGroupName "rg-move"

Azure will tell you which NICs, NSGs, VNets, and public IPs need to come along.

Step 5. Prepare the move

Invoke-AzResourceMoverPrepare `
  -MoveCollectionName "eastus-to-centralus-move" `
  -ResourceGroupName "rg-move"

Step 6. Commit the move

Invoke-AzResourceMoverCommit `
  -MoveCollectionName "eastus-to-centralus-move" `
  -ResourceGroupName "rg-move"

At this point your resources exist in the target region. Validate and test everything.

Step 7. Clean up

Delete or retire source resources once you are comfortable.

Advanced How To

This is the part that actually levels up your use of Azure Resource Mover. Most people never move past clicking buttons in the portal. You can take this much further.

Option 1. Automate dependency resolution with PowerShell

Azure Resource Mover will happily surface every missing dependency. The trick is automating the process so you do not manually chase NICs, NSGs, or VNets.

Here is a simple pattern to loop through unresolved dependencies and add them:

$collection = Get-AzResourceMoverMoveCollection `
    -Name "eastus-to-centralus-move" `
    -ResourceGroupName "rg-move"

$dependencies = Get-AzResourceMoverRequiredForMove `
    -MoveCollectionName $collection.Name `
    -ResourceGroupName "rg-move"

foreach ($item in $dependencies) {
    Add-AzResourceMoverMoveResource `
        -MoveCollectionName $collection.Name `
        -ResourceGroupName "rg-move" `
        -Location "EastUS" `
        -ResourceId $item.ResourceId
}

This turns your “resolve dependencies” click fest into something predictable.

Option 2. Combine Resource Mover with Azure Policy

Before you move a single resource, make sure the landing zone is compliant. Resource Mover will not magically make your NSGs or storage accounts meet corporate standards.

For example, you can assign a policy that requires:

Diagnostic settings
Approved SKUs
No public IP creation without justification
Encryption settings

Quick example of assigning a policy definition to your target region resource group:

New-AzPolicyAssignment `
  -Name "target-region-hardening" `
  -Scope "/subscriptions/$subId/resourceGroups/centralus-landingzone" `
  -PolicyDefinition (Get-AzPolicyDefinition -Name "audit-vm-managed-disks")

You now validate your target region before you move anything.

Option 3. Export post-move resources as ARM or Bicep

Once resources land in the target region you can export them as templates. This gives you a clean baseline of what “good” looks like after the move.

Export-AzResourceGroup `
  -ResourceGroupName "centralus-app-rg" `
  -Path "C:\templates\centralus-app.json"

You now have a gold copy of your post move architecture.

Option 4. Wrap everything into an Automation Runbook or pipeline

This is where you turn region realignment into a repeatable workflow.

Runbook example flow:

Validate source region resources
Validate target region with Azure Policy
Create move collection
Add resources
Auto resolve dependencies
Prepare
Commit
Notify your team
Export final state templates
Clean up source resources

You can script all of this with PowerShell inside Azure Automation or GitHub Actions.

A simple runbook starter:

Write-Output "Starting region move for app01"

# Create collection
New-AzResourceMoverMoveCollection -Name "auto-move" -ResourceGroupName "rg-move" -Location "EastUS"

# Add VM
Add-AzResourceMoverMoveResource -MoveCollectionName "auto-move" -ResourceGroupName "rg-move" -Location "EastUS" -ResourceId "/subscriptions/$subId/vm/app01"

# Dependency resolution
Resolve-AzResourceMoverMoveCollectionDependency -MoveCollectionName "auto-move"     -ResourceGroupName "rg-move"

# Prepare
Invoke-AzResourceMoverPrepare -MoveCollectionName "auto-move" -ResourceGroupName "rg-move"

# Commit
Invoke-AzResourceMoverCommit -MoveCollectionName "auto-move" -ResourceGroupName "rg-move"

Write-Output "Region move complete"

If you built this similarly, you have just turned a manual region move into infrastructure choreography.

Wrap Up

Azure Resource Mover is not a replacement for good architecture, but it is an incredibly useful tool when you need to shift supported resources from one region to another. The basic workflow gets you through most scenarios, but the real power comes when you layer automation, compliance, and template management on top of it.