VMware vs Hyper-V: Licensing, Features and Migration Compared
Hyper-V has no hypervisor licence of its own. The right to run it rides entirely on Windows Server: buy Datacenter edition and every VM on that host is covered, unlimited, at no extra per-VM cost. VMware, since Broadcom's acquisition, is the opposite: there is no free ride on top of anything else, the hypervisor itself is the licensed product, sold per core, with a minimum order that has already doubled once.
That single structural difference is most of what separates the two platforms' cost, not a feature gap. This is the comparison: what each licence actually buys, what changed under Broadcom, and what a migration between them does and does not simplify.
What each licence buys
| VMware (VCF, Broadcom) | Hyper-V (Windows Server) | |
|---|---|---|
| What is licensed | The hypervisor and stack (vSphere, vSAN, NSX) directly, per core | Windows Server Datacenter edition; Hyper-V itself carries no separate fee |
| Minimum order | 72 cores per deployment, since April 10, 2025 (was 16) | 16 cores per server (8 per processor), same floor as every Windows Server edition |
| VM density included | Not a licensing variable; cores are cores regardless of VM count | Datacenter: unlimited VMs per host. Standard: 2 VMs (OSEs) per licence, stacked for more |
| Perpetual option | Discontinued; subscription only | Available via Volume Licensing, alongside subscription/CSP |
| Management tooling | vCenter bundled into the stack | System Center (SCVMM) licensed separately, per core on managed hosts |
What changed under Broadcom
Three changes moved together, and each one independently raises the bill. Per-CPU licensing became per-core, which for any host with high core-count processors, the norm on recent hardware, multiplies the unit count before a single price change is applied. Perpetual licences were discontinued, converting a one-time purchase into a recurring subscription with no option to stop paying and keep running the version already deployed. And the minimum order per deployment rose from 16 cores to 72, covered in full in the 72-core minimum change, which prices a small deployment as if it were a much larger one regardless of actual core count.
Individually any one of these is a meaningful shift. Together, on top of a list price that itself moved from per-CPU to per-core math, they are why small and mid-sized estates report the largest percentage increases: the fixed costs (the 72-core floor, the subscription conversion) land hardest on a deployment that was already running close to the old minimum.
The Hyper-V side of the sum
Hyper-V's cost is Windows Server Datacenter's cost, priced the same way Windows Server itself is priced: per-core, 8-core minimum per processor, 16 per server, sold as 2-packs and 16-packs of Core Licences. Datacenter's unlimited-VM right is what actually competes with VMware's density story, and it is the same right whether the host runs one VM or two hundred. Standard edition, with its 2-OSE cap, is the wrong comparison to VMware entirely; a Standard-licensed host stacked for VM density starts costing more than Datacenter fast.
What Hyper-V does not include: storage and network virtualization at VMware's vSAN and NSX depth. Microsoft's equivalents, Storage Spaces Direct and software-defined networking in Windows Server, are real but licensed and operated differently, and a like-for-like migration has to price that gap, not assume Datacenter alone replaces the whole VCF stack.
What a migration actually simplifies, and what it does not
- It simplifies the licence count. One SKU, Windows Server Datacenter, replaces a stack of VMware products each with their own per-core pricing.
- It does not simplify the OS estate underneath. Guest operating system licensing, Windows Server, Linux distributions, is unchanged by which hypervisor hosts them; nothing about a hypervisor migration touches guest OS entitlement.
- It does not remove management tooling cost. SCVMM's per-core licensing on managed hosts is a real, separate line that a VMware-to-Hyper-V comparison built on Windows Server pricing alone will understate.
- It does not remove the migration project itself. Retraining, re-platforming automation, and validating workload compatibility are real costs a per-core price comparison does not capture, and they belong in the same decision as the licensing delta.
The platform choice is not only a VMware-versus-Hyper-V question either: the same structural logic, what a hypervisor licence actually covers and what counts toward it, is the same decision Oracle's partitioning policy forces on a database estate, where the hypervisor decides whether a licence covers one VM or the whole cluster. A platform decision made for one vendor's licensing terms has consequences for every other vendor's software running on the same hosts.
Whichever platform an estate runs, the number that actually matters is host count, core count per host, and VM density, the same physical facts a defensible position needs whatever hypervisor and whatever vendor software sits on top. Infrastructure Mapper reads that from the inventory already collected, so a VMware-versus-Hyper-V cost comparison, or the mixed estate most migrations actually run for a year or two, is built on the real host and cluster shape, not a spreadsheet estimate.
Checklist
- Every VMware host's core count checked against the 72-core minimum order, not the host's actual core count alone.
- A Hyper-V comparison priced at Datacenter, not Standard, for any host running meaningful VM density.
- SCVMM and guest OS licensing included in the total, not just the hypervisor licence.
- Storage and network virtualization gaps (vSAN, NSX versus Storage Spaces Direct) priced explicitly, not assumed equivalent.
