Fundamentação Teórica: Move a Virtual Machine to Another Resource Group, Subscription, or Region

1. Intuição Inicial

Imagine que você mora em um apartamento e decide se mudar. Dependendo do destino, a mudança tem implicações muito diferentes:

Mudar para outro apartamento no mesmo prédio (outro Resource Group, mesma subscription): você leva tudo, o endereço muda, mas continua no mesmo condomínio com as mesmas regras.
Mudar para outro prédio no mesmo bairro (outra Subscription, mesmo tenant): você leva tudo, mas agora está em outro condomínio com outras regras, outro síndico, outra conta de gás.
Mudar para outra cidade (outra região): não dá para carregar os móveis pesados. Você precisa adquirir tudo novo no destino ou transportar peça por peça com esforço significativo.

Mover uma VM no Azure segue exatamente essa lógica. Mover entre Resource Groups ou Subscriptions é uma operação de metadados que preserva o recurso intacto. Mover entre regiões é uma operação de migração física que requer uma ferramenta especializada e envolve criação real de novos recursos.

2. Contexto

Por que mover recursos existe como operação

Organizações evoluem. Uma VM criada em um projeto temporário pode precisar ser transferida para o Resource Group permanente da aplicação. Uma startup adquirida pela empresa traz VMs em subscriptions separadas que precisam ser consolidadas. Uma expansão para novos mercados exige mover infraestrutura para regiões mais próximas dos usuários.

A operação de mover VMs existe para acomodar essas necessidades sem precisar deletar e recriar infraestrutura, o que causaria perda de dados, downtime e reconfiguração completa.

O que depende de mover VMs corretamente

RBAC: role assignments existentes no RG ou Subscription de origem não são transferidos
Azure Policy: o destino pode ter policies diferentes que tornam a VM não-conforme
Networking: dependências de VNet, NSG e IP público precisam ser gerenciadas
Backup: jobs do Azure Backup no RG de origem precisam ser reconfigurados no destino
Monitoring: alertas e Diagnostic Settings apontam para o Resource ID antigo
Cost Management: budgets e tags precisam ser revisados no destino

3. Construção dos Conceitos

3.1 Os três tipos de movimentação e suas naturezas

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

3.2 O que muda no Resource ID ao mover

O Resource ID de uma VM inclui o caminho completo na hierarquia ARM:

/subscriptions/{subId}/resourceGroups/{rgName}/providers/Microsoft.Compute/virtualMachines/{vmName}

Ao mover para outro RG (mesma Sub):

DE: /subscriptions/AAA/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-01
PARA: /subscriptions/AAA/resourceGroups/rg-destino/providers/Microsoft.Compute/virtualMachines/vm-01

Apenas o resourceGroups muda.

Ao mover para outra Subscription:

DE: /subscriptions/AAA/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-01
PARA: /subscriptions/BBB/resourceGroups/rg-destino/providers/Microsoft.Compute/virtualMachines/vm-01

Tanto subscriptions quanto resourceGroups mudam.

Implicação: qualquer referência hardcoded ao Resource ID antigo em scripts, alertas, RBAC, políticas ou aplicações quebra após o move.

3.3 Recursos que acompanham a VM em um move de RG/Subscription

Uma VM raramente existe sozinha. Ela tem dependências que precisam ser movidas juntas ou tratadas explicitamente:

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Regra geral: a VM, sua NIC e seus discos gerenciados devem ser movidos juntos. VNets e NSGs podem permanecer no RG de rede (cross-RG networking funciona normalmente).

3.4 Restrições ao mover VMs

Existem situações que impedem o move:

Condição	Pode mover?	Motivo
VM com Azure Disk Encryption (ADE) ativo	Não (para outra Sub)	Key Vault deve estar na mesma Sub; mova o KV junto ou descriptografe primeiro
VM em Availability Set sendo movida sem o AS	Não	AS deve ser movido junto com todas as VMs
VM com Proximity Placement Group	Condicional	PPG deve ser movido junto se existir
VM com Extension de backup configurada	Sim, mas com atenção	Backup jobs precisam ser reconfigurados no destino
VM com discos Ultra SSD ou Premium SSD v2	Verificar	Algumas restrições por tipo de disco
VM rodando (para move cross-subscription)	Sim	Move de metadados não requer parar a VM
VM com Classic Administrators	Não recomendado	Modelo legado; migrar para ARM primeiro

