Hyper-V to Proxmox: Migration Without Data Loss

VMware moved to Broadcom in 2024 — and as a consequence many mid-market customers switched to Proxmox. What many overlook: Hyper-V estates are increasingly migrating to Proxmox as well. The reasons vary — Microsoft Datacenter Edition licence costs, the wish for a single hypervisor platform instead of mixed operation, consolidation of smaller Hyper-V hosts onto a Proxmox cluster — but technically the migration follows the same basic principles.

This article walks through the steps concretely. Those coming the other way from VMware will find practical material on our site too: Proxmox-VMware migration case study and From VMware to Proxmox: the switch.

Preparation Inside the Guest OS — Before the Move

The decisive point: whatever needs to be done inside the guest OS should be done while the VM is still running on Hyper-V. After the move it becomes significantly more difficult.

For Windows VMs:

1. Uninstall Hyper-V Integration Services / Guest Services. Remove via Programs & Features. These components expect Hyper-V specific interfaces and lead to bluescreens or performance problems under KVM/QEMU.
2. Pre-install VirtIO drivers. This is the most important step. Download the current VirtIO ISO from Fedora People (virtio-win), mount it in the still-running VM and install all drivers (storage, network, balloon, serial). If this step is forgotten, Windows will not boot after migration because it cannot find a driver for the new VirtIO-SCSI disk.
3. Check BitLocker. If active, decrypt before migration or keep the recovery key at hand.
4. Note the MAC address. Licence activations are often tied to MAC address or hardware ID.

For Linux VMs:

1. Check Hyper-V specific modules. lsmod | grep hv_ shows loaded Hyper-V modules. These have no function under Proxmox but mostly do no harm — modern kernels load the matching drivers depending on the hypervisor.
2. Switch fstab to UUIDs. If /dev/sda1 is used instead of UUID, the move to VirtIO-SCSI (/dev/vda1) can cause boot problems. UUIDs are robust.
3. Rebuild initramfs. On modern distributions run update-initramfs -u (Debian/Ubuntu) or dracut -f (Rocky/RHEL/CentOS) once so the VirtIO modules end up in the initramfs.

Convert VHDX to QCOW2

Hyper-V uses VHDX (or older VHD). Proxmox prefers QCOW2 or raw — both are native QEMU formats. Conversion runs with qemu-img:

# On a Linux system with qemu-utils:
qemu-img convert -p -O qcow2 /path/to/vm.vhdx /path/output.qcow2

# Alternatively raw (slightly faster, larger footprint):
qemu-img convert -p -O raw /path/to/vm.vhdx /path/output.raw

The -p flag shows a progress bar — helpful with large VHDX files (several hundred GB).

Key points:

• VHDX dynamic is automatically unpacked. QCOW2 is also dynamic (thin-provisioned).
• Snapshots living in the VHDX chain (.avhdx files) must be merged first — either in Hyper-V via “Delete checkpoints” or with qemu-img rebase.
• Do not delete the source file before the new VM has started successfully.

Import Into Proxmox

There are three pragmatic ways to get a QCOW2/raw disk into a Proxmox VM:

Variant 1 — qm importdisk (recommended). First create an empty VM in Proxmox (suitable CPU, RAM, no storage). Note the VM ID, e.g. 101. Then on the Proxmox host:

qm importdisk 101 /path/output.qcow2 local-lvm --format qcow2

The disk is imported into the storage pool and afterwards is visible as an unassigned disk in VM 101. Assign it to the VM via “Hardware → Disk → Add” in the GUI.

Variant 2 — copy manually. Place the file directly into /var/lib/vz/images/101/ and reference it in the VM config (/etc/pve/qemu-server/101.conf). Works, but more error-prone.

Variant 3 — Proxmox VE migration tool. Since version 8.2 Proxmox ships a proxmox-vm-migrate script that can talk to the source hypervisor and transfer disks live. Tested for VMware, experimental for Hyper-V — we still recommend the manual export-convert-import path.

Boot Mode: BIOS vs. UEFI, Generation 1 vs. 2

