VMware to Hyper-V Migration: Step-by-Step Guide & Tools

Our virtualization migration services team runs VMware to Hyper-V migration projects on a fixed sequence: inventory, tool selection, synchronization, cutover, validation. This page documents that sequence with the current first-party tooling — the VM Conversion extension in Windows Admin Center — plus the alternatives, the disk format conversion mechanics, and the guest-level work (VMware Tools removal, drivers, static IPs) that determines whether the migrated VM boots and stays on the network.

Pre-migration assessment

Before any tool runs, build an inventory. Migration failures trace back to items missed here far more often than to the conversion itself.

• VM inventory — per VM: guest OS and version, vCPU/RAM allocation, disk count and provisioning type (thick/thin), total consumed storage, firmware type (BIOS or EFI). Guest OS support on Hyper-V and on the conversion tool must be checked per VM; the WAC extension's supported guest list covers Windows Server 2012 R2 through 2025, Windows 10/11, Ubuntu 20.04/24.04, Debian 11/12, RHEL 9, AlmaLinux, and CentOS.
• Firmware mapping — BIOS-firmware VMs map to Hyper-V Generation 1, EFI-firmware VMs to Generation 2. A converted disk attached to the wrong generation does not boot.
• Dependencies — application-to-application traffic, hardcoded IPs in application configs, licensing tied to MAC address or BIOS identifiers, backup agents, and antivirus filter drivers. Group dependent VMs into the same cutover window.
• Snapshots — the WAC extension prechecks fail if the source VM has active snapshots. Consolidate and delete snapshots before synchronization.
• Blockers — VMs with RDM disks, vSphere fault tolerance, or SR-IOV/passthrough devices need per-case handling; no converter moves those configurations directly.
• Target capacity — the destination Hyper-V host needs disk space for the full converted VHDX set plus memory and vCPU headroom; the extension prechecks verify both.

Tool options

For a supported guest OS and a vCenter-managed source, the WAC extension is the default choice: it is first-party, free, and the only option in this list with online sync plus minimal-downtime cutover. Note its preview status — Microsoft does not commit to support services for preview extensions, which matters for change-control sign-off in regulated environments.

Step-by-step: WAC VM Conversion extension

Step 1 — Prerequisites

On the environment:

• VMware vCenter 6.x, 7.x, or 8.x, with credentials that have privileged access to the VMs being migrated. Standalone ESXi without vCenter is not the supported topology.
• Hyper-V role installed on the target host, with local Administrators or Hyper-V Administrators membership.

On the Windows Admin Center gateway machine:

• WAC gateway version 2410 (build 2.4.12.10) or later, with administrator privileges.
• Latest VMware PowerCLI installed.
• VMware VDDK version 8.0.3 — this exact version; others are unsupported — extracted to C:\Program Files\WindowsAdminCenter\Service\VDDK.
• Visual C++ Redistributable packages: 2013 and the latest (VC++ 14.x).

Deploy the WAC gateway in the same site as the ESXi and Hyper-V hosts; the disk data flows through it, so WAN placement adds latency to every sync.

Install the extension from WAC under Settings > Extensions > Available Extensions > VM Conversion (Preview), then connect to the target Hyper-V server, open Extensions > VM Conversion (Preview), and connect to vCenter with its FQDN and credentials.

Step 2 — Synchronize

The extension runs prechecks before sync: no active snapshots on the VM, PowerCLI and the VC++ redistributables present on the gateway, VDDK at the expected path, a valid target disk path, sufficient memory and disk on the destination host, and CBT support on the VM. Fix any reported failure before proceeding.

1. In the VM list, select up to 10 VMs to synchronize.
2. Enter the path to store data on the Hyper-V host and select Synchronize.
3. The extension snapshots the source VM to track changes, copies the disk data to the destination host, and writes a VHDX at the specified path — all while the source VM keeps running.
4. Confirm the VHDX exists at the target path when the sync completes.

During synchronization you choose thick (fixed) or thin (dynamic) provisioning for the destination disks, matching or changing the source configuration.

Step 3 — Cutover (migrate)

Migration prechecks verify vCPU availability on the destination, no name collision with an existing Hyper-V VM, the Hyper-V role, the synchronized VHDX at the expected path, and no active snapshots. Then, from the Migrate tab:

1. Select the VM and confirm. The extension performs a CBT delta replication, powers off the source VM, runs a final delta sync to capture writes made during shutdown, and imports the VM into Hyper-V with its CPU, memory, and network settings.
2. Downtime is the final delta sync plus import — not the full disk copy. The delta size is a function of write rate since the last sync, so resync shortly before the cutover window to keep it small.
3. Keep the browser session active: migration requires a signed-in WAC session, and Microsoft's release notes recommend refreshing the session every 2 hours during long batch operations. A timed-out session can leave a migration stuck.

The migrated VM is then managed through Hyper-V Manager or WAC. Leave the source VM powered off but intact until validation completes — it is the rollback path.

Guest-level work: VMware Tools, drivers, IP and MAC