3.5 Azure Resource Mover: para movimentação entre regiões

Para mover uma VM para outra região, a ferramenta oficial é o Azure Resource Mover. Ele:

Cria novos recursos no destino baseados na configuração da origem
Replica os dados dos discos para a região destino
Permite validar e testar no destino antes de commitar
Descarta os recursos de origem após commit

Esta é a única forma suportada de "mover" uma VM entre regiões. Tecnicamente não é um move mas sim uma migração: novos recursos são criados e os antigos são deletados.

Alternativas ao Resource Mover para migração de região:

Azure Site Recovery (para VMs com workloads críticos que precisam de replicação contínua)
Capturar imagem + deploy em nova região + deletar original
Exportar/importar VHD manualmente (não recomendado para produção)

4. Visão Estrutural

Fluxo completo: mover VM entre Resource Groups

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Fluxo de migração entre regiões com Azure Resource Mover

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Comportamentos não óbvios e críticos

A operação de move aplica um lock temporário nos recursos. Durante o move (que pode levar de segundos a minutos para muitos recursos), o Azure aplica um lock nos recursos de origem. Nenhuma operação pode ser executada neles até o move terminar. Se o move falhar, os recursos são liberados no estado original.

Move entre subscriptions requer que ambas pertençam ao mesmo tenant. Não é possível mover VMs entre subscriptions de tenants diferentes via move nativo. Para isso é necessário recriar no destino ou usar Azure Site Recovery.

RBAC nunca é transferido automaticamente. Esta é a mudança mais impactante em um move cross-subscription: todos os role assignments no RG ou subscription de origem são perdidos. O receptor da VM precisa receber novos acessos no destino. Em um ambiente com muitos usuários e permissões, isso pode ser um trabalho significativo.

Resource providers devem estar registrados na subscription de destino. Se você move uma VM para uma subscription que nunca teve VMs, os resource providers Microsoft.Compute, Microsoft.Network e Microsoft.Storage precisam estar registrados. Caso contrário, o move falha com erro de resource provider não registrado.

Managed Disks movem junto com a VM mas podem ter restrições de zona. Se a VM usa Availability Zones e está na Zone 1 em brazilsouth, os discos gerenciados também estão atrelados àquela zone. Ao mover para outro RG, a zone é preservada. Mas ao mover para outra subscription, verifique se a zona está disponível no destino.

Diagnostic Settings e alertas ficam órfãos. Após um move, os Diagnostic Settings configurados na VM ou nos discos continuam existindo, mas apontam para o Resource ID antigo que não existe mais. Você verá logs sendo enviados para o Log Analytics com referências incorretas. É necessário reconfigurar.

O Azure Backup não segue a VM. Se a VM estava protegida pelo Azure Backup em um Recovery Services Vault no RG de origem, após o move a VM continua registrada no vault mas a associação pode se tornar inconsistente. Recomendação: pare a proteção de backup antes do move e reconfigure no destino.

6. Formas de Implementação

Portal do Azure

Quando usar: moves pontuais, uma VM por vez, verificação visual das dependências

Para mover para outro RG ou Subscription:

Portal > Resource Groups > selecionar RG de origem
Selecionar os recursos a serem movidos (VM + NIC + Discos + IP Público, se aplicável)
Clicar em Move > Move to another resource group ou Move to another subscription
O portal valida automaticamente as dependências e exibe avisos
Selecionar o RG destino (ou subscription + RG destino)
Confirmar que entende que Resource IDs mudarão
Move

Para mover entre regiões (via Resource Mover):

Portal > buscar Azure Resource Mover
Move > Move to another region
Selecionar subscription, RG de origem
Adicionar VM e deixar o Resource Mover identificar dependências
Seguir o wizard de preparação, validação e commit

Limitação: para grandes volumes, o portal é lento e impraticável.

Azure CLI

# Validar se os recursos suportam move antes de executar
az resource invoke-action \
  --action "validateMoveResources" \
  --ids "/subscriptions/<sub-id>/resourceGroups/rg-origem" \
  --request-body "{
    \"resources\": [
      \"/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-01\",
      \"/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Network/networkInterfaces/nic-vm-01\",
      \"/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Compute/disks/vm-01-osdisk\"
    ],
    \"targetResourceGroup\": \"/subscriptions/<sub-id>/resourceGroups/rg-destino\"
  }"

