Migrate from Hyper-V to Proxmox VE

Migrate from Hyper-V to Proxmox VE: what the move involves

Moving Hyper-V virtual machines to Proxmox VE is a repeatable cycle of export, convert, import and validate, and it stays manageable for a small pilot while requiring more planning for clustered Windows workloads. Teams usually start this work when a Windows Server license renewal, a cost review or a requirement to keep workloads inside their own infrastructure forces a decision. The people doing the work are platform engineers who are comfortable with both Windows guests and Linux hosts, because the export happens on the Hyper-V side while the import, driver changes and networking happen on Proxmox VE. Many organizations bring in an implementer such as DeployOpen for the cluster design and the first production waves, then hand routine moves to their own staff. Effort and risk depend mostly on how many workloads are clustered, how much data sits on each disk and how many guests depend on specific Windows roles. Confirm these figures with your own inventory rather than relying on a general estimate.

Proxmox VE is licensed under the GNU Affero General Public License, version 3, and every subscription tier includes the same software features. The Community, Basic, Standard and Premium subscriptions differ in support entitlements and access to the enterprise repository, so the choice is about support and operations, not feature gates. The software can run without a subscription, but the enterprise repository is the recommended source for production, and a no-subscription setup is suited to testing. Ask your implementer and Proxmox sales to confirm the current tier pricing and the number of CPU sockets in your hosts, since the subscription is charged per socket per year. Your Windows Server and guest licensing does not change with the hypervisor, so keep those costs in the same model.

Before the first export, decide which workloads move in which order. Start with a non-critical VM to test the full path: export with Export-VM, import the VHDX disks with qm disk import, change the storage controller and network adapter to VirtIO, and confirm the Generation 2 firmware is set to UEFI on the Proxmox side. Clustered workloads need a different plan because Proxmox high availability requires at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing. Plan cutover windows for each application tier, keep the Hyper-V source intact until the validated VM has run successfully, and test backups on the target before you retire any source host. The Proxmox wiki migration guide lists the import paths and the limits you should check before you commit.

Which Hyper-V capabilities map to Proxmox VE, and which need rework

This table maps common Hyper-V capabilities to their closest Proxmox VE equivalents and labels each as clean, needs rework or a gap to confirm. Use it to scope a pilot, then test each row against your own guests and hardware before committing to a cutover.

Hyper-V capability	Proxmox VE equivalent	Migration note
VM configuration and Generation 1 versus Generation 2 firmware	KVM guests with SeaBIOS (BIOS) or OVMF (UEFI) firmware selected per VM	Needs rework: Generation 2 VMs use UEFI, so set the firmware to OVMF and confirm the EFI disk before first boot. Generation 1 VMs usually map to SeaBIOS.
VHDX disks	Disk images imported with qm disk import into Proxmox storage	Needs rework: convert or import VHDX disks and confirm the target format on your chosen storage (LVM, ZFS, Ceph RBD or NFS). Confirm this path in a pilot.
Windows guest drivers (VirtIO)	VirtIO network and storage drivers from the Windows VirtIO driver package	Needs rework: install VirtIO storage and network drivers before switching disk and NIC bus types, or the guest may fail to boot. Keep a rollback copy.
Hyper-V Integration Services	QEMU guest agent and VirtIO balloon, installed inside the guest	Needs rework: remove Hyper-V integration components from the guest and install the guest agent. Confirm which Hyper-V-specific services your applications depend on.
Checkpoints	Proxmox VE snapshots (with RAM state for running VMs, where supported)	Needs rework: merge or delete Hyper-V checkpoints before export so the disk chain is clean. Confirm snapshot behavior for your storage type.
Virtual switches and VLANs	Linux bridges (vmbr) with VLAN-aware configuration	Needs rework: rebuild each external and internal switch as a bridge, then reapply VLAN tags and MAC or IP settings. Verify trunk ports on the physical switch.
Failover clustering and live migration	Proxmox VE clusters with multi-master management and live migration between nodes with shared storage	Gap to confirm: Proxmox VE needs at least three nodes for reliable quorum, shared storage and watchdog fencing for HA. Confirm exact parity with the Hyper-V clustering features you use in a pilot.
Cluster Shared Volumes versus Ceph RBD or NFS	Shared storage on Ceph RBD, NFS, iSCSI or CephFS	Needs rework: move VM disks off Cluster Shared Volumes to shared storage Proxmox VE supports. Plan the storage design and network sizing before migrating disks.
Hyper-V Replica versus Proxmox replication and Proxmox Backup Server	Storage replication between nodes and Proxmox Backup Server for backup and restore	Gap to confirm: replication schedules, failover behavior and recovery steps differ from Hyper-V Replica. Test a full failover and restore in a pilot.
Windows Server licensing for guests	Windows guest licenses stay with the guest, independent of the hypervisor	Clean for the licensing model, but confirm with your Microsoft agreement that guest licenses and any host-based rights still apply after the move.

