The free standalone Hyper-V Server product was discontinued after 2019 and never replaced. What is left is a hypervisor you reach by licensing Windows Server per core, with minimums, plus CALs, plus anything you use to manage it. We move those workloads to Proxmox VE - piloted, staged, and reversible.
Hyper-V Server 2019 was the last free standalone release. There was no 2022 or 2025 equivalent, so running Hyper-V in a supported way now means licensing Windows Server on the host - per core, with a minimum core count per processor and per server, whether or not your hardware is that large.
Then the stack continues. Standard edition entitles you to a small number of virtualized instances, so any real consolidation pushes you towards Datacenter. Client access licences are counted separately. Centralized management beyond a handful of hosts pulls in System Center. Failover clustering expects shared storage, which is its own purchase and its own renewal. And the newer direction - Azure Local, formerly Azure Stack HCI - is billed per core per month, which is a subscription by another name.
None of that is a scandal. It is simply a bill that grew quietly, attached to a component most teams still describe as the free option.
Hyper-V is a capable hypervisor - this is not an argument that it is bad technology. It is an argument about what you are paying, what you are locked into, and what happens on the day the person who built it leaves.
| Hyper-V today | Proxmox VE, co-managed by us | |
|---|---|---|
| Host licensing | Windows Server per core, with per-processor and per-server minimums. No free standalone product since 2019. | Open source. An optional support subscription per socket - nothing gating the hypervisor itself. |
| Guest density | Standard entitles you to a limited number of instances; real consolidation pushes you to Datacenter. | Density is a function of your hardware, not your edition. |
| Access licensing | CALs counted separately, per user or per device. | Not applicable to the platform. Windows guests keep their own licensing. |
| Management | Hyper-V Manager, Windows Admin Center, or System Center at additional cost. | Built-in clustered web interface covering every node, plus an API. No separate management product. |
| Clustering & HA | Failover Clustering, generally expecting shared storage. | Built in. Shared storage if you have it, or local ZFS with scheduled replication if you would rather not buy another array. |
| Host patching | Tied to the Windows update cycle and its reboots. | Node-by-node maintenance with guests live-migrated off first. We schedule and run it. |
| Backup | Third-party product, licensed per VM or per socket. | Integrated incremental backup with verified restores - part of what we run for you. |
| Support | Microsoft or your reseller, contingent on entitlements. | Us, by name - with a vendor subscription underneath where you want it. |
| If you stop paying | Unlicensed hosts are a compliance problem, not just a support problem. | The platform keeps running. You lose our involvement, not your infrastructure. |
Hyper-V migrations are usually more forgiving than VMware ones, because the disk format converts cleanly and most environments are smaller. The discipline is the same: pilot first, cut over in waves, keep the original bootable.
Every VM, its generation, its disks, and what depends on it. Generation 2 VMs boot UEFI and need that carried across correctly - getting this wrong is the single most common cause of a guest that will not boot after import, and it is entirely avoidable.
Domain controllers get their own plan. In most environments the right answer is to stand up a new DC on the target platform and let replication do the work, rather than move the VM at all. Cheaper, safer, and it leaves you with a rollback by definition.
The new cluster is built and burned in while Hyper-V keeps running untouched. Where hardware is tight, we usually start by freeing a single node from the existing cluster.
VirtIO drivers staged into Windows guests while they are still running on Hyper-V, integration services accounted for, boot configuration confirmed. Doing this in advance is what keeps the cutover window short.
VHDX converted and attached on the target. We measure the conversion on the pilot so the maintenance window is based on your actual disk sizes and storage throughput rather than a guess.
Grouped by dependency. Each wave verified - service up, application tested, backups running - before the next begins.
We convert from a copy. The original VHDX files stay exactly where they are, and the Hyper-V VM definition stays registered and shut down. Rolling back a wave is powering the old VM back on - not a restore, not a rebuild.
The environment is documented as we go. Only when you release it do we reclaim the hosts - and at that point the Windows Server licences on them may be worth redeploying somewhere they actually earn their keep.
For your Windows guests, yes - and we will not pretend otherwise. Windows guest licensing follows the physical host it runs on regardless of which hypervisor is underneath, so that obligation does not vanish. What changes is that you stop paying for a Windows Server licence whose only job was to give you a hypervisor. Whether that adds up to a real saving depends on your host count and edition mix, and it is one of the first things we work out in the assessment.
In most cases we do not migrate them. We build new DCs on the new platform, let Active Directory replicate, transfer roles, then retire the old ones. It is the lower-risk path and it gives you a rollback that needs no special handling.
Your SAN does - iSCSI and Fibre Channel both work. The clustering itself is replaced by Proxmox's own clustering rather than translated. If the SAN is approaching end of life, this is the moment to ask whether you want to replace it at all, or move to local ZFS with replication between nodes instead.
If you have already committed to it, the economics are different and you should probably finish that thought rather than turn around. If you are being quoted it as the natural next step and the per-core monthly figure is what brought you here, then it is worth comparing properly - which is exactly what the assessment gives you.
Most mainstream backup products support Proxmox now, so sometimes the answer is simply yes. Often the better question is whether you still need to pay for it - integrated backup with verified restores is part of what we run for you, and that licence line is frequently the second saving people find.
A typical two or three node Hyper-V cluster with twenty to forty VMs is a couple of weeks of assessment and build, then two or three maintenance windows. We give you the schedule after the inventory, not before.
No - that is the model. We run the platform and your team keeps doing what they are good at. You get access, visibility and documentation, and as much or as little hands-on involvement as you want. Nobody is expected to become a virtualization specialist as a condition of the move.
Hypervisor licensing. Firewall subscriptions. Backup seat counts. Per-endpoint tooling. Individually they are line items - together they are a business you do not control, renewing on somebody else's schedule at somebody else's price.
A technical conversation, not a discovery call.
Tell us what you are running - host count, Windows editions, VM count, whether you are clustered. We will tell you what the move looks like, what it is likely to save, and whether it is worth doing at all.
We do not share your details, and we will not add you to a drip campaign.