How to export virtual machines from Hyper-V

What can you export from Hyper-V, and what stays behind?

A team facing a renewal, a licensing change or a data residency requirement needs its virtual machines out of Hyper-V, and the first question is what can actually leave the host. VM disks and exported configuration can be taken out through Hyper-V's own export path, but host settings, Windows Server licensing and some runtime state do not carry over. Expect the disks to travel as virtual hard disk files, while the VM definition, networking and host-level policy must be rebuilt on the target platform.

The exact export contents and limits depend on the Windows Server version and the VM configuration version in use, so confirm them against Microsoft's current Hyper-V documentation for your version before planning any cutover. Pay particular attention to how configuration versions, checkpoints and Generation 2 firmware settings are handled, because these determine which target platforms can import a given VM without rework. Inventory each VM's disks, checkpoints, attached ISOs and integration services in a spreadsheet, and record which items the export covers and which must be recreated by hand.

If the scope is large, regulated or time-bound, DeployOpen can define the export as part of a written, fixed-scope engagement, with the VM inventory, export method, validation steps and rollback path agreed in writing before work starts. Ask any provider to state in writing which items are exported, which are rebuilt, and who verifies each VM boots and passes its checks on the target host.

Which Hyper-V data can be exported and in what form

This table lists each part of a Hyper-V virtual machine, the documented way to export it, the file format it lands in and the limits that decide where it can go next. Read it before the export starts, because the configuration version and checkpoint state often decide whether an import succeeds without rework.

Data item	Export method and format	Limits and what to confirm
Virtual hard disks (VHD and VHDX)	Copied as part of the export folder produced by Hyper-V Manager or Export-VM, keeping the original VHD or VHDX format	Confirm in Microsoft's documentation for your Windows Server version which disk formats and sizes the export keeps. Plan the later conversion to a format Proxmox VE or XCP-ng imports directly.
VM configuration files	Exported as XML configuration files in the export folder, with the VM's hardware and settings recorded	Confirm which configuration version your hosts write and whether the target hypervisor accepts it. Older configuration versions can restrict which hosts can import the VM.
Checkpoints	Exported with the VM when checkpoints exist, stored as differencing disks and checkpoint files alongside the base disk	Merge or remove checkpoints before conversion so the importer reads one consistent disk chain. Confirm in Microsoft's documentation how checkpoint files are handled for your version.
Guest data inside the disks	Stored inside the VHD or VHDX files and moved as a block copy of the virtual disk	Export does not change guest file systems. Confirm the disk partition style and file system are readable by the target platform, and check that the guest is shut down or consistent at export time.
Generation 1 VM settings	Recorded in the configuration files, with BIOS-style firmware and IDE controllers for the boot disk	Confirm how the target platform maps BIOS firmware and IDE controllers. Plan driver changes for the guest, since storage and network devices differ after import.
Generation 2 VM settings	Recorded in the configuration files, including UEFI firmware, Secure Boot and SCSI-based virtual disks	Confirm whether the target platform keeps UEFI, Secure Boot and the virtual TPM settings after import. Check the EFI system partition layout before choosing the boot mode on the new host.

What does not export from Hyper-V and how to handle each gap

A Hyper-V export moves virtual disks and a configuration file, but several things stay behind on the source host or depend on the platform you import into. Each card below names one gap, what it affects on the target, and the check to run before you cut over.

Host and cluster settings

Export-VM copies a VM's configuration and disks, not the host itself. Failover cluster roles, host-level settings such as NUMA and live migration options, and cluster resource ownership do not follow the VM. On Proxmox VE, you rebuild the cluster, storage definitions and node settings in the target environment, then assign imported VMs to nodes. Record every clustered role and its preferred owner on the Hyper-V side before exporting, so the target placement matches your intent rather than the old host layout.

Virtual switches and network definitions

Hyper-V virtual switches, VLAN tags, MAC address pools and adapter names are host constructs. An exported VM keeps its virtual adapter settings in its configuration, but the bridge or switch it expects does not exist on the target. Before import, document each switch and the VLANs it carries, then create equivalent bridges on Proxmox VE or networks on XCP-ng. After import, confirm each VM's NIC is attached to the correct bridge and that IP addressing, DNS and firewall rules still match. Treat a mismatch here as the most common cause of a VM that boots but cannot reach its services.

Windows activation and licensing

Windows activation is tied to the hardware and virtualization environment the guest sees, so a Windows VM that was activated under Hyper-V may report as unlicensed after it moves. Activation does not transfer as a side effect of export. Confirm which Windows and SQL Server entitlements the organization holds, whether they are covered by Software Assurance or by a Windows Server host license, and how the target hypervisor is licensed. Re-activate each guest under the customer's own entitlement, and keep proof of license for audit.