# Mover VM para outro Resource Group (mesma Subscription)
# Obtém os IDs de todos os recursos a mover
VM_ID=$(az vm show --resource-group rg-origem --name vm-01 --query id --output tsv)
NIC_ID=$(az vm show --resource-group rg-origem --name vm-01 --query "networkProfile.networkInterfaces[0].id" --output tsv)
OS_DISK_ID=$(az vm show --resource-group rg-origem --name vm-01 --query "storageProfile.osDisk.managedDisk.id" --output tsv)
DATA_DISK_IDS=$(az vm show --resource-group rg-origem --name vm-01 --query "storageProfile.dataDisks[].managedDisk.id" --output tsv)

# Executar o move
az resource move \
  --destination-group "rg-destino" \
  --ids "$VM_ID" "$NIC_ID" "$OS_DISK_ID" $DATA_DISK_IDS

# Mover para outra Subscription
az resource move \
  --destination-group "rg-destino" \
  --destination-subscription-id "<sub-destino-id>" \
  --ids "$VM_ID" "$NIC_ID" "$OS_DISK_ID"

# Verificar resource providers na subscription de destino (para cross-sub move)
az provider show \
  --namespace "Microsoft.Compute" \
  --subscription "<sub-destino-id>" \
  --query "registrationState" \
  --output tsv

# Registrar providers se necessário
az provider register \
  --namespace "Microsoft.Compute" \
  --subscription "<sub-destino-id>"

az provider register \
  --namespace "Microsoft.Network" \
  --subscription "<sub-destino-id>"

az provider register \
  --namespace "Microsoft.Storage" \
  --subscription "<sub-destino-id>"

# Após o move: verificar que a VM está no novo RG
az vm show \
  --resource-group "rg-destino" \
  --name "vm-01" \
  --query "{Name: name, RG: resourceGroup, Location: location}" \
  --output json

# Script completo: mover VM com todos os recursos associados
RESOURCE_GROUP_ORIGEM="rg-origem"
RESOURCE_GROUP_DESTINO="rg-destino"
VM_NAME="vm-01"
SUB_ID=$(az account show --query id --output tsv)

echo "Coletando IDs dos recursos associados a $VM_NAME..."

VM_ID="/subscriptions/$SUB_ID/resourceGroups/$RESOURCE_GROUP_ORIGEM/providers/Microsoft.Compute/virtualMachines/$VM_NAME"

# Coletar NICs
NIC_IDS=$(az vm show \
  --resource-group "$RESOURCE_GROUP_ORIGEM" \
  --name "$VM_NAME" \
  --query "networkProfile.networkInterfaces[].id" \
  --output tsv)

# Coletar disco de SO
OS_DISK_ID=$(az vm show \
  --resource-group "$RESOURCE_GROUP_ORIGEM" \
  --name "$VM_NAME" \
  --query "storageProfile.osDisk.managedDisk.id" \
  --output tsv)

# Coletar discos de dados
DATA_DISK_IDS=$(az vm show \
  --resource-group "$RESOURCE_GROUP_ORIGEM" \
  --name "$VM_NAME" \
  --query "storageProfile.dataDisks[].managedDisk.id" \
  --output tsv)

# Coletar IP público (se houver)
PUBLIC_IP_IDS=$(for nic_id in $NIC_IDS; do
  az network nic show --ids "$nic_id" \
    --query "ipConfigurations[].publicIpAddress.id" \
    --output tsv 2>/dev/null
done)

echo "Executando move..."
az resource move \
  --destination-group "$RESOURCE_GROUP_DESTINO" \
  --ids "$VM_ID" $NIC_IDS "$OS_DISK_ID" $DATA_DISK_IDS $PUBLIC_IP_IDS

echo "Move concluído. Verificando..."
az vm show \
  --resource-group "$RESOURCE_GROUP_DESTINO" \
  --name "$VM_NAME" \
  --query "{Name: name, RG: resourceGroup}" \
  --output json

Azure PowerShell

# Mover VM para outro Resource Group
$vm = Get-AzVM -ResourceGroupName "rg-origem" -Name "vm-01"