What data, identities and integrations must move with the VMs

A Hyper-V VM is more than its virtual disks. Configuration, checkpoints, backup history, directory dependencies and management tooling each need a decision before cutover. Work through these items for every workload so nothing a guest depends on is left behind on the Hyper-V side.

VM disk data

The VHDX files are the data that must cross over. Copy them from the Hyper-V host while the VM is powered off, then import each disk onto the Proxmox VE target with qm disk import. Hyper-V sources use this disk path because the integrated import wizard added in Proxmox VE 8.2 targets VMware ESXi and vCenter. Confirm the disk format and size on the target storage before you start, since conversion needs free space alongside the source files.

Configuration captured by Export-VM

Export-VM writes the VM definition, including its virtual hardware, network adapter settings and disk references, into a folder alongside the disks. Proxmox does not read that definition, so vCPU count, memory, firmware type, boot order and NIC configuration must be recorded and recreated as a Proxmox VM. Keep the exported configuration files with the change record so the rebuilt VM can be checked against the original.

Checkpoints merged before conversion

Hyper-V checkpoints create differencing disks that reference a parent. Each chain must be merged into a single disk before import, or the target may boot an older state or fail to attach the disk. Remove checkpoints on the source VM, confirm the merge finished, and check that the resulting disk is the one you export. Expect longer import times for any VM that still carries snapshots.

Backup jobs and retention history

Backup jobs in Veeam, Windows Server Backup or another tool point at the Hyper-V VM identity and hold restore points that will not follow the VM automatically. Decide whether to keep the old backup set as read-only history for the retention period your policy requires, and set up the new backup target on Proxmox before the first production cutover. Record which restore points belong to which VM so a restore request can be answered during the transition.

Active Directory and DNS dependencies

Windows and Linux guests often rely on Active Directory, DNS, DHCP and time services that run as other VMs. Moving a guest changes its MAC address and sometimes its IP address, which can break Kerberos, DNS records and service accounts that expect the old values. Map which guests consume these services, confirm reachability from the Proxmox network, and update DNS and service configuration in the same change window.

Management integrations and licensing servers

Monitoring agents, SCVMM or PowerShell automation, and licensing servers for applications such as KMS or software license managers tie to the Hyper-V host or its hardware identity. List each integration, decide whether it is replaced, rebuilt or retired, and test the licensing server against the new virtual hardware before cutover. Ask each software vendor whether a hardware change triggers reactivation or a new license.

The migration sequence: inventory, pilot, parallel run, cutover and decommission

This sequence moves Hyper-V workloads to Proxmox VE in controlled stages, so each wave has a documented baseline, a tested method, a rollback path and a signed record before the Hyper-V hosts are retired.