Integration services and guest tools

Hyper-V integration services supply the synthetic drivers for storage, network, time sync and heartbeat. Once a VM runs on KVM or Xen, those drivers are absent or replaced, so Windows may fail to boot or show a disk or NIC it cannot use. Plan to install VirtIO drivers on Proxmox VE or the Xen PV and guest tools on XCP-ng before the first boot on the new host, and remove the Hyper-V integration components afterward. Test boot, disk I/O, networking and clean shutdown on a copy of each VM first.

Running memory state and checkpoints

An export captures a VM's saved state only if the VM is off, and it does not carry live RAM contents from a running or paused guest to another hypervisor. Checkpoints are exported as disk chains that must be merged before conversion, and any in-flight application transactions are not preserved. Shut each VM down cleanly, confirm no checkpoints remain as needed, and plan a cutover window for databases and stateful services. Live migration between hypervisors is a separate process that depends on the tooling you choose, so confirm it with the vendor before you rely on it.

Host-side backup and replication policies

Backup jobs, replication schedules and retention rules configured in Hyper-V Replica, Windows Server Backup or a third-party agent live on the host or in the backup product, not in the VM's configuration file. They do not transfer with the export. Inventory every policy that protects a VM, record its schedule and retention, and recreate equivalent jobs on the target platform, such as Proxmox Backup Server or Xen Orchestra backup, before the VM goes live. Run one restore test from the new backups before you decommission the Hyper-V copy.

How the export path changes for standalone hosts and failover clusters

On a standalone Hyper-V host, one machine controls the whole export. No cluster resource group holds the VM, so the work centers on the guest's state, its checkpoint chain and the free space on the export volume.

Stop or quiesce the guest: Shut down the VM for the cleanest copy. If you export a running VM, flush database and application state with the product's own tools first, so the exported disks match a consistent point in time.
Review checkpoints before export: Exports carry the checkpoint chain with the disks. Identify the AVHDX files that belong to the VM, and merge them before conversion so the disk you convert is the one you intend to move.
Record the configuration version: Run Get-VM and read the Version property for each guest. The target platform's import path may not accept every configuration version, so note the value now.
Size the export volume: Export writes full copies of every disk, and conversion needs more space on top of that. Measure the actual VHDX sizes on the host and plan the destination from those figures.

Before you copy anything off the host, confirm the VM is off or at a known checkpoint and that the export folder contains the VHDX files and configuration files you expect.

A mixed estate has two groups of guests with different post-import work. The export discipline is the same for both, but Windows guests need more changes to drivers and integration tools, and Linux guests need careful handling of disk identifiers. Sorting the inventory first keeps each group on its own preparation path.

Group guests by OS and generation: Record the guest OS, whether each VM is Generation 1 or Generation 2, and the disk controller type. Generation determines the firmware and boot settings the target VM needs.
Use the application's own flush tools: For database servers and other stateful services in both groups, run the product's backup or flush procedure before export, so the copied data is consistent.
Check how Linux guests mount disks: Confirm that /etc/fstab references disks by UUID or label. Device names can change after conversion, and a guest that depends on them may fail to boot.
List Hyper-V integration components: Identify the Hyper-V integration services and tools installed in each Windows guest. Plan their removal and the installation of the target platform's guest tools as separate steps.
Run exports in small batches: Move one Windows and one Linux guest first, then expand the batch once both boot and reach the network.

Boot one guest from each group on the target platform and check network, storage and logins before you move the rest of the estate.

Why merge checkpoints before converting a Hyper-V disk

Checkpoints in Hyper-V do not copy a disk. They create differencing disks, so each checkpoint adds a child file that stores only the blocks changed since its parent. A VM with several checkpoints therefore has a chain of VHDX files, and the running guest reads across that whole chain. Most target platforms expect one consolidated disk per VM disk. Proxmox VE's import tooling and the disk conversion steps for XCP-ng both work on a single flattened image, so the chain has to be resolved somewhere before the disk reaches the new host. A broken or missing link in the chain makes the disk unreadable or silently wrong, which is the main data loss risk in this step.