# Coletar IDs dos recursos associados
$nicIds = $vm.NetworkProfile.NetworkInterfaces.Id
$osDiskId = $vm.StorageProfile.OsDisk.ManagedDisk.Id
$dataDiskIds = $vm.StorageProfile.DataDisks.ManagedDisk.Id

# Coletar IPs públicos das NICs
$publicIpIds = @()
foreach ($nicId in $nicIds) {
  $nic = Get-AzNetworkInterface -ResourceId $nicId
  $publicIpIds += $nic.IpConfigurations.PublicIpAddress.Id | Where-Object { $_ -ne $null }
}

# Combinar todos os IDs
$allIds = @($vm.Id) + $nicIds + $osDiskId + $dataDiskIds + $publicIpIds
$allIds = $allIds | Where-Object { $_ -ne $null }

# Executar move
Move-AzResource `
  -DestinationResourceGroupName "rg-destino" `
  -ResourceId $allIds

# Mover para outra Subscription
Move-AzResource `
  -DestinationResourceGroupName "rg-destino" `
  -DestinationSubscriptionId "<sub-destino-id>" `
  -ResourceId $allIds

# Verificar resultado
Get-AzVM -ResourceGroupName "rg-destino" -Name "vm-01" |
  Select-Object Name, ResourceGroupName, Location

Azure Resource Mover via CLI (migração entre regiões)

# Criar Move Collection no Resource Mover
az resource-mover move-collection create \
  --name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover" \
  --source-region "brazilsouth" \
  --target-region "eastus" \
  --identity-type SystemAssigned

# Adicionar VM à move collection
az resource-mover move-resource add \
  --move-collection-name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover" \
  --source-id "/subscriptions/<sub-id>/resourceGroups/rg-origem/providers/Microsoft.Compute/virtualMachines/vm-01"

# Resolver dependências automaticamente
az resource-mover move-collection resolve-dependency \
  --move-collection-name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover"

# Preparar recursos (inicia replicação de dados)
az resource-mover move-resource initiate-move \
  --move-collection-name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover" \
  --move-resources "/subscriptions/<sub-id>/resourceGroups/rg-resource-mover/providers/Microsoft.Migrate/moveCollections/move-collection-brazilsouth-to-eastus/moveResources/vm-01"

# Verificar status de preparação
az resource-mover move-resource list \
  --move-collection-name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover" \
  --query "[].{Name: name, State: moveStatus.moveState}" \
  --output table

# Commit o move (após validar no destino)
az resource-mover move-collection commit \
  --move-collection-name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover" \
  --move-resources "/subscriptions/<sub-id>/..."

# Deletar recursos de origem (após commit)
az resource-mover move-collection discard \
  --move-collection-name "move-collection-brazilsouth-to-eastus" \
  --resource-group "rg-resource-mover" \
  --move-resources "/subscriptions/<sub-id>/..."

7. Controle e Segurança

Permissões necessárias para executar um move

Operação	Permissão necessária
Mover para outro RG (mesma Sub)	`Microsoft.Resources/subscriptions/resourceGroups/moveResources/action` no RG origem + Contributor no RG destino
Mover para outra Subscription	Owner ou Contributor em ambas as subscriptions
Usar Azure Resource Mover	Contributor na subscription de origem e destino

A forma mais simples de garantir as permissões corretas é ter Contributor tanto no RG/Subscription de origem quanto no destino.

O que fazer com RBAC após o move cross-subscription

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Backup antes do move

Para moves críticos, especialmente cross-subscription, criar um snapshot dos discos antes do move é uma prática de segurança:

# Criar snapshot do disco de SO antes do move
OS_DISK_ID=$(az vm show \
  --resource-group rg-origem \
  --name vm-01 \
  --query "storageProfile.osDisk.managedDisk.id" \
  --output tsv)

az snapshot create \
  --name "snapshot-vm-01-osdisk-premove-$(date +%Y%m%d)" \
  --resource-group "rg-snapshots" \
  --source "$OS_DISK_ID"

8. Tomada de Decisão

Quando usar cada abordagem de movimentação

Situação	Abordagem	Motivo
Reorganização de RGs na mesma subscription	az resource move	Operação rápida, apenas metadados
Consolidar VMs de subscription adquirida	az resource move cross-sub	Move nativo se mesmo tenant
Mover para região mais próxima de usuários	Azure Resource Mover	Única opção suportada para migração entre regiões
VM com ADE ativo para outra Sub	Mover Key Vault junto, depois a VM	KV deve estar na mesma Sub
VM crítica com mínimo de downtime para nova região	Azure Site Recovery	Replicação contínua, failover controlado
Recriar VM com mesma configuração em nova região	Capturar imagem + deploy	Mais controle, mas requer recriação manual
Move de dezenas de VMs entre RGs	Script PowerShell/CLI em lote	Portal é impraticável para volumes altos

Move nativo vs. recreação

Aspecto	Move nativo (RG/Sub)	Recriar no destino
Dados preservados	Sim (dados no disco intactos)	Depende (precisa copiar dados)
Downtime	Nenhum (lock temporário)	Necessário para copiar dados
Resource ID	Muda	Novo ID desde o início
Risco	Baixo (operação atômica)	Médio (pode ocorrer erros na recriação)
Tempo	Minutos	Horas para VMs grandes
Ideal para	VMs com dados e configuração complexa	Ambientes novos ou VMs stateless

9. Boas Práticas

Sempre use o validador de move antes de executar. O comando validateMoveResources ou o portal identifica restrições antes da operação. Descobrir que um recurso não suporta move depois de iniciar causa rollback desnecessário.

Mova todos os recursos dependentes na mesma operação. Uma VM sem sua NIC no mesmo RG é uma VM sem conectividade de rede. Discos sem a VM são discos órfãos. O ARM valida algumas dependências, mas não todas. Identifique manualmente tudo que precisa se mover junto.

Documente o estado antes do move. Antes de qualquer move cross-subscription, exporte os role assignments atuais:

az role assignment list \
  --resource-group "rg-origem" \
  --output json > rbac-backup-$(date +%Y%m%d).json

Isso serve como referência para recriar acessos no destino.

Teste a validação de resource providers na subscription de destino. Para cross-subscription, verifique com antecedência que Microsoft.Compute, Microsoft.Network e Microsoft.Storage estão registrados. O registro pode levar alguns minutos.

Para movimentações entre regiões, prefira Azure Resource Mover a soluções manuais. O Resource Mover gerencia dependências automaticamente, oferece uma fase de teste antes do commit e mantém um estado da operação que permite desfazer se necessário.

Planeje janelas de manutenção para moves cross-subscription de VMs críticas. Embora o move não cause downtime na VM em execução, o período em que a VM está com lock temporário pode impedir operações de gerenciamento (scaling, restart, apply de patches). Comunique a janela para as equipes dependentes.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Move falha por resource provider não registrado	Subscription destino nunca usou aquele tipo de recurso	Verificar e registrar providers antes do move
Move falha por recurso não suportado	Tipo específico de disco ou configuração sem suporte	Usar validateMoveResources antes de executar
Alertas e dashboards quebram após o move	Resource ID muda; referências ficam obsoletas	Inventariar e atualizar todas as referências externas
RBAC perdido sem backup	Move cross-subscription apaga role assignments	Exportar RBAC antes do move
NIC ou disco não movido junto com a VM	Operação incompleta, movendo apenas a VM	Sempre mapear e incluir todos os recursos dependentes
VM com ADE falha no move cross-sub	Key Vault deve estar na mesma subscription	Mover KV primeiro, ou descriptografar e re-criptografar
Backup jobs quebram após o move	Recovery Services Vault aponta para Resource ID antigo	Remover VM do backup antes do move, reconfigurá-la no destino
Cross-sub move falha por subscriptions em tenants diferentes	Move nativo não funciona cross-tenant	Usar Azure Site Recovery ou recrear no destino

O erro mais crítico

Executar um move cross-subscription sem documentar os role assignments e sem avisar as equipes que têm acesso à VM. Após o move, todos os acessos são perdidos e as equipes reportam que "não conseguem acessar a VM". Em produção, isso pode causar incidentes de disponibilidade enquanto os acessos são reconfigurados.

11. Operação e Manutenção

Checklist pós-move

# 1. Confirmar que a VM está no novo RG/Sub
az vm show \
  --resource-group "rg-destino" \
  --name "vm-01" \
  --query "{Name: name, RG: resourceGroup, Sub: id}" \
  --output json

# 2. Verificar conectividade da VM (se em execução)
az vm run-command invoke \
  --resource-group "rg-destino" \
  --name "vm-01" \
  --command-id RunShellScript \
  --scripts "echo 'VM acessivel'"

# 3. Verificar que discos estão associados
az disk list \
  --resource-group "rg-destino" \
  --query "[?managedBy != null].{Name: name, VM: managedBy}" \
  --output table

# 4. Verificar Diagnostic Settings (se existem, precisam ser atualizados)
az monitor diagnostic-settings list \
  --resource "/subscriptions/<sub-destino>/resourceGroups/rg-destino/providers/Microsoft.Compute/virtualMachines/vm-01"

# 5. Verificar se VM ainda está no Recovery Services Vault antigo
az backup item list \
  --resource-group "rg-backup-origem" \
  --vault-name "rsv-origem" \
  --query "[?properties.friendlyName=='vm-01']" \
  --output table

Monitorar o status de um move em andamento

# Move de grandes volumes pode levar tempo
# Verificar status das operações recentes
az monitor activity-log list \
  --resource-group "rg-origem" \
  --max-events 10 \
  --query "[?operationName.value=='Microsoft.Resources/subscriptions/resourceGroups/moveResources/action'].{Time: eventTimestamp, Status: status.value, Caller: caller}" \
  --output table

12. Integração e Automação

Move em massa com validação e logging

# Script: Mover múltiplas VMs de um RG para outro com logging
param (
  [string]$SourceRG,
  [string]$DestinationRG,
  [string[]]$VMNames
)

$results = @()

foreach ($vmName in $VMNames) {
  Write-Output "Processando VM: $vmName"

  try {
    $vm = Get-AzVM -ResourceGroupName $SourceRG -Name $vmName -ErrorAction Stop

    # Coletar recursos dependentes
    $resourceIds = @($vm.Id)
    $resourceIds += $vm.NetworkProfile.NetworkInterfaces.Id
    $resourceIds += $vm.StorageProfile.OsDisk.ManagedDisk.Id
    $resourceIds += $vm.StorageProfile.DataDisks.ManagedDisk.Id | Where-Object { $_ -ne $null }

    # Exportar RBAC antes do move
    $rbac = Get-AzRoleAssignment -ResourceGroupName $SourceRG |
      Where-Object { $_.Scope -like "*$vmName*" }
    $rbac | Export-Csv -Path "rbac-$vmName-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

    # Executar move
    Move-AzResource `
      -DestinationResourceGroupName $DestinationRG `
      -ResourceId $resourceIds `
      -Force

    $results += [PSCustomObject]@{
      VM = $vmName
      Status = "Success"
      Message = "Movida para $DestinationRG"
    }
    Write-Output "VM $vmName movida com sucesso"

  } catch {
    $results += [PSCustomObject]@{
      VM = $vmName
      Status = "Failed"
      Message = $_.Exception.Message
    }
    Write-Error "Falha ao mover $vmName: $_"
  }
}

