Broadcom’s subscription-only repackaging of VMware sent a wave of customers looking for a hypervisor they may already be paying for. Hyper-V is a mature Type-1 hypervisor that ships in the box with Windows Server, and for Windows-heavy estates it has a licensing twist that can make the move close to cost-neutral. This guide covers when Hyper-V is the right landing spot and how to execute the move cleanly.
The licensing angle that decides it
Windows Server Datacenter edition licenses the physical cores of the host and then grants unlimited Windows Server guests on that host. If you run mostly Windows VMs, you may already be buying (or close to buying) Datacenter licensing for those guests, so the hypervisor itself effectively comes for free, and you stop paying a separate per-core vSphere subscription on top. The comparison flips against Hyper-V when your estate is mostly Linux: there’s no Windows-guest density benefit to harvest, and Proxmox or XCP-ng may be a better fit.
The trade you are making
You gain a hypervisor with first-party support, deep Windows and Active Directory integration, and Failover Clustering for HA. You give up vCenter’s polish: centralized management comes from System Center Virtual Machine Manager (SCVMM), which is a separately licensed System Center component, or from the free Windows Admin Center and Failover Cluster Manager for smaller estates. Linux guests are supported and run well, but the ecosystem is Windows-first.
Architecture mapping
- vCenter → SCVMM (full fleet management) or Windows Admin Center + Failover Cluster Manager (lighter).
- vSphere HA → Windows Server Failover Clustering (WSFC) with Cluster Shared Volumes (CSV).
- DRS → Dynamic Optimization in SCVMM (no exact match without SCVMM).
- vSAN → Storage Spaces Direct (S2D) for hyper-converged; or keep your existing SAN via CSV.
- VMFS datastores → CSV on S2D or block storage.
- Distributed vSwitch → Hyper-V Virtual Switch with VLANs and Switch Embedded Teaming (SET) for NIC teaming.
Getting the VMs across
Common V2V paths, in increasing automation:
- Disk conversion. Power off the VM, then convert:
qemu-img convert -f vmdk -O vhdx source.vmdk target.vhdx. Create a VM and attach the disk. StarWind V2V Converter is a popular free GUI for the same job. - SCVMM V2V for fleets, or Azure Migrate if a stop in Azure fits the plan.
- Backup-tool restore. Veeam and similar can restore a VMware backup directly to a Hyper-V target.
The steps teams forget matter more than the copy itself: uninstall VMware Tools while the VM is still on ESXi, match the VM generation to the source firmware, install Hyper-V Integration Services / guest services, fix the synthetic NIC and static IP, and re-activate Windows.
The Gen1 vs Gen2 trap
Hyper-V has two VM types. Generation 1 emulates BIOS; Generation 2 is UEFI with Secure Boot. A guest that booted UEFI on vSphere must become a Gen2 VM, and a BIOS guest must be Gen1, you cannot change generation after creation, and a mismatch yields an unbootable VM. For Linux Gen2 guests, either disable Secure Boot or set the template to the Microsoft UEFI Certificate Authority so the bootloader is trusted.
Features with no clean Hyper-V equivalent
A few vSphere features have no clean Hyper-V equivalent and need a plan before cutover:
- vSphere Fault Tolerance. Hyper-V offers Failover Clustering restart, not lockstep continuous availability. Workloads that depended on FT need application-level clustering instead.
- Storage vMotion nuance. Hyper-V supports live and storage migration, but the cross-storage live moves you take for granted on vSphere may require Failover Clustering and CSV to be configured correctly first, so design shared storage before you rely on it.
- NSX segmentation and distributed firewall. Recreate these with VLANs on the Hyper-V Virtual Switch plus host or Windows Firewall policy, or a third-party SDN; there is no import path.
- VMware-specific tooling. vRealize/Aria automation, vSphere tags, and SPBM policies do not carry over. Rebuild templates, tagging, and placement rules natively.
Sign-off checks per VM
Verify the same items on every migrated VM so the runbook stays reliable:
- VM generation matches source firmware (Gen2/UEFI or Gen1/BIOS) and the guest boots to a login prompt.
- VMware Tools was removed while the VM was still on ESXi, and Integration Services / guest services are installed and healthy.
- Synthetic NIC is bound to the right virtual switch and VLAN, with the correct static IP, gateway, and DNS.
- Windows is re-activated and, for domain members, the machine account and time sync are intact.
- A backup runs and a test restore boots on the Hyper-V target.
- A live migration or a drained-node failover completes cleanly in the cluster.
Piloting the rollout
Run a pilot wave end to end, convert, drivers, validate, backup/restore test, then a live HA failover by draining a cluster node. Document the runbook and timings, then repeat wave by wave. Keep each source VM powered off but intact through hypercare so rollback is instant.
Net-net for Windows shops
For Windows-centric estates, vSphere → Hyper-V can be the cheapest exit because Datacenter licensing you may already need covers the guests. The technical risks are the Gen1/Gen2 firmware match, removing VMware Tools first, and rebuilding HA on Failover Clustering. Model your per-core numbers in the calculator above, and treat them as illustrative until a reseller quotes your exact licensing position.