You have two places to resolve the chain. Merging in Hyper-V before export means removing checkpoints on the source host, which folds their changes into the base disk while the VM is still in Hyper-V. The source then exports one clean disk, and you can verify the result before the VM leaves the old host. Consolidating after export means copying the full chain to the target or a staging host and flattening it there with conversion tools. This keeps the source untouched, but it moves more data, depends on each file in the chain being copied intact, and makes it easier to pick the wrong parent when names are similar. Either route needs free space: a merge writes new data while the old files still exist, so the volume holding the VM must have headroom beyond the size of the disks. Confirm the merge behavior, the temporary space required and how checkpoint removal affects running VMs in Microsoft's Hyper-V documentation for your Windows Server version before you schedule any change.

Take a full backup of every VM in the chain before you merge or remove any checkpoint, and confirm that the backup restores. Then run the full procedure on a copy of one non-critical VM, including the export, the conversion and a boot test on the target platform. Record the checkpoint count, the disk sizes before and after, and any error messages, because these are the signals you will compare when the production VMs follow the same path. Do not start on a production VM until the test copy boots cleanly and its data checks match the source.

What is the sequence for a complete Hyper-V VM export?

The sequence turns each Hyper-V virtual machine into a verified set of configuration and disk files that a Proxmox VE or XCP-ng migration can use. Each step leaves a record you can check before you move on.

Inventory VMs and their checkpoints
Build a list of every VM slated for export, with its name, Generation, state, virtual disks, attached checkpoints and any dependencies such as clustered roles or pass-through hardware. Run Get-VM and Get-VMSnapshot on each host, or record the same details in Hyper-V Manager, and store the output with the migration ticket. The step is done when every VM has a row in the inventory and every checkpoint is accounted for, so nothing is discovered for the first time during cutover.
Confirm Generation and configuration version
Record each VM's Generation (1 or 2), its firmware type, and its configuration version as reported by Get-VM. The configuration version determines which Hyper-V hosts can import the export, so note it before you export anything. Confirm the target platform's import path for that Generation, because Generation 2 VMs use UEFI and Secure Boot settings that you must map on the target. The step is done when each VM has a documented Generation and configuration version and the target import path is confirmed in your own environment.
Take a full backup before exporting
Create a full backup of each VM with your existing backup product, and verify that the backup set restores. This gives you a rollback point if an export, merge or conversion step damages a disk chain. Keep the backup on separate storage from the source host where possible. The step is done when a test restore of at least one VM from the backup has booted or its disks have been read successfully, and the backup set is recorded in the inventory.
Stop or quiesce workloads
Shut down each VM cleanly from inside the guest, or follow the application vendor's documentation for quiescing databases and other stateful services so that writes are flushed to disk. Do not export a VM that is running on a live filesystem with in-flight writes unless the vendor documents that the state is consistent. The step is done when each VM reports Off in Hyper-V Manager and the application owners have confirmed the quiesce method for their workloads.
Export each VM with Export-VM
Export each VM to a staging folder using Hyper-V Manager's Export action or the Export-VM cmdlet, for example Export-VM -Name followed by the VM name and -Path to a dedicated staging share. The export writes the configuration files, the virtual hard disk files and the checkpoint data for that VM. Keep one folder per VM so the files stay grouped. The step is done when each export completes without errors and the folder contains the configuration, VHD or VHDX disk files and any checkpoint files that the inventory lists.
Merge or consolidate checkpoints
Decide whether to keep checkpoints as history or merge them into a single base disk. Most conversion paths need a single flat disk per volume, so merge checkpoints into the base disk with the Hyper-V Manager merge option or by using Merge-VHD on the disk chain, working from the backup taken earlier. Record the disk chain before and after the merge. The step is done when each VM shows one base disk per volume, the chain is recorded, and the application owners have approved which checkpoint states, if any, are retained.
Copy files to the target storage
Copy the exported folders to the storage the migration will read from, such as a staging volume or NFS share attached to the target cluster. Keep the original file names, and make sure the staging location has enough free space for the disk conversion you plan, because conversion writes a second copy of the data. Use a copy method that reports errors rather than silently skipping files. The step is done when every file in the export folder is present on the target storage and the copy log shows no failed transfers.
Check file integrity and disk chains
Compare the file sizes on source and target, then compute a checksum such as SHA-256 for each disk file on both sides and compare the values. Confirm that each disk file opens with Get-VHD or the target's disk inspection tool and that its parent and child references are resolved. A mismatch in size, checksum or chain indicates an incomplete copy or a stale checkpoint file, and the file should be recopied before any import. The step is done when every checksum matches and every disk reports a valid, unchained base image.
Run a test boot on an isolated network
Import one copy of each VM onto the target platform, attach it to an isolated network segment with no route to production, and boot it. Confirm that the guest reaches its login prompt, that storage is detected, and that the services the workload needs start. Test Windows guests for driver and hardware-change prompts, and keep the source VM powered off so the two copies do not share identifiers on the same network. The step is done when each VM boots, its disks are visible inside the guest, and the results are recorded in the migration log, with production cutover planned separately.