# Relatório final
$results | Format-Table -AutoSize
$results | Export-Csv -Path "move-results-$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation

Integração com Azure Resource Mover via Terraform

Para migração de região como parte de um processo de IaC, o Azure Resource Mover pode ser acionado via Terraform usando o provider azurerm:

resource "azurerm_resource_group_template_deployment" "resource_mover" {
  name                = "resource-mover-deployment"
  resource_group_name = azurerm_resource_group.mover.name
  deployment_mode     = "Incremental"

  template_content = jsonencode({
    "$schema" = "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#"
    contentVersion = "1.0.0.0"
    resources = [
      {
        type       = "Microsoft.Migrate/moveCollections"
        apiVersion = "2021-08-01"
        name       = "move-collection-prod"
        location   = "eastus"
        identity = { type = "SystemAssigned" }
        properties = {
          sourceRegion = "brazilsouth"
          targetRegion = "eastus"
        }
      }
    ]
  })
}

13. Resumo Final

Pontos essenciais:

Mover uma VM entre Resource Groups ou Subscriptions é uma operação de metadados no ARM: os dados nos discos não são tocados, apenas o endereçamento (Resource ID) muda
Mover entre regiões é uma migração física: novos recursos são criados no destino, dados são copiados, recursos de origem são deletados ao final; use Azure Resource Mover para essa operação
A VM, suas NICs e seus discos gerenciados devem ser movidos juntos na mesma operação
Move cross-subscription apaga todos os role assignments; exporte o RBAC antes e recrie no destino
O move aplica um lock temporário nos recursos durante a operação; nenhuma ação de gerenciamento pode ser executada neles até o término
Azure Disk Encryption com Key Vault em outra subscription impede o move da VM; mova o Key Vault primeiro ou descriptografe

