Relocating a production workload to another Azure region: a checklist for capacity, data, identity, DNS and cutover

Moving a workload to another region is not a resource move. Almost nothing moves in place. You build a parallel stack in the target region, replicate the data, switch traffic over and remove the old stack. Most problems come from things that stay tied to the source region: regional managed identities, firewall allow-lists with old egress IPs, private DNS records and globally unique names.

Use this checklist in order. Every phase ends with a gate.

#Phase 1: inventory everything the workload touches

• List every resource in the workload's resource groups, including the ones nobody remembers:

az graph query -q "Resources
  | where resourceGroup in~ ('rg-orders-prod', 'rg-orders-data')
  | project name, type, location, sku = tostring(sku.name), id
  | order by type asc" --first 1000 -o table

• Find dependencies outside those groups: private endpoints pointing at your resources, role assignments, shared hubs, Log Analytics workspaces, Front Door origins, DNS zones.

# Private endpoints anywhere that connect to resources in the workload's groups
az graph query -q "Resources
  | where type =~ 'microsoft.network/privateendpoints'
  | mv-expand c = properties.privateLinkServiceConnections
  | extend target = tostring(c.properties.privateLinkServiceId)
  | where target contains '/resourceGroups/rg-orders-'
  | project peName = name, peRg = resourceGroup, target" -o table

# Role assignments granted to or on the workload
az role assignment list --all --query "[?contains(scope, '/resourceGroups/rg-orders-')].{role:roleDefinitionName, principal:principalName, scope:scope}" -o table

• Record outbound public IPs (NAT Gateway, firewall, App Service outbound addresses) that partners or SaaS providers have on allow-lists.
• Record inbound IPs and hostnames that clients have hard-coded or allow-listed.

Gate: a dependency list that the application owner has signed off.

#Phase 2: confirm the target region can host it

• Every resource type and API version is available in the target region:

az provider show -n Microsoft.Web \
  --query "resourceTypes[?resourceType=='sites'].locations" -o tsv | tr '\t' '\n' | grep -i "sweden central"

• VM and node SKUs are offered, in the zones you need, without restrictions for your subscription:

az vm list-skus -l swedencentral --size Standard_D8s_v5 \
  --query "[].{sku:name, zones:locationInfo[0].zones, restricted:restrictions[].reasonCode}" -o table

• Quota is enough for both stacks running at once during the overlap:

az vm list-usage -l swedencentral \
  --query "[?contains(name.value, 'DSv5') || name.value=='cores'].{name:name.localizedValue, used:currentValue, limit:limit}" -o table

• Features you rely on are available there: zone redundancy for each PaaS service, Premium SSD v2, availability of specific AI models, ExpressRoute peering locations close to the region.
• Data residency and compliance approval covers the target region.

Gate: quota requests approved and SKUs confirmed. Do not start building on assumptions.

Tip

Capacity for large or GPU SKUs is not guaranteed even with quota. For critical sizes, consider an on-demand capacity reservation in the target region before cutover, and check current pricing.

#Phase 3: names, identities and things that do not move

Gate: IaC for the target stack deploys cleanly into an empty resource group with what-if reviewed.

#Phase 4: replicate the data

Pick one method per data store and measure how long it takes to catch up before you set a cutover date.

# Example: SQL geo-replica and failover group to the target server
az sql failover-group create -g rg-orders-data -s sql-orders-weu \
  --partner-server sql-orders-sdc --name fog-orders --add-db orders \
  --failover-policy Manual

# Example: incremental blob copy between accounts (repeat until the delta is small)
azcopy sync "https://storderswe.blob.core.windows.net/invoices" \
  "https://storderssdc.blob.core.windows.net/invoices" --recursive --delete-destination=false

Gate: each store has a measured lag, and the final catch-up fits inside the agreed cutover window.

#Phase 5: rewire network and access

• Target VNet address space does not overlap with on-premises or with any peered VNet, including the source.
• Hub connectivity (peering, Virtual WAN, ExpressRoute or VPN) is in place and tested from on-premises to the target subnets.
• New private endpoints are created and resolve correctly from every client network: nslookup <name>.privatelink... returns the new IP.
• New outbound IPs have been sent to partners and added to their allow-lists before cutover.
• Firewall rules, NSGs and route tables are deployed from the same code as the source.
• Secrets and connection strings in the target point at target-region endpoints, not the source.

#Phase 6: cutover

• Lower DNS TTLs at least one old-TTL period before the window:

az network dns record-set cname update -g rg-dns -z contoso.com -n orders --set ttl=60

• Freeze writes or put the app into maintenance mode.
• Final data catch-up, then planned failover (for example az sql failover-group set-primary -g rg-orders-data -s sql-orders-sdc -n fog-orders).
• Switch traffic: Front Door origin weights, Traffic Manager endpoint status, or the DNS record.
• Smoke tests from outside and from on-premises; watch error rates and latency against the baseline.

Caution

Keep the source stack intact and read-only until the rollback window has passed. Deleting it early, or letting replication run the wrong way after failover, is how relocations lose data. Write down the rollback trigger (for example error rate above X for 15 minutes) and the steps before you start.

#Phase 7: decommission

• Rollback window passed and the owner has signed off.
• Remove replication links and failover groups, then deallocate the source.
• Remove locks deliberately, delete the source resource groups, and purge soft-deleted vaults only if you need the names back.
• Remove old private endpoint DNS records, old role assignments and stale alert rules.
• Ask partners to remove the old IPs from their allow-lists.

#Prevent it next time

• Deploy every workload from IaC with the region as a parameter, so a relocation is a redeploy and not an archaeology project.
• Assign roles and network rules to named identities and groups that are defined in code, not created by hand.
• Keep one up-to-date dependency map per workload (Resource Graph queries are enough).
• Run a relocation dry run into the target region as part of DR testing, so the quota, SKU and DNS problems are found before the real move.