Build the signed migration register
Record every VM with its disks, checkpoints, Hyper-V generation, guest OS and version, network adapters, dependencies, business owner and technical owner. Checkpoints should be noted now because they must be merged before conversion. Ask the application owners to confirm the dependency list for their systems, since undocumented links between VMs are the most common cause of surprises later. The step is complete when the register is signed by the infrastructure lead, the application owner for each workload and the security or compliance lead, who confirms that data classification and retention requirements are recorded for each system.
Pilot one Windows and one Linux VM
Choose one non-critical Windows VM and one non-critical Linux VM, ideally with different disk layouts and one Generation 2 guest. Export each VM, convert or import its disks with qm disk import, and attach VirtIO drivers to the Windows guest before first boot. Confirm UEFI and boot order settings, network bridge mapping, VLAN tags and guest agent behavior. The output is a documented runbook that lists each driver and network step in order, along with the rollback steps. The platform engineering lead and the owner of each pilot VM sign the runbook before any production VM is touched.
Run both platforms in parallel
Start each migrated VM on Proxmox VE while the original Hyper-V copy stays powered off or read-only, so it can be restarted if a serious fault appears. Test application functions, authentication, backups, monitoring and inbound and outbound connections against the baseline recorded in the register. Keep the Hyper-V copy until the owner confirms the workload is correct. The output is a test report for each VM that states what was tested, what passed, what failed and who accepted the result. The application owner and the security lead sign the test report before the workload is considered ready for cutover.
Cut over in change-controlled waves
Group VMs into waves by dependency and business impact, and schedule each wave in an approved change window. Within each window, shut down the source VM, perform the final disk sync or import, start the Proxmox VE copy and update DNS records, load balancer pools and firewall rules that point to it. Verify each service before closing the window. Retain the rollback path until the wave is accepted. The output is a cutover record for each wave listing the start and end times, the steps performed, the verification results and any deviations. The change manager and the application owner sign the cutover record.
Decommission Hyper-V hosts after verified backups
Retire a Hyper-V host only after every VM it ran has been migrated, verified and covered by a backup on the new platform, and a restore test has succeeded. Remove the host from the register, wipe or destroy storage according to your data handling policy, and remove Windows Server and System Center licensing records that no longer apply. Confirm that any remaining Windows guest licenses are reassigned to the workloads that still run. The output is a closed migration register and updated asset records in the configuration management database. The infrastructure lead and the finance or licensing owner sign the closure, and the security lead confirms media disposal.

How the move differs for standalone hosts, failover clusters and mixed estates

A standalone Hyper-V host has no cluster quorum and no Cluster Shared Volumes to unwind, so the move is mostly a per-VM exercise. Each VM is exported, its disks are prepared, and it is imported into a Proxmox VE node that already has storage and networking defined. The main risk is treating the host as disposable before every VM and its checkpoints have been verified on the target. For a few VMs, a single Proxmox VE node can run the workloads while you validate them, but it has no high availability on its own.

Export and verify first: Export each VM with Export-VM and confirm the disks and configuration files are complete before the old host is touched.
Merge checkpoints before conversion: Remove or merge checkpoints so the disk you import reflects the state you intend to keep.
Plan storage on the target: Define local storage such as ZFS or LVM on the Proxmox VE node with enough free space for the converted disks.
Keep the source host intact: Leave the Hyper-V host powered off but untouched until each restored VM has booted and passed application checks.
Accept the single-node tradeoff: A standalone node does not restart guests on another machine if hardware fails, so plan backups and a restore test.

Confirm the target storage type, the free space available for conversion, and whether the workloads need high availability, which requires at least three cluster nodes and shared storage.

What drives migration cost and duration, and how to reduce each driver

This table lists the main factors that change the effort and cost of moving Hyper-V workloads to Proxmox VE, with the reason each one matters and how to keep it under control. Read the rows as a checklist to size the work before you request a quote, and treat the subscription row as a recurring cost that sits alongside one-time migration work.