Diferenças críticas:

Move RG vs. Move Subscription: ambos mudam o Resource ID, mas move de subscription também perde RBAC e pode exigir registro de resource providers no destino
Move nativo vs. Azure Resource Mover: move nativo é para RG/Subscription (metadados); Resource Mover é para mudança de região (migração física)
Azure Resource Mover vs. Azure Site Recovery: Resource Mover é para migração única (mover uma vez); Site Recovery é para replicação contínua com failover (DR)
Lock temporário durante move vs. Resource Lock permanente: o lock do move é automático e temporário; Resource Locks são configurados pelo administrador

O que precisa ser lembrado para o AZ-104:

O comando CLI para move é az resource move --destination-group --ids
Para cross-subscription, adicionar --destination-subscription-id
Resource providers precisam estar registrados na subscription de destino antes do move cross-sub
Mover VM entre regiões requer Azure Resource Mover (não o comando az resource move)
A operação de move é atômica: se falhar, todos os recursos voltam ao estado original
Verificar suporte ao move: https://learn.microsoft.com/azure/azure-resource-manager/management/move-support-resources
Permissão mínima necessária: Microsoft.Resources/subscriptions/resourceGroups/moveResources/action + Contributor no destino

1. Intuição Inicial​

2. Contexto​

Por que mover recursos existe como operação​