How exported disks get ready for Proxmox VE or XCP-ng

Once the export is complete, the disks still have to be converted and imported into the target platform, and the Windows guest has to be adjusted to run on different virtual hardware. On the Proxmox VE side, the documented paths include qm disk import for disk files, which is the route for VHDX files exported from Hyper-V, and OVF import with qm importovf as an alternative. The Proxmox wiki page Migrate to Proxmox VE lists these paths alongside Clonezilla, so compare them against the source VM before choosing one. On the XCP-ng side, the XCP-ng migration guide documents imports from Hyper-V, but the exact disk formats and steps should be confirmed in the current documentation for your target version. Confirm the exact disk format each target accepts before you convert anything, because a format the platform does not read will cost a conversion cycle and disk space.

Before import, record the guest's boot mode, disk controller, network adapter and any Hyper-V integration services it depends on. Windows guests that were built for Hyper-V often rely on Hyper-V integration components and synthetic devices, so the storage and network drivers the guest expects will change after the move. Plan to remove Hyper-V tools where they are present and to install the target's guest drivers and agents afterward, including the paravirtualized storage and network drivers that the target recommends. Keep a rollback copy of each exported disk, and test boot on an isolated network before connecting the VM to production VLANs.

After the first boot, verify the disk layout, boot order, network configuration and the guest's device manager for devices without drivers. Check that the VM's firmware setting matches the one used on Hyper-V, since a mismatch is a common reason a converted Windows guest fails to start. For a detailed VHDX conversion walkthrough, including checkpoint merging and file naming rules, follow the related migration pages for Proxmox VE and XCP-ng. Those pages cover the step-by-step commands, so this section only sets out what to verify and what to plan for.

What to plan before the Hyper-V contract or licensing ends

Exporting VMs is the easy part of leaving Hyper-V. The cards below cover the decisions that come before the first export: what you run, which Windows and System Center rights still apply during the overlap, how long both platforms run side by side, how exports stay restorable, and what support model the target platform needs.

Inventory VMs and dependencies

List every VM with its generation, disk files, checkpoint chains, virtual switches, VLANs, attached ISOs and any guest-level dependencies such as licensed databases or license servers. Note which VMs sit in a failover cluster, since clustered workloads move in a fixed order. Confirm the configuration version of each VM, because it determines which hosts can import it later. Illustrative example: a file server with three checkpoints and a SQL Server guest needs a different export sequence from a stateless web VM.

Keep Windows Server rights valid

Hyper-V host licenses and the Windows Server guest licenses you still run during the overlap must stay valid until the last VM leaves the Hyper-V host. Ask your licensing advisor how Windows Server and System Center entitlements apply while VMs run on both platforms, and whether any guest license is tied to the host. Record the license keys, software assurance or subscription dates and renewal owners in the same inventory so nothing lapses mid-migration.

Plan a parallel-run period

Run the migrated VMs on the target platform alongside their Hyper-V originals for a defined period before retiring the source. Use this window to test boot, network reachability, storage performance, backups and application-level checks. Keep the Hyper-V copy powered off but intact until the business owner signs off. Agree the length of this period in your written scope, since it depends on your change calendar and the workloads involved.

Retain Hyper-V exports

Keep each Hyper-V export package, including the VHDX or VHD files, configuration files and a manifest of checkpoints merged, in storage you control until the restore test passes on the new platform. Record which Hyper-V and Windows Server build produced each export, and test that a copy can still be read after the source host is decommissioned. Set a retention period with your records owner, and store one copy off the migration network.

Choose a Proxmox VE subscription

Proxmox VE is open-source software under the GNU AGPL v3, and all features are available in every subscription tier. Tiers are priced per occupied CPU socket per year, and they differ in support tickets, response times and enterprise repository access. Decide whether production hosts need the enterprise repository and a response time, then request a quote from your written scope, since the price depends on your socket count and tier.

Choose a Vates support plan

XCP-ng and Xen Orchestra are open-source software, and Vates describes commercial support subscriptions as the layer that adds service level agreements. Decide whether your team can carry first-line support in-house or needs a contracted SLA for hosts, V2V migration and backups. Ask Vates or your implementation partner to confirm which support plan covers Xen Orchestra, the hypervisor and any add-ons you plan to use, and request a written quote for your environment.