Driver	Why it matters	How to keep it down
VM count and disk sizes	Each VM needs export, conversion, import and validation time, and large VHDX files extend copy windows and need free space on both sides.	Inventory every VM with its vCPU, memory and disk sizes, retire unused guests first, and schedule the largest disks in their own windows.
Checkpoint chains	Hyper-V checkpoints create differencing disks that must be merged before import, and deep chains slow conversion and add failure points.	Merge or delete checkpoints on the source before export, and document which checkpoint state is the recovery point you intend to keep.
Windows guests needing VirtIO and driver work	Windows guests lack VirtIO storage and network drivers by default, so boot failures and missing NICs are common until drivers are installed and tested.	Group guests by OS version and Generation, build one tested runbook per group, and test each group on a clone before cutover.
Generation 2 and UEFI settings	Generation 2 VMs use UEFI and Secure Boot settings that must match the Proxmox VE VM configuration, or the guest will not start.	Map each VM's firmware and boot settings in the inventory, then confirm the boot mode on a test import before scheduling production moves.
Clustered workloads and their dependencies	Failover clusters, SQL Server availability groups and file clusters depend on shared storage, quorum and application-level replication that do not map directly to a Proxmox VE cluster.	Document dependencies per service, move the least critical node first, and plan a maintenance window that keeps quorum and application replicas intact.
Network and VLAN complexity	Virtual switch names, VLAN tags, trunk ports and MAC-based licensing or firewall rules must be recreated on Proxmox VE bridges, which adds review and testing time.	Export the Hyper-V switch and VLAN map, recreate bridges with the same tags, and validate reachability for each service before cutover.
Backup and rollback design	A working rollback path, with the source VM kept intact until acceptance, adds storage and time, but a failed cutover without one is costlier.	Keep Hyper-V exports until acceptance, use a backup product that supports Proxmox VE, and test one restore before the first production move. Confirm the backup tool with its vendor.
Skills on the team	Staff who know PowerShell and Hyper-V Manager must learn the Proxmox VE web interface, the qm command set and Linux-side troubleshooting, which lengthens early phases.	Train on a non-production cluster, assign a named owner per runbook step, and consider a fixed-scope implementation partner for the first wave.

What usually goes wrong in a Hyper-V to Proxmox VE move

Most failed Hyper-V to Proxmox VE moves do not fail in the hypervisor. They fail in the guest boot path, the disk state, the network identity, or the order in which dependent servers move. The cards below cover the risks that recur, with the prevention step for each. The Proxmox wiki's ESXi caveats, such as the tested ESXi version range and vSAN limits, do not apply to Hyper-V, so the checks here focus on Hyper-V disk formats, guest drivers and cluster dependencies.

Windows guests fail to boot

A Windows guest built on Hyper-V usually has no VirtIO storage or network drivers, and its firmware mode may not match the Proxmox VM settings. After importing the disk, the guest can stop with a boot or blue screen error. Before cutover, install the VirtIO drivers in a test copy, confirm the firmware (UEFI or BIOS) and machine type match the Generation 2 or Generation 1 source, and check that the boot disk is set as the first boot device. Keep the original VM powered off until a test copy boots cleanly.

Unmerged checkpoints corrupt disks

A VM that still has checkpoints has a chain of differencing disks, and copying only the top-level file gives an incomplete disk. The guest may boot with missing data or fail after the import. Remove or merge every checkpoint on the source VM and confirm the VM's disk is a single base disk before exporting. Record the disk paths and sizes before and after the merge so you can prove the disk you imported is the one you intended.

Network changes break DNS and directory access

Moving a VM to a new bridge, VLAN tag or MAC address can cut off domain controllers, DNS servers and file shares that other systems depend on. Domain-joined servers may also lose their secure channel if their identity or addressing changes unexpectedly. Map each VM's NIC, VLAN and IP address on Hyper-V, and create the matching Linux bridge in Proxmox VE before the import. Confirm that DNS resolution and domain logon work from a test network segment before moving production servers.

Clustered workloads move out of order

Domain controllers, database availability groups and application tiers that depend on each other need a planned sequence. Moving a database node before its witness or the directory it authenticates against can leave the service unavailable during the move. Write the dependency order for each clustered service, move the lowest-dependency systems first, and keep the source cluster in a state that can resume those services. Confirm with the application owner which systems must stay online during each step.

No rollback copy before cutover

