Start with a VM-by-VM inventory

Record the guest operating system, firmware mode, CPU, memory, every virtual disk, virtual NIC, port group, VLAN, static IP, DNS settings, snapshots, backup jobs, monitoring and application owner. The conversion method cannot compensate for a missing dependency map.

Map virtual networking before conversion

VMware port groups and Hyper-V virtual switches are not interchangeable labels. Build a mapping for VLAN IDs, management networks, production networks, storage paths and any trunking or teaming design. For static workloads, record the current IP configuration before the cutover.

Verify storage and recovery capacity

Confirm the Hyper-V destination has enough usable storage for the converted VMs, growth and the backup design. Validate that the destination backup platform supports the new host and that the source remains recoverable until the migrated workload is accepted.

Plan for a controlled cutover

  • Define the final synchronization or conversion point.
  • Power down or isolate the source at the agreed point so duplicate identities do not exist on the network.
  • Connect the target VM to the intended virtual switch and VLAN.
  • Validate boot, storage, IP configuration, DNS, routes, services and applications.
  • Run or confirm the new backup job before retiring the source.

Microsoft's Windows Admin Center conversion option

Microsoft currently documents a VM Conversion extension in Windows Admin Center for VMware-to-Hyper-V scenarios. It uses synchronization followed by a final migration phase and has specific prerequisites and supported guest operating systems. Because the feature is documented as preview, evaluate its current status and suitability before building a production cutover around it.