What do teams ask before exporting Hyper-V VMs themselves?

Can our own staff export Hyper-V virtual machines without an outside partner?

Yes, many teams do the export in-house, because the core steps use tools already on a Windows Server host, such as Export-VM in PowerShell, and the target platform's own import tools. The work is manageable for a small number of VMs with clear owners. It gets harder when VMs are clustered, depend on each other, or must be moved inside a fixed change window. Ask your team to confirm, from its own inventory, which VMs are simple single-host guests and which need a documented runbook and rollback plan before anyone starts.

What drives how long a Hyper-V export and import takes?

Duration depends on four things: total disk size, how many checkpoints each VM carries, network throughput between the hosts or to a file share, and how many VMs move in one wave. Checkpoints add merge work before conversion, and the research on Proxmox VE notes that VMs with snapshots import more slowly. No duration figure is given here because it varies by environment. Measure one representative VM in your own network, then multiply by the inventory, and confirm the result with a test cutover.

What cost components should we expect when moving VMs off Hyper-V?

The cost has several parts, and most of them are labor or time rather than licenses:

Staff time for inventory, export, conversion, driver work and testing
Target platform subscriptions, if you choose one. Proxmox VE subscriptions are priced per CPU socket per year, and Vates lists XCP-ng support plans separately
Storage for exported disks and temporary copies during conversion
Test environments and validation effort
Any outside services you buy, quoted from a written scope

One-time work covers migration, while subscriptions, support and backup storage recur. Ask each vendor for the exact figures in writing.

What do we need to provide before an export starts?

Teams typically need administrative access to the Hyper-V hosts and the VM storage paths, an inventory of VMs with their owners, and agreed change windows for each application. You also need a named owner for Windows licensing, because the license terms that apply to Windows guests depend on your agreements, not on the hypervisor alone. Confirm with your Microsoft licensing contact which guest licenses stay with each VM after it moves, and record the decision before the first export.

How should we verify that a migrated VM booted correctly?

Check boot, device and service behavior in a test copy before cutover. Confirm that the VM reaches the login or service stage, that disks and network interfaces appear, and that the application answers its health checks. For Windows guests, confirm that the guest drivers and any Hyper-V integration components are removed or replaced, and that the license activation state is what your records expect. Keep the original Hyper-V VM and its exported files until the target copy has passed a defined acceptance test.

What happens to Windows licensing after we move a VM off Hyper-V?

The host and guest licenses are separate questions. Moving a Windows guest off Hyper-V does not by itself end the guest's Windows license, but it can change which host licenses you still need, and it can change how activation works on new hardware. Ask your licensing advisor to review the Windows Server edition, the number of physical cores on each host, and any Client Access Licenses before you decide what to retire. Treat that review as a prerequisite, not a formality.

Can we export an entire Hyper-V estate in one batch?

Usually not safely. Moving everything at once concentrates risk, and dependencies between VMs, such as databases, domain controllers and application tiers, need an order. Group VMs by owner and dependency, start with low-risk test workloads, and move clustered workloads only after the target platform's cluster and storage design is proven. Confirm the sequence with the application owners, and avoid the first wave for production systems that cannot tolerate a rollback.

How DeployOpen scopes and delivers a Hyper-V export

DeployOpen treats a Hyper-V export as a scoped piece of work inside your own environment, starting with an inventory of VMs, disks, checkpoints and configuration versions. We plan the export path, prepare the disks for Proxmox VE or XCP-ng, and document each step so your team can repeat it.

How we scope

Inventory every VM, its configuration version, disk format and checkpoint chain before any export starts.
Record which hosts, storage paths and networks the export touches, and which VMs need a maintenance window.
Agree the written scope, deliverables and timeline with you in advance, since engagements are fixed-scope.

How we build

Merge or consolidate checkpoints on a copy of each disk so the converted image reflects the intended state.
Convert and test disks on a non-production target, checking boot, drivers, network and storage paths.
Confirm free space for conversion and copy operations on the source and target hosts before the first export.

How we hand over

Deliver a runbook listing each export, conversion and import step, with the commands and settings used.
Provide a per-VM checklist covering guest driver changes, firmware mode and post-import verification results.
Walk your operations team through rollback points so each VM can return to its source if a cutover fails.

How we support

Offer ongoing support and upgrades as a retainer after handover, covering Proxmox VE or XCP-ng updates.
Re-test migrated VMs when platform versions change, so your runbook stays accurate for later waves.
Confirm with you which vendor support tier, such as Proxmox VE or Vates, your environment will carry.