A migration that deletes or overwrites the Hyper-V source leaves no way back if the imported VM fails in production. Keep the exported VHDX files, the VM configuration and a recent backup until the VM has run correctly through its agreed acceptance period. Store these copies on separate storage from the Proxmox VE disks so one storage fault cannot remove both. Test a restore from the backup before cutover, not after the first failure.

Production runs on the no-subscription repository

The no-subscription repository is intended for testing and non-production use, while the enterprise repository requires a valid subscription key and is the recommended repository for production. Teams that run migrated VMs on the no-subscription repository may receive package updates with less testing and no enterprise support path. Decide which repository each node uses before go-live, record the subscription level and support tier in the change record, and confirm the update source on every node after installation.

In what order to move clustered workloads without losing availability

Clustered Hyper-V workloads should move in dependency order, not in the order they are easiest to export. Start with directory, DNS and other infrastructure services, because every later workload depends on them for authentication and name resolution. Move non-critical application tiers next, such as test, reporting or internal tools, so the team can practice the disk import, driver and network steps on systems where a mistake costs little. Move the most critical systems last, once the runbook has been proven on earlier waves and the rollback path is known to work. The target has to exist and pass testing before the first clustered guest moves. Proxmox VE high availability needs at least three cluster nodes for reliable quorum, shared storage that guests can reach from every node, redundant hardware, and watchdog-based fencing so that a failed node is reset before its guests are restarted elsewhere. Confirm with your hardware vendor that each node has a working watchdog path, then test a controlled node failure with a non-critical guest. Also confirm how the storage behind the cluster replicates, because a Hyper-V cluster that relied on Storage Spaces Direct will not carry its disk layout over unchanged.

Confirm the Proxmox VE version before you build the cluster. Proxmox VE 9.2 was released on May 21, 2026 on Debian 13 (Trixie), and the release was announced in the Proxmox VE roadmap. Check the support window for the version you plan to deploy against the Proxmox VE FAQ, which ties support to the matching Debian release. Proxmox VE 8.x runs on Debian 12, and that line reaches end of life in August 2026, so a cluster built on 8.x now would need an upgrade inside the migration window. Ask the vendor or your own platform team to confirm this before the cluster design is signed off. After the cluster is stable, move workloads in small waves and keep the Hyper-V source hosts running until each wave has passed a boot test, a network check and a backup restore. Keep at least one application owner on call for each wave, and record the cutover time for every guest so later waves can be sized realistically. Do not decommission a Hyper-V node until its last guest has run on Proxmox VE for an agreed period.

What buyers ask before moving Hyper-V workloads to Proxmox VE

How much does a Hyper-V to Proxmox VE migration cost?

The cost depends on the work involved, not on a single fixed figure, and no public number exists for a generic migration. The main components are the Proxmox VE subscription (if you buy one), the hardware and storage you add or reuse, the time your own staff spend on inventory, testing and cutover, any outside engineering you contract for, and the Windows guest licensing that stays in place. Proxmox VE software can run without a subscription, and its subscriptions are priced per CPU socket per year, so the recurring line item depends on your socket count and the support tier you choose. Ask any quote to separate one-time migration effort from recurring subscription and support costs, and to state which Windows guest licenses are assumed to carry over.

How long does it take to move Hyper-V workloads?

Timing is set by the number and size of VMs, how many are clustered or depend on each other, and how much change window your business allows. Export and disk conversion time grows with disk size, and VMs with checkpoints need merging first, which adds steps per VM. Testing each Windows guest on Proxmox VE, including VirtIO driver installation and boot settings, often takes longer than the copy itself. Clustered workloads usually move in waves, so a schedule depends on how many cutover windows you can secure. Ask for a schedule built from your own inventory, with the wave order, rollback points and the owner who approves each cutover.

Can our in-house team migrate Hyper-V VMs without outside help?

