You're a great admin... on-prem. Now, become a great admin in the cloud and prove it by passing the Microsoft Certified: Azure Administrator Associate exam!
Gauge your current knowledge
Gauge your current knowledge
Before moving a virtual machine, you must ensure both the source and target subscriptions reside within the same Microsoft Entra ID tenant. The administrator performing the move needs Owner permissions to assign roles and manage identities. While virtual machines with managed disks can move easily, any unmanaged disks must be converted to managed disks before starting. Additionally, the target subscription must have sufficient quota, and the target region must support availability zones if the source configuration uses them.
Several resource configurations block the movement of virtual machines. For instance, Virtual Machine Scale Sets that use Standard SKU load balancers or public IP addresses cannot be moved, and virtual machines in an availability set must be moved together rather than individually. Furthermore, marketplace virtual machines with attached plans cannot cross subscription boundaries without being deprovisioned and redeployed. You must also disable Azure Disk Encryption before moving virtual machines across subscriptions, and any active resource locks must be removed.
Virtual machines rely on associated resources like Network Security Groups (NSGs), load balancers, and public IP addresses. To avoid breaking these connections, you should assess and move these dependent resources concurrently. The Azure Resource Mover tool can automatically validate these dependencies and manage cross-region relocations. During the move process, Azure locks the source resources, which prevents any modifications and may cause brief downtime.
Executing a resource move involves a structured sequence within the Azure Portal to prevent configuration errors. First, you locate the resource group containing the virtual machine and select the specific items to relocate. Next, you trigger the move command, specify the target resource group and subscription, and initiate the validation phase. Once validation succeeds, you must acknowledge that resource IDs will change and then start the actual transfer.
When resources move, their associated Role-Based Access Control (RBAC) assignments do not transfer automatically and must be recreated at the destination. For special configurations like Azure Backup, you must delete the restore points collections before starting the move. If the virtual machine uses customer-managed keys for encryption, you must replicate those keys to a Key Vault in the target region before executing the transition.
After a move, especially across regions, a virtual machine receives a new public IP address because public IPs are region-specific and cannot travel. You must manually update public DNS records and external firewalls to point to the new IP address. To restore internal traffic flows, you need to reconfigure Virtual Network Peering, update Load Balancer backend pools, and adjust network security rules. These changes ensure that both public and private traffic routes to the virtual machine without interruption.
Because resource IDs change during a move, existing RBAC assignments are left orphaned and no longer apply. You must manually recreate these permission structures at the target scope to restore access for users and applications. If the virtual machine uses a system-assigned managed identity, you must re-register the virtual machine with its dependent Azure services. This step is critical for restoring automated authentication between the virtual machine and other secure resources.
Data protection configurations must be rebuilt after relocation because backups do not cross boundaries easily. For virtual machines protected by Azure Backup, you must unregister the virtual machine from the original Recovery Services vault and set up protection in a new vault. Similarly, diagnostic settings will break during a move, requiring you to manually reconnect them to the correct Log Analytics Workspace. Finally, any custom maintenance schedules or update configurations must be reapplied to ensure the virtual machine receives updates.
The final phase of a move is validating the new environment and cleaning up leftover artifacts. After performing a smoke test to confirm the virtual machine is running and sized correctly, you must delete the original resources to avoid double billing. This cleanup includes deleting the source virtual machine, its old managed disks, and any temporary Move Collection storage. You should also clear out orphaned resource navigation links in the source subnets to prevent future networking issues.
StudyCerts
StudyCerts