VMware Tools removal. Remove VMware Tools before cutover; after migration the guest is no longer on VMware and leftover Tools services and drivers produce boot delays and event-log errors. The WAC extension supports batch uninstall of VMware Tools for Windows VMs before migration; Linux guests require manual removal (vmware-uninstall-tools.pl or the distribution package manager, per the guest's install method). If Tools will not uninstall cleanly, Broadcom documents manual removal procedures on knowledge.broadcom.com.

Hyper-V drivers and Integration Services. Windows Server 2012 R2 and later ship the Hyper-V integration services in-box; no separate install is needed, and updates arrive through Windows Update. Linux guests are the failure point: Microsoft requires Hyper-V drivers (the hv modules in the kernel, or Linux Integration Services) to be present before migration, or the guest does not boot on Hyper-V. Modern distribution kernels include the drivers, but verify they load and are in the initramfs before cutover, not after.

Static IPs and MACs. The extension's static IP batch migration reapplies static IP configuration inside Windows and Linux guests after cutover. MAC addresses change by default — the Hyper-V VM gets a new virtual NIC with a Hyper-V MAC prefix. Where an application or license binds to the MAC, set a static MAC on the Hyper-V NIC manually:

Set-VMNetworkAdapter -VMName "APP01" -StaticMacAddress "00155D0A1B2C"

The extension preserves the BIOS UUID from the source VM, but the BIOS serial number format differs between VMware and Hyper-V; software that keys licensing to the serial number needs re-activation. DHCP-configured guests will request a new lease from a new MAC — pin reservations before cutover if the address must not change.

Manual disk conversion: VMDK to VHDX

For hosts without vCenter, unsupported guests, or one-off conversions, convert the disk directly. Power off the source VM, copy the flat VMDK off the datastore, then convert with qemu-img:

qemu-img convert -p -O vhdx -o subformat=dynamic source-flat.vmdk destination.vhdx

The Hyper-V Convert-VHD cmdlet converts between VHD and VHDX and between fixed and dynamic, but does not read VMDK — it is the second stage when another tool has already produced a VHD, or for post-conversion format changes:

Convert-VHD -Path .\server01.vhd -DestinationPath .\server01.vhdx -VHDType Dynamic

Cmdlet reference: Convert-VHD. After conversion, create the Hyper-V VM with the generation matching the source firmware (Generation 1 for BIOS, Generation 2 for EFI), attach the VHDX, and reconfigure CPU, memory, NICs, and IPs by hand — nothing carries over in this path. Downtime spans the whole copy-and-convert operation, so this method fits small disks and maintenance windows, not large production VMs.

Downtime planning

• Sync early, cut over late. With the WAC extension, run the initial synchronization days ahead; only the final delta happens in the window. Schedule a resync close to the cutover time so the delta is minutes of writes, not days.
• Order by dependency. Cut over database servers and their application servers in the same window, back ends before front ends.
• Budget for validation. The window ends when validation passes, not when the import finishes. Allow time per VM for the checklist below plus one reboot.
• Define rollback. Rollback is powering the source VM back on in vCenter. It stays available until the source VM is deleted, which should happen only after an agreed soak period — one to two weeks of clean operation is a common standard.
• DNS and ARP. If the IP is preserved, upstream switches update on the gratuitous ARP from the new MAC; if the IP changes, lower DNS TTLs ahead of the window.

Post-migration validation checklist

• VM boots on Hyper-V without stop errors; correct generation and firmware settings.
• VMware Tools absent from installed programs and services (Windows) or package list (Linux).
• Hyper-V integration services active — on the host: Get-VMIntegrationService -VMName "APP01"; on a Linux guest, hv_netvsc and hv_storvsc modules loaded.
• Network: expected IP present, gateway reachable, DNS resolving, application ports listening.
• Disk count, sizes, and drive letters/mount points match the source; no offline disks.
• Time synchronization correct (one source: either the Hyper-V time sync integration service or the domain/NTP hierarchy, not both fighting).
• Application-level check by the application owner, not just a ping.
• Licensing re-activated where it was bound to hardware identifiers.
• Backup agent reconfigured for the new platform and a first successful backup completed — the VMware-level backup job no longer protects this VM.
• Monitoring re-pointed; old vCenter alarms for the VM disabled.

When Proxmox fits instead

Hyper-V is not the only exit from VMware. Proxmox VE is the common choice where the estate is Linux-heavy, where there is no Windows Server licensing in place (Hyper-V's economics assume there is), or where KVM/QEMU tooling fits the team. Proxmox VE ships a built-in import wizard that connects to an ESXi host and imports VMs directly, and qemu-img on the Proxmox side converts VMDK to qcow2 or raw for manual paths. The assessment work in this guide — inventory, firmware mapping, guest driver preparation (virtio instead of Hyper-V drivers), IP/MAC handling, validation — applies unchanged; only the tooling differs. The platform trade-offs are covered in VMware alternatives.

Where migrations actually fail

• Linux guest without Hyper-V drivers in the initramfs — boots on VMware, black-screens on Hyper-V. Verify before cutover.
• Wrong VM generation — EFI source attached to a Generation 1 VM, or the reverse. No boot device found.
• Active snapshots on the source — precheck failure at sync time, discovered during the window instead of during assessment.
• WAC session timeout mid-migration — the migration stalls; recovery involves cleaning entries from migrationStatus.json and syncStatus.json on the gateway and re-running, per the troubleshooting documentation.
• VMware Tools left installed — slow boots and phantom NIC entries holding the static IP, which then cannot be assigned to the new adapter until the ghost device is removed.
• Backup gap — the VM migrates on Friday, the VMware backup job keeps "succeeding" against a powered-off source, and the Hyper-V copy runs unprotected until someone notices.

When to hand it over

A migration project across dozens of VMs is mostly scheduling, dependency mapping, and per-guest preparation — the conversion tool is the small part. Our team handles VMware to Hyper-V migrations end to end: assessment, tool selection, sync and cutover execution, and post-migration validation, with VMware ESXi support for keeping the source environment stable while the migration runs.