Checklist before moving resources to a new resource group or subscription

Before we start moving resource in azure to different resource group or subscription, it is better to get familiar the points mentioned in this article. Resource movement is risky operation and can result in unexpected results. First thing you need to be sure the resources you want to move must support the move operation, you need to review Microsoft document as all resource does not support this operations.

Some services have specific limitations or requirements when moving resources.

Virtual Machine: Scenarios not supported

§  Managed Disks in Availability Zones can't be moved to a different subscription all other managed disk movement is supported.

§  Virtual Machines with certificate stored in Key Vault can be moved to a new resource group in the same subscription, but not across subscriptions.

§  Virtual Machine Scale Sets with Standard SKU Load Balancer or Standard SKU Public IP can't be moved.

§  Virtual machines created from Marketplace resources with plans attached can't be moved across resource groups or subscriptions. Deprovision the virtual machine in the current subscription, and deploy again in the new subscription.

§  Virtual machines in an existing virtual network but you aren't moving all resources in the virtual network.

§  Virtual machines with Azure Backup: To move virtual machines configured with Azure Backup, use the following workaround:

a)      Find the location of your Virtual Machine.

b)     Find a resource group with the following naming pattern: AzureBackupRG_<location of your VM>_1 for example, AzureBackupRG_westus2_1

c)      If in Azure portal, then check "Show hidden types"

d)     If in PowerShell, use the Get-AzResource -ResourceGroupName AzureBackupRG_<location of your VM>_1 cmdlet

e)     e  If in CLI, use the az resource list -g AzureBackupRG_<location of your VM>_1

f)       Find the resource with type Microsoft.Compute/restorePointCollections that has the naming pattern AzureBackup_<name of your VM that you're trying to move>_###########

g)      Delete this resource. This operation deletes only the instant recovery points, not the backed-up data in the vault.

h)     i  After delete is complete, you can move the vault and virtual machine to the target subscription. After the move, you can continue backups with no loss in data.

i)       j. For information about moving Recovery Service vaults for backup, see Recovery Services limitations.

 VNET:

§  Dependent resources: When moving a virtual network, you must also move its dependent resources. For VPN Gateways, you must move IP addresses, virtual network gateways, and all associated connection resources. Local network gateways can be in a different resource group.

§  To move a virtual machine with a network interface card, you must move all dependent resources. Move the virtual network for the network interface card, all other network interface cards for the virtual network, and the VPN gateways.

§  Peered virtual network: To move a peered virtual network, you must first disable the virtual network peering. Once disabled, you can move the virtual network. After the move, reenable the virtual network peering.

§  Subnet links: You can't move a virtual network to a different subscription if the virtual network contains a subnet with resource navigation links. For example, if an Azure Cache for Redis resource is deployed into a subnet, that subnet has a resource navigation link.

The others important points to note here are listed below:

1. The source and destination subscriptions must be active.

2. The destination subscription must be registered for the resource provider of the resource being moved. You might see this error when moving a resource to a new subscription, but that subscription has never been used with that resource type.

For VM resource provider is Microsoft.Compute

Commands to get the registration status and then To register a resource provider

Set-AzContext -Subscription <destination-subscription-name-or-id>

Get-AzResourceProvider -ListAvailable | Select-Object ProviderNamespace, RegistrationState

Register-AzResourceProvider -ProviderNamespace Microsoft.Batch

az account set -s <destination-subscription-name-or-id>

az provider list --query "[].{Provider:namespace, Status:registrationState}" --out table

az provider register --namespace Microsoft.Batch

OR

az feature register --namespace Microsoft.Compute --name planresourcegroup

#to see status of registered

az feature show --namespace Microsoft.Compute --name planresourcegroup

3. The source and destination subscriptions must exist within the same Azure Active Directory tenant.

 (Get-AzSubscription -SubscriptionName <your-source-subscription>).TenantId

 (Get-AzSubscription -SubscriptionName <your-destination-subscription>).TenantId

az account show --subscription <your-source-subscription> --query tenantId

az account show --subscription <your-destination-subscription> --query tenantId

If not same then use the following methods to reconcile the tenant IDs:

a. Transfer ownership of an Azure subscription to another account

b. How to associate or add an Azure subscription to Azure Active Directory

4. The account moving the resources must have at least the following permissions:

Microsoft.Resources/subscriptions/resourceGroups/moveResources/action on the source resource group.

Microsoft.Resources/subscriptions/resourceGroups/write on the destination resource group.

5. Before moving the resources, check the subscription quotas for the subscription you're moving the resources to.

6. The validate move operation lets you test your move scenario without actually moving the resources.

Send the following request with updated <location-url>:

POST https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/<source-group>/validateMoveResources?api-version=2019-05-10

Authorization: Bearer <access-token>

Content-type: application/json

With a request body:

{

 "resources": ["<resource-id-1>", "<resource-id-2>"],

 "targetResourceGroup": "/subscriptions/<subscription-id>/resourceGroups/<target-group>"

}

The 202 status code indicates the validation request was accepted. To check the status, send the following request:

GET <location-url>

Authorization: Bearer <access-token>

While the operation is still running, you continue to receive the 202 status code. Wait the number of seconds indicated in the retry-after value before trying again. If the move operation validates successfully, you receive the 204 status code. If the move validation fails, you receive an error message, such as:

{"error":{"code":"ResourceMoveProviderValidationFailed","message":"<message>"...}}

7. Resource are locked during the move i.e. cannot add,update or delete but no effect on application using resource

8. Location of the resource does not change.

9. After move resource id will change so need to update in tools or script using it.