O que depende de mover VMs corretamente​

3. Construção dos Conceitos​

3.1 Os três tipos de movimentação e suas naturezas​

3.2 O que muda no Resource ID ao mover​

3.3 Recursos que acompanham a VM em um move de RG/Subscription​

3.4 Restrições ao mover VMs​

3.5 Azure Resource Mover: para movimentação entre regiões​

4. Visão Estrutural​

Fluxo completo: mover VM entre Resource Groups​

Fluxo de migração entre regiões com Azure Resource Mover​

5. Funcionamento na Prática​

Comportamentos não óbvios e críticos​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Azure Resource Mover via CLI (migração entre regiões)​

7. Controle e Segurança​

Permissões necessárias para executar um move​

O que fazer com RBAC após o move cross-subscription​

Backup antes do move​

8. Tomada de Decisão​

Quando usar cada abordagem de movimentação​

Move nativo vs. recreação​

9. Boas Práticas​

10. Erros Comuns​

O erro mais crítico​

11. Operação e Manutenção​

Checklist pós-move​

Monitorar o status de um move em andamento​

12. Integração e Automação​

Move em massa com validação e logging​

Integração com Azure Resource Mover via Terraform​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Por que mover recursos existe como operação

O que depende de mover VMs corretamente

3. Construção dos Conceitos

3.1 Os três tipos de movimentação e suas naturezas

3.2 O que muda no Resource ID ao mover

3.3 Recursos que acompanham a VM em um move de RG/Subscription

3.4 Restrições ao mover VMs

3.5 Azure Resource Mover: para movimentação entre regiões

4. Visão Estrutural

Fluxo completo: mover VM entre Resource Groups

Fluxo de migração entre regiões com Azure Resource Mover

5. Funcionamento na Prática

Comportamentos não óbvios e críticos

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Azure Resource Mover via CLI (migração entre regiões)

7. Controle e Segurança

Permissões necessárias para executar um move

O que fazer com RBAC após o move cross-subscription

Backup antes do move

8. Tomada de Decisão

Quando usar cada abordagem de movimentação

Move nativo vs. recreação

9. Boas Práticas

10. Erros Comuns

O erro mais crítico

11. Operação e Manutenção

Checklist pós-move

Monitorar o status de um move em andamento

12. Integração e Automação

Move em massa com validação e logging

Integração com Azure Resource Mover via Terraform

13. Resumo Final