Migrating from Hyper-V to Proxmox VE

Not every move to Proxmox starts with VMware. More and more teams are leaving Hyper-V, often over licensing cost, strategic dependence on Microsoft, and a wish to regain control of their virtualization platform. The destination is the same as for VMware exits: Proxmox VE, an open-source hypervisor with no per-core or per-VM licensing. This guide walks through a Hyper-V to Proxmox VE migration designed not to disrupt your services.

Why teams leave Hyper-V

Hyper-V is not a bad hypervisor. The problem lies elsewhere. The feature is tied to Windows Server: your right to run virtual machines depends on Windows Server licensing (Standard or Datacenter) and, very often, on a Software Assurance agreement. Operating at scale goes through System Center, another component to license and maintain. And Microsoft’s product direction keeps nudging towards Azure, which does not fit every strategy, especially when sovereignty and cost control matter.

Proxmox VE answers all three points. The software is open source: no per-core or per-VM licensing. A per-socket subscription, which funds Proxmox development and gives you the stable enterprise repository and vendor support, replaces the Windows Server and System Center licensing stack at a fraction of the cost. Operations stay in your hands, on your hardware or with the host of your choice.

Assess before you move

As with any migration, the assessment phase makes the difference. Before touching anything, inventory your Hyper-V estate:

• Every VM: vCPU, RAM, VHDX disk sizes, guest OS, and how critical it is.
• Generation: generation 1 (BIOS) or generation 2 (UEFI, sometimes with Secure Boot). That detail decides whether the VM boots on Proxmox.
• Dependencies: which VMs talk to which, and what cannot tolerate downtime.
• Networking: virtual switches, VLANs, virtual NICs, firewall rules.
• Storage: volumes, total capacity, IOPS profile, and any checkpoints to merge before migrating.

This inventory tells you how to size the Proxmox VE cluster and in which order to migrate. Start with the low-risk VMs.

Prepare the VMs on the Hyper-V side

Two steps happen while the VM is still running under Hyper-V, and they prevent most cutover incidents.

First, merge the checkpoints. A VM with a checkpoint chain does not have one clean disk but a stack of differencing files. Delete or merge those checkpoints to get a single, consistent VHDX to convert.

Second, remove the Hyper-V integration services on Windows guests and prepare the ground for the VirtIO paravirtualized drivers that Proxmox uses. Doing this before the cutover saves you blue-screen boots after migration.

Convert the disks

The technical core of the migration is disk conversion. Hyper-V stores its disks in VHDX format. Proxmox VE works with qcow2 or raw. The qemu-img tool converts a VHDX to qcow2 or raw in a single command, then you attach the converted disk to a new Proxmox VM whose hardware configuration mirrors what you recorded during the assessment.

This is a cold migration: the VM is stopped during the copy and conversion. The downtime window depends on disk size and storage throughput. That is why migration order and dependency grouping matter so much.

The Windows guest case

Most Hyper-V estates are mostly Windows. Three points deserve special attention:

• VirtIO drivers: install them so the VM gets a fast paravirtualized disk and network. Stage the installation while the VM is still running, and finish it on the first boot under Proxmox.
• Boot mode: a generation 2 VM expects UEFI. Configure the Proxmox VM accordingly (OVMF), or it will not boot. If Secure Boot was enabled, plan to handle it or disable it for the cutover.
• Windows activation: changing the hardware platform may require reactivation. Anticipate it for critical servers.

Cut over and validate

For each migrated VM, validate before declaring it done: it boots, the network responds, the application works, and performance matches the baseline measured during the assessment. Keep the original VHDX until validation. That is your rollback.

Migrate in waves, grouped by dependency. Critical VMs go last, once the process is proven on the rest of the estate.

Where it gets hard

The conversion mechanics are well documented. The hard part is running the migration without service disruption: merging checkpoints cleanly, handling generation 2 guests and Secure Boot, sequencing dependencies, and sizing the target cluster so you do not migrate onto a fragile platform.

That is the work our Proxmox migration service takes on. We assess the existing Hyper-V estate, size and build the Proxmox VE cluster, run the migration in waves and validate each one. You reduce your dependence on Windows Server licensing without carrying the migration risk yourself. Once the migration is done, you operate the cluster yourself or hand it over for managed Proxmox hosting.