A pitfall that often catches migration newcomers: Hyper-V has Generation 1 (BIOS) and Generation 2 (UEFI).

• Generation 1 → SeaBIOS in Proxmox. Default and uncomplicated.
• Generation 2 → OVMF (UEFI) in Proxmox. Requires a separate EFI disk volume in the VM config (efidisk0: local-lvm:vm-101-disk-1,size=4M).

If the EFI disk is forgotten, the VM does not boot. Add the EFI disk under “Hardware” in the Proxmox GUI before the first start.

For Generation 2 VMs with Windows the Secure Boot configuration also needs attention. We recommend disabling Secure Boot during migration — once the VM runs stably, it can be re-enabled.

VirtIO Instead of IDE / SATA — the Performance Point

In the newly created Proxmox VM the imported disk is by default often set up as SCSI with the lsi controller. For maximum performance switch to:

• SCSI controller: VirtIO SCSI single
• Disk bus: SCSI with VirtIO driver
• Network: VirtIO (paravirtualised)

Important: the VirtIO drivers must be present in the guest OS before the switch. That is exactly why step 2 of preparation (pre-install VirtIO drivers) was so important.

If forgotten: boot first with an IDE disk, install VirtIO drivers in the running guest, then shut down the VM and switch the disk bus to VirtIO SCSI.

Network and MAC Addresses

The VM receives a new MAC address by default in Proxmox. That can cause two problems:

1. DHCP reservations / inventory. If the DHCP server assigns a reserved IP per MAC, the IP changes after migration. Solution: in Proxmox set the old MAC address manually (in the VM hardware under “Network Device → Advanced”).

2. Software licence activation. Some software (especially older Windows Server editions, database licences, CAD software) is tied to MAC address or hardware ID. For Microsoft Windows a renewed activation via phone activation usually helps; for specialised software clarify with the vendor in advance.

Test VM First — Production in a Maintenance Window

The most important organisational recommendation: migrate a test or staging VM first, walk through the process fully, document — and only then tackle production systems in a maintenance window.

Typical sequence for a production VM:

1. Schedule maintenance window (often weekend, evening).
2. Shut down the VM in Hyper-V (graceful shutdown, not hard).
3. Copy VHDX to the migration system (NFS share, external USB 3 disk, fast network).
4. Convert with qemu-img.
5. Import into Proxmox.
6. Adjust hardware in the VM config (disk bus, network, EFI for Gen 2).
7. First start and observe boot behaviour — open console, not just pings.
8. Licence activation, application functional test, configure backups.
9. Only after a successful smoke test: clean up the Hyper-V source (archive VHDX, delete VM in Hyper-V).

Rule of thumb: plan 30-60 minutes of pure maintenance window per production VM, plus 30 minutes buffer. For larger VMs (>500 GB) longer.

Cluster Aspects and Live Replication

If Proxmox is already set up as a cluster, the imported VM can be taken into an HA group after a successful boot. Anyone migrating a larger Hyper-V estate step-by-step benefits from a 3-node Proxmox cluster with shared storage — see Proxmox cluster with three nodes and shared storage.

A true live migration from Hyper-V to Proxmox (without downtime) is not possible with built-in means — the two hypervisors speak different memory-page protocols. Anyone who wants to minimise downtime can work with database- or storage-level replication at application level and limit the final cutover to seconds.

Conclusion

Hyper-V to Proxmox migration in 2026 is an established workflow: convert VHDX to QCOW2, import into Proxmox, adjust hardware profiles, ensure VirtIO drivers. The most common mistake is not the conversion itself but the missing preparation inside the guest OS — removing Hyper-V Integration Services and installing VirtIO drivers before migration saves hours of troubleshooting later.

For SMBs with five to thirty Hyper-V VMs the migration is doable in a weekend maintenance window. For larger environments a staggered approach over several weekends is advisable, with test-VM validation at the start. DATAZONE handles the migration end-to-end — from inventory through conversion to cluster takeover during ongoing operation.