Export and Import are how you move a Hyper-V VM from one host to another, clone a VM for testing, or keep a portable copy you can rebuild from. Unlike copying a VHDX by hand, an export captures the whole machine — disks, configuration, checkpoints, and saved state — in a structure that Hyper-V can reconstruct on the other end.
The catch most people hit is on import, not export. Hyper-V offers three import types, and picking the wrong one either fails with an ID conflict or quietly reuses files you meant to keep separate. Get the export right, then choose the import type that matches what you’re actually doing — moving, restoring, or cloning.
This guide covers both the Hyper-V Manager clicks and the PowerShell cmdlets, plus the rules that decide whether an import succeeds.
What an export actually contains
When you export a VM, Hyper-V writes a folder named after the machine, with three subfolders inside:
Structure of an exported VM
| Virtual Machines | The VM configuration (.vmcx), saved state, and the VM's GUID |
|---|---|
| Virtual Hard Disks | Every attached VHD/VHDX, copied in full |
| Snapshots | Any checkpoints (.avhdx differencing disks and their config) |
That full-disk copy is the part that surprises people. If the VM has a 60 GB dynamically expanding disk that’s grown to 45 GB of data, the export writes 45 GB. Point your export at a drive with room to spare.
Export a VM with Hyper-V Manager
The GUI path is short:
- Open Hyper-V Manager and select the VM in the list.
- In the Actions pane (or right-click the VM), choose Export.
- Browse to the destination folder and click Export.
Hyper-V exports in the background — you can watch the Status column show a percentage. The VM keeps running the whole time if it was running.
Export a VM with PowerShell
For a single VM, one line does it:
Export-VM -Name "Lab-VM01" -Path "D:\Exports"That creates D:\Exports\Lab-VM01\ with the three subfolders. To export every VM on the host in one go:
Get-VM | Export-VM -Path "D:\Exports"Each VM lands in its own named subfolder under D:\Exports. This is a tidy way to stage a batch of VMs before moving a host or rebuilding it.
Understand the three import types
This is where imports go right or wrong. When you import, Hyper-V asks how to handle the files and the VM’s identity. There are three choices:
Hyper-V import types
| Register in place | Uses the files where they sit now. Keeps the original VM ID. Good when the files are already on their final storage. |
|---|---|
| Restore the virtual machine | Copies files to the host's configured default paths. Keeps the original VM ID. Good for moving a VM back to standard storage. |
| Copy the virtual machine | Copies the files and generates a NEW VM ID. Use this to clone, or when the source VM still exists. |
The deciding question is simple: does a VM with this same ID already exist anywhere you care about? If you’re cloning a VM, or the original is still registered on another host you’ll keep using, choose Copy the virtual machine so the new one gets a fresh GUID. Two VMs sharing an ID is what triggers most import failures.
Import a VM with Hyper-V Manager
- In Hyper-V Manager, choose Action → Import Virtual Machine.
- Browse to the exported VM’s folder (the one named after the VM) and click Next.
- Hyper-V validates the export and shows the VM. Click Next.
- Pick one of the three import types from the list above.
- If you chose Restore or Copy, set the destination folders for the configuration, checkpoints, and disks.
- Choose the virtual switch to connect the VM’s network adapter to, then Finish.
Step 6 matters when moving between hosts: the switch named in the export probably doesn’t exist on the new host, so Hyper-V prompts you to map the adapter to a local switch. If you skip it, the VM imports with a disconnected NIC.
Import a VM with PowerShell
PowerShell import needs the path to the VM’s configuration file (.vmcx), which lives in the Virtual Machines subfolder. To register a VM in place, keeping its files and ID where they are:
Import-VM -Path "D:\Exports\Lab-VM01\Virtual Machines\<GUID>.vmcx"To clone the VM onto this host with a brand-new ID and copied files:
Import-VM -Path "D:\Exports\Lab-VM01\Virtual Machines\<GUID>.vmcx" -Copy -GenerateNewId -VhdDestinationPath "D:\VMs\Cloned\Disks" -VirtualMachinePath "D:\VMs\Cloned"The -Copy -GenerateNewId combination is the PowerShell equivalent of “Copy the virtual machine” in the GUI — it’s what keeps you out of duplicate-ID trouble when the source VM is still around.
Moving a VM between hosts, end to end
Here’s the full sequence when the goal is to relocate a VM from Host A to Host B:
Host-to-host move
- Shut down the VM on Host A for a consistent export (or accept live export)
- Export-VM to a shared folder or external drive with enough free space
- Copy the export folder to Host B if it isn't on shared storage
- On Host B, Import-VM and choose Restore (moving) or Copy (cloning)
- Map the network adapter to a switch that exists on Host B
- Start the VM and confirm networking, then delete the export once verified
A couple of version notes worth knowing. Importing a VM exported from an older Windows build usually works, and Hyper-V offers to upgrade its configuration version with Update-VMVersion. Going the other way doesn’t: a VM exported from a newer host won’t import on an older one if its configuration version is higher than the old host supports. Check the configuration version with Get-VM | Select-Object Name, Version before assuming a move will work both directions.
If the imported VM won’t get on the network afterward, the adapter is probably mapped to the wrong switch or no switch at all — the same class of problem covered in why a Hyper-V VM has no internet. And if export grinds to a halt over checkpoints, merging AVHDX checkpoint files first will clean things up.
Wrapping up
Export is the easy half — pick the VM, point Export-VM at a drive with space, and let it copy the disks, config, and checkpoints. Import is where the thinking happens. Register in place when the files are already home, Restore when you’re moving back to standard storage, and Copy with a new ID whenever the original still exists, so you never trip the duplicate-GUID error.
Keep the network-switch mapping in mind on host-to-host moves, watch the configuration version when going between Windows builds, and shut transactional VMs down for a clean export. Do that and moving Hyper-V VMs becomes routine. For more Hyper-V walkthroughs, browse the virtualization guides.