Yes, a team with Linux and Windows administration skills and some KVM or Proxmox experience can do the work, provided the estate is small or the workloads are not business critical. The skills that matter most are disk export and import, Windows boot changes for Generation 2 and UEFI guests, VirtIO driver installation, network re-mapping, and cluster design for high availability, which needs at least three nodes, shared storage and watchdog-based fencing. Teams without these skills in-house often use an implementation partner for a fixed-scope pilot, then run later waves themselves. DeployOpen plans, implements, integrates and documents self-hosted platforms in your own infrastructure under a written scope, which is one option to compare with doing it internally.

What do we need to provide before a migration starts?

Start with a complete inventory of every Hyper-V host, VM, virtual disk, checkpoint, virtual switch and VLAN, plus the business owner and recovery requirement for each workload. You will also need approved change windows, administrative access to the Hyper-V hosts and the Windows guests, and network access between the old and new platforms during the copy. Name a sign-off owner for each application group who can accept test results and approve cutover, and a second owner who can approve rollback. Confirm licensing, DNS, Active Directory dependencies and any applications tied to hardware identifiers before work begins, because these often delay cutover more than the disk copy does.

Do Windows guest licenses change when we move off Hyper-V?

Moving the hypervisor does not by itself change the Windows guest licenses you hold, but the exact rights depend on your agreement and on how each VM is licensed. Windows Server licenses on guests are governed by Microsoft's licensing terms for your specific agreement, including how Software Assurance or subscription rights apply and whether licenses are assigned to hosts or to VMs. Confirm with Microsoft or your licensing reseller in writing before cutover, and check whether any VM is licensed through a host-based model that would stop applying once the host changes. This question should be resolved with your licensing advisor, not with a migration vendor.

Is Proxmox VE free to run in production?

Proxmox VE is free and open-source software licensed under the GNU Affero General Public License, version 3, and it can be used without a subscription. The difference with a subscription is access to the enterprise repository, which requires a valid subscription key and is the recommended repository for production, plus support entitlements that vary by tier. The freely accessible no-subscription repository is intended for testing and non-production use. Subscriptions are priced per CPU socket per year, and every tier includes the same software features. Decide with your change control and support requirements in mind, and confirm the current tier terms on the Proxmox VE pricing page.

What happens to backups and checkpoints during the move?

Checkpoints are not carried over as Hyper-V checkpoints, so each VM needs its checkpoint chain merged or flattened before conversion, and the result should be the state you intend to run. Keep the existing Hyper-V backups intact and verified until the migrated VM has passed its acceptance tests, because they remain your rollback path. On the Proxmox side, plan a backup target such as Proxmox Backup Server and run a test restore of at least one VM from each application group before retiring the old backup jobs. Confirm with your backup product's documentation how it handles the migrated VMs, since backup agents and VM identifiers often change during the move.

How DeployOpen scopes, runs and supports a Hyper-V to Proxmox VE migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, including the Proxmox VE environment that replaces Hyper-V. For a Hyper-V migration, we start from a written inventory of your VMs, disks and clusters, then move workloads in an order that keeps each service recoverable.

How we scope

We inventory Hyper-V hosts, clusters, VM generations, VHDX disks, checkpoints and attached network configuration before any move.
The written scope names which VMs move, which stay on Hyper-V, and which Windows and Linux guests need driver or boot changes.
Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we build

We stand up the target Proxmox VE cluster, storage and network bridges in your environment, then configure access and backup targets.
We run test imports of representative VMs, covering Generation 2 UEFI settings, VirtIO driver installation and boot verification.
We test each migrated workload for boot, network reachability, application function and rollback before cutover.

How we hand over

You receive documentation of the cluster design, VM mapping, network and storage configuration, and the cutover record for each workload.
The handover includes a runbook for remaining Hyper-V workloads, decommissioning steps and the rollback path used during cutover.
We walk your operations team through daily administration, backup restore tests and the Proxmox VE upgrade process.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after handover.
Retainer scope covers Proxmox VE version upgrades, backup verification and changes to the cluster as workloads are added.
Before engaging, confirm with us which Proxmox VE subscription tier your organization will hold, since support entitlements differ by tier.

Migrate from Hyper-V to Proxmox VE