VMware to Azure: What to Check Before You Replicate

Not every VMware exit ends on Hyper-V. For some servers the better destination is Azure, and Microsoft's own tool for that move is Azure Migrate. It is a free service for discovery, assessment and migration (partner tools you plug into it may charge separately), and it handles VMware vSphere VMs well. But it has firm limits, and it is far cheaper to find them before replication starts than halfway through it.

This post covers what to check before you replicate the first VM, so the surprises turn up in a spreadsheet instead of a cutover weekend. If you are still weighing destinations, our VMware to Hyper-V guide covers the on-premises path.

Start With Discovery, Not a Spreadsheet Export

Azure Migrate discovers VMware VMs through a lightweight appliance that runs as a VM in your vCenter Server. You download it as an OVA template from your Azure Migrate project, or build it with a PowerShell script on an existing Windows Server 2022 or 2025 server. Plan for what it needs: 32 GB of RAM, 8 vCPUs, about 80 GB of disk, and internet access, directly or through a proxy. It talks to vCenter Server on port 443. For Canadian organizations, the project's discovery and assessment metadata can be kept in the Canada geography (Canada Central or Canada East).

Once registered, the appliance keeps collecting configuration and performance data. If you give it server credentials, it also inventories installed applications, SQL Server instances and web apps, and maps dependencies. That last part matters most.

Map Dependencies Before You Group Waves

Agentless dependency analysis captures TCP connection data from each server: which processes have active connections, which applications own them, and the destination ports. The appliance polls every five minutes and sends the data to Azure every six hours. You can view it as a map or export it as a CSV.

Use it to build migration waves around applications, not around hosts or datastores. A server that quietly talks to a licence server or a file share nobody listed is how a "finished" migration turns into an outage on Monday morning. Agentless is now the recommended option; Microsoft has stopped onboarding new servers to agent-based dependency analysis.

Size From Performance Data, and Give It Time

Assessments can size Azure VMs either as-is, from each VM's configured CPU, memory and disks, or from measured performance. Performance-based sizing usually gives a closer fit, but only if the data has had time to build up. Microsoft recommends waiting at least a day after discovery starts before creating a performance-based assessment, and ideally the full period you plan to base it on (a day, a week or a month) for a high-confidence rating. A comfort factor adds headroom for seasonal peaks and growth.

The assessment's default assumes VMs run 31 days a month, 24 hours a day. If some servers only need business hours, change that before you show anyone a cost estimate.

Check the Blockers VM by VM

Agentless migration installs nothing on the VMs, which keeps changes to production servers to a minimum. It supports vCenter Server and ESXi 6.5 through 9.0. These are the limits most likely to stop a VM partway through:

• Disks that won't replicate: encrypted disks or volumes, shared-disk clusters, independent disks and multipath IO aren't supported. RDM or passthrough disks and NFS volumes mounted inside the VM are skipped. VMs with iSCSI targets aren't supported for agentless migration.
• Disk layout: an OS disk that is a dynamic disk isn't supported, and the boot files and OS must sit on the same disk. OS disks can be up to 2 TB on Generation 1 VMs and 4 TB on Generation 2; data disks up to 32 TB.
• Networking: teamed NICs and IPv6 aren't supported.
• Secure Boot: UEFI VMs move to Generation 2 Azure VMs without Secure Boot. Plan to convert them to Trusted Launch after migration to turn it back on.
• Old operating systems: Microsoft warns it can't guarantee reliable results for Windows Server 2008 through 2012 R2 and strongly advises upgrading first. Our Windows Server 2012 R2 guide covers those options, and our SQL Server 2016 guide covers the database side.

Also check the vCenter account the appliance uses. It needs specific privileges (snapshot management, disk change tracking, disk access and power off, among others) at the datacenter, cluster, host, VM and datastore levels. Missing one at a single level is a common cause of replication errors.

Test Every Machine Before Cutover

Replication starts with a snapshot copied to seed disks in Azure, then switches to delta replication of changed blocks. Once a VM is in delta replication you can run a test migration: Azure Migrate builds a VM from the replicated data in a network you choose, while the source keeps running and replicating.

Microsoft recommends testing every machine at least once. Use an isolated, non-production virtual network. A test network with open connections back on-premises can cause duplicate machines or DNS changes. Clean up the test resources afterwards.

For the real cutover, choose to shut down the source VM so the final sync loses no data, then run Complete migration to stop replication and clean up. The tool itself scales well: one appliance supports up to 300 VMs replicating at once per vCenter Server, or 500 with a scale-out appliance. In practice, the pace is set by how quickly application owners can test and sign off.

Plan Protection on Day One

A migrated VM isn't protected until you set up backup and, where it is needed, replication to a second region. Decide that per server before cutover, not after. Our post on Azure Backup versus Azure Site Recovery walks through which servers need which.

And if some workloads have to stay on VMware for now, Azure VMware Solution runs VMware vSphere clusters on dedicated Azure hosts (minimum three per deployment). It can buy time for the hard cases while the rest move to native Azure VMs. Budget for the licence as well: since November 1, 2025, new Azure VMware Solution deployments need a portable VMware Cloud Foundation subscription bought from Broadcom (Microsoft's licensing reference).

Talk It Through Before You Replicate

Discovery, dependency mapping and a test migration on a few representative VMs will tell you more about your VMware exit than any quote. If you want a second set of eyes on your hosts, blockers and target platform, we're happy to review them with you. Book a VMware exit review.