How to migrate VMware, Hyper-V and physical servers to Azure

Choose the region closest to your users that meets your data residency rules. The geography you pick for the Azure Migrate project decides where project metadata is stored. For example, with the Australia geography it is stored in Australia East or Australia Southeast.

Create the resource group, virtual network and subnets in the target region, plus a separate isolated virtual network for test migrations. Virtual networks are regional, so they must be in the same region you replicate to.

az group create --name rg-migrate-aue --location australiaeast
az network vnet create --resource-group rg-migrate-aue --name vnet-prod-aue --address-prefix 10.20.0.0/16 --subnet-name snet-servers --subnet-prefix 10.20.1.0/24
az network vnet create --resource-group rg-migrate-aue --name vnet-test-aue --address-prefix 10.99.0.0/16 --subnet-name snet-test --subnet-prefix 10.99.1.0/24

Choose the subscription and resource group, name the project and choose the geography that matches your residency needs, then select Create. Full steps are in set up the Azure Migrate appliance.

In Are your servers virtualized? choose Yes, with VMware vSphere hypervisor. Give the appliance a name of 14 characters or fewer, select Generate key and copy the key. Do not close the pane while resources are created.

Download the OVA and deploy it. Microsoft lists 32 GB RAM, 8 vCPUs and about 80 GB of disk for the appliance, plus internet access directly or via an HTTP proxy. Pick a network with internet access in Network Mapping, power on the VM, then in Open Console accept the licence terms and set the administrator password.

Create a read-only account. For application discovery and agentless dependency analysis on vCenter 7.x and later, clone the Read-only role, add Guest operations privileges and assign it with Propagate to children.

Pass the prerequisite checks, paste the project key under Register with Azure Migrate and sign in with the account that generated the key. In Manage credentials and discovery sources add the vCenter account and up to 10 vCenter Servers per appliance, then select Start discovery.

Leave the appliance collecting data for a representative period so sizing reflects real usage, including month-end peaks. Do not shut the appliance down between discovery and assessment.

Name the assessment and review the servers added (select Add workloads for more). Set Target region, Default environment, Pricing options, Saving options and Sizing criteria (performance-based or as-is). On the Azure VM tab select Edit defaults to review settings, then in Review + create assessment select Create Assessment. Review readiness, recommended VM sizes and disk types, and fix servers marked as not ready (unsupported OS, boot type, disk size) before replication.

Use dependency analysis to find servers that must move together. Group them into migration waves and record each wave in the plan.

In Specify intent choose Servers or Virtual Machines(VM) and Azure VM. Select workloads From all inventory or From an assessment, choose the VMware vSphere appliance and Agentless migration. Choose the Target VM security type and the VMs, then set the target subscription, region, storage account, Azure Hybrid Benefit, virtual network, availability options, VM size and disk type. Select Review and start execution. Microsoft documents up to 500 simultaneous replications, and you can select up to 10 VMs at once in the portal.

Follow the portal link to the provider setup, select the Target region, tick the confirmation and select Create resources, then download the Hyper-V Replication provider and registration key. On each host run AzureSiteRecoveryProvider.exe, select Install, then Register, browse to the key and finish. The key is valid for five days. Back in the portal select Finalize registration, then start replication with Start execution as for VMware.

Select the Target region, confirm it and select Create resources. Build a separate Windows server for the replication appliance (not a source server and not the discovery appliance), download the installer from the portal or https://aka.ms/V2ARcmApplianceCreationPowershellZip, extract it and run DRInstaller.ps1 as administrator. In the appliance configuration manager, register with the replication appliance key, then add credentials and source servers. The Mobility service is pushed when you enable replication, or you install it manually. The classic replication appliance retired on 30 September 2026, so use the simplified appliance.

.\DRInstaller.ps1

For VMware agentless migration, the Az.Migrate module covers the same steps.

Connect-AzAccount
$MigrateProject = Get-AzMigrateProject -Name MyMigrateProject -ResourceGroupName rg-migrate-aue
$DiscoveredServer = Get-AzMigrateDiscoveredServer -ProjectName $MigrateProject.Name -ResourceGroupName rg-migrate-aue -DisplayName APP01
Initialize-AzMigrateReplicationInfrastructure -ResourceGroupName rg-migrate-aue -ProjectName $MigrateProject.Name -Scenario agentlessVMware -TargetRegion "australiaeast"
$TargetResourceGroup = Get-AzResourceGroup -Name rg-servers-aue
$TargetVirtualNetwork = Get-AzVirtualNetwork -Name vnet-prod-aue
New-AzMigrateServerReplication -InputObject $DiscoveredServer -TargetResourceGroupId $TargetResourceGroup.ResourceId -TargetNetworkId $TargetVirtualNetwork.Id -LicenseType NoLicenseType -OSDiskID $DiscoveredServer.Disk[0].Uuid -TargetSubnetName snet-servers -DiskType Standard_LRS -TargetVMName APP01 -TargetVMSize Standard_D2s_v5
Get-AzMigrateServerMigrationStatus -ProjectName $MigrateProject.Name -ResourceGroupName rg-migrate-aue -MachineName APP01

Choose the isolated test virtual network and a subnet for each NIC. Optionally select Upgrade available to upgrade the Windows Server OS. Select Test migration. The source keeps running and replicating.

$ReplicatingServer = Get-AzMigrateServerReplication -ProjectName $MigrateProject.Name -ResourceGroupName rg-migrate-aue -MachineName APP01
$TestVirtualNetwork = Get-AzVirtualNetwork -Name vnet-test-aue
Start-AzMigrateTestMigration -InputObject $ReplicatingServer -TestNetworkID $TestVirtualNetwork.Id

Log on, check services start, run application smoke tests and confirm the VM agent and activation are healthy. Record any changes needed, such as connection strings or firewall rules.

Remove the test VM so it does not clash with the real migration.

Start-AzMigrateTestMigrationCleanup -InputObject $ReplicatingServer

In the change window, stop application services. In the Migrate pane, under Shut down virtual machines and perform a planned migration with no data loss, choose Yes, then select Migrate. Azure Migrate shuts down the source VM and runs a final replication so no data is lost.

Start-AzMigrateServerMigration -InputObject $ReplicatingServer -TurnOffSourceServer

Point DNS records, load balancers and firewall rules at the new private IP addresses. Update application settings that reference host names or IPs.

Resolve-DnsName app01.contoso.com

After acceptance testing, select Complete migration to stop replication and clean up replication state.

Remove-AzMigrateServerReplication -InputObject $ReplicatingServer

Enable Azure Backup, apply network security groups, configure Azure Update Manager and Defender for Cloud, and set budgets in Cost Management.

Remove the on-premises VMs from inventory and backup jobs once the rollback window has closed, and update documentation with the new locations and IP addresses.

Host types vary by region, so check Microsoft's list for yours. For example, Microsoft lists Azure VMware Solution host types in Australia East (AV36, AV36P and AV64 across zones) and Australia Southeast (AV36). A cluster needs a minimum of three hosts.

It suits large estates that need to exit a data centre quickly or have VMware-dependent appliances. You still license VMware, so compare it with rehosting in the VMware alternatives guide.