Migrate Hyper-V to Proxmox: step by step with direct VHDX import

Moving a VM from Microsoft Hyper-V to Proxmox VE is technically less spectacular than many expect: Proxmox imports VHDX files directly, without conversion. The real stumbling blocks are the VirtIO drivers, the correct firmware type (Gen1 vs. Gen2) and Windows activation. This guide walks through all six steps (as of July 2026, Proxmox VE 9.x - the commands also apply to 8.x).

Why companies are switching right now (Hyper-V Server 2019 was the last free version, Windows Server 2025 licenses per core) and how a planned migration of entire environments works is covered on our service page Hyper-V to Proxmox migration - this guide focuses on the technical side.

Step 1: Prepare and shut down the VM

Before the move, in Hyper-V:

1. Merge checkpoints: Delete all of the VM's checkpoints in Hyper-V Manager and wait until Hyper-V has merged the AVHDX differencing files into the base VHDX. A checkpoint chain cannot be imported.
2. Suspend BitLocker (if active): Suspend-BitLocker -MountPoint "C:" -RebootCount 0 - without -RebootCount 0, protection re-enables after the first reboot, as the default is 1. Back up the recovery key: the TPM measurements change with the platform switch.
3. Note the configuration: generation (1 = BIOS, 2 = UEFI), vCPU count, RAM, static IP addresses, VLAN assignment. The MAC address changes with the move - Windows treats the new NIC as a new device.
4. Shut down cleanly (no saved state, no pause).

Optional but proven: pre-install the VirtIO drivers under Hyper-V (mount the virtio-win ISO, run the installer). Windows will then boot straight from a VirtIO disk after the import, and step 5 shrinks to a quick check.

Step 2: Transfer the VHDX to the Proxmox host

A formal export via Hyper-V Manager is only needed if you have no direct access to the VHDX files - the disk files themselves are sufficient. Transfer options:

• SMB share from the Hyper-V host, mounted on the Proxmox host: mount -t cifs //hyperv-host/share /mnt/hyperv -o username=admin
• SCP/rsync from a staging machine: rsync -avP disk.vhdx root@pve:/var/lib/vz/import/
• For very large disks: pre-sync while the VM is still running and a final delta sync after shutdown - this cuts downtime to minutes.

Both dynamic and fixed VHDX are supported; Proxmox also imports VHD (the older format) directly.

Step 3: Create the target VM in Proxmox

Create the VM without a hard disk first (choose "Do not use any media" in the wizard and remove the suggested disk). The crucial part is mapping the Hyper-V generation:

Further recommendations: set the matching OS type (qm set 201 --ostype win11 covers Windows 11, Server 2022 and 2025), CPU type host (or x86-64-v2-AES in mixed clusters for live migration), SCSI controller VirtIO SCSI single, network card VirtIO.

Step 4: Import the VHDX with qm disk import

The core of the migration is a single command on the Proxmox host:

qm disk import 201 /mnt/hyperv/disk.vhdx local-zfs

201 is the VM ID, local-zfs the target storage. Proxmox detects the VHDX format automatically and converts during import to the target storage's format (RAW on ZFS/LVM-thin, optionally QCOW2 on directory storage with --format qcow2). A manual qemu-img convert intermediate step is not required.

Then attach the imported disk and make it bootable:

# The disk appears as "unused0" - attach it (first boot deliberately via SATA, see step 5):
qm set 201 --sata0 local-zfs:vm-201-disk-1
# Set the boot order:
qm set 201 --boot order=sata0

With multiple VHDX files, repeat the import per disk; data disks can be attached directly as VirtIO SCSI - only the boot disk needs the SATA detour.

Step 5: Install VirtIO drivers and switch to VirtIO

Windows does not ship VirtIO drivers - a boot disk attached straight to VirtIO SCSI without pre-installed drivers ends in the INACCESSIBLE_BOOT_DEVICE bluescreen. The stable path:

1. Start the VM with the boot disk on SATA - Windows boots without extra drivers.
2. Mount the current virtio-win ISO (download at Fedora) as a CD drive and run virtio-win-guest-tools.exe - the bundle installs storage (viostor/vioscsi), network (NetKVM) and balloon drivers plus the QEMU guest agent in one pass. Note: virtio-win-gt-x64.msi on its own contains only the drivers, not the agent.
3. Enable the guest agent in the VM options (qm set 201 --agent 1) - it replaces the Hyper-V integration services for shutdown, IP reporting and consistent backups.
4. Shut down, reattach the boot disk from SATA to VirtIO SCSI (qm set 201 --scsi0 ... --boot order=scsi0, remove the SATA entry), verify the NIC is set to VirtIO.
5. Reboot - Windows binds the drivers and runs at full I/O performance.

An alternative from the Proxmox wiki: instead of the SATA detour, attach a small dummy disk (1-2 GB) to VirtIO SCSI in addition, boot, wait for the driver binding, then reattach the boot disk and remove the dummy disk.

The Hyper-V integration services have been part of the operating system since Windows Server 2016 and do not need to be uninstalled; they simply remain inactive. Linux guests skip the detour entirely: VirtIO drivers are built into the kernel, so the disk can go straight to VirtIO SCSI - just check /etc/fstab and the bootloader for device-name changes, install the qemu-guest-agent, and with Hyper-V-optimized images make sure the virtio modules are included in the initramfs.

Step 6: Test and activate

• Network: The NIC appears as a new device with a new MAC - reapply static IPs, then remove the old, hidden NIC in Device Manager. Proxmox sets VLAN tags on the bridge or directly on the VM NIC.
• Functional test: services, applications, shares, domain join - only delete the source VM in Hyper-V after a successful test. Until then it remains your rollback.
• Activation: AVMA requires a Hyper-V Datacenter host and does not work on Proxmox - switch previously AVMA-activated VMs to KMS, AD-based activation or MAK. The licensing rules (core minimums, Standard vs. Datacenter, the cluster question) are covered in depth in Licensing Windows Server on Proxmox.
• Monitoring and backup: add the new VM to your backup jobs (ideally with Proxmox Backup Server) and to monitoring.

Where the DIY path hits its limits

For a handful of VMs, this path is perfectly doable on your own. It gets more demanding with dozens of interdependent VMs, failover-cluster environments with Cluster Shared Volumes, tight maintenance windows, or domain controllers and database servers where order matters. For such projects we plan and run the migration end to end - with inventory, test migration, cutover plan and operations afterwards: Hyper-V to Proxmox migration, followed on request by Managed Proxmox from €179.90 per node per month. Happy to discuss your setup in a free initial consultation.