Choosing a Live Migration Strategy for Hyper-V VMs on Windows Server 2022

When you need to move a running Hyper-V virtual machine to another host — for patching, hardware maintenance, or load balancing — the decision that matters is not whether to live migrate but which path: shared storage, SMB 3.0, or a generation-compatible destination. Picking the wrong combination either blocks the migration outright or stretches it long enough to trigger application timeouts. This guide compares the supported options on Windows Server 2022 (and Windows 11 Pro as a source/destination for dev workloads) and shows how to validate the result.

The decision and its constraints

Live migration moves a running VM's memory and execution state to another host without shutting it down. The hard constraints are:

• Storage must be reachable from both hosts — either shared storage (FC/iSCSI SAN, Storage Spaces Direct) or SMB 3.0 file shares. A VM whose VHDX sits on local-only disks cannot be live migrated as-is; you must combine it with a storage migration or move the files first.
• VM generation must match host support. Generation 2 VMs (UEFI, Secure Boot) migrate cleanly between hosts that both support Gen 2, but a Gen 2 VM can never run on a host configured only for Gen 1 expectations, and mixing generations across very old hosts causes startup failures.
• The destination virtual switch must exist with the same name (or you accept re-binding), and the subnet must be consistent or the VM loses connectivity after the move.
• Bandwidth and latency set the timeline. Over low-latency LAN links with SMB 3.0 and modern NICs, impact is minimal. Over WAN links, memory-page iterations can fail to converge and the migration times out.

Comparing the supported options

For most maintenance scenarios on a cluster or two-host setup with an SMB share, live migration over SMB 3.0 is the pragmatic default. Reserve combined moves for genuine re-homing where no shared storage exists, and run them over the LAN only.

Generation and network compatibility checks

Before migrating, confirm the VM generation and that the destination exposes an equivalent virtual switch. Run these in an elevated PowerShell session on the source host:

Get-VM -Name "AppServer01" | Select-Object Name, Generation, State
Get-VMSwitch -ComputerName DESTHOST01

Compare the switch names. If the destination switch has a different name, the VM will arrive disconnected unless you handle the re-bind. Also confirm Secure Boot and vCPU/RAM limits are supported on the destination — a Gen 2 VM with more memory than the destination allows for its generation will fail to start after the move.

Performing and validating the migration

Initiate the migration from an elevated PowerShell session (local admin on both hosts, and constrained delegation or CredSSP configured if you are not using a cluster):

Move-VM -Name "AppServer01" -DestinationHost DESTHOST01 -IncludeStorage -DestinationStoragePath "D:\VMs\AppServer01"

Omit -IncludeStorage when the VHDX is already on shared storage or an SMB share — that is the fast path. -IncludeStorage forces the combined move and copies the disks over the migration network.

Validate during and after:

Get-VMLiveMigration -VMName "AppServer01"
Get-VM -Name "AppServer01" -ComputerName DESTHOST01 | Select-Object Name, State, Status

Expected result: the migration progress reaches completion, the VM shows Running on the destination with a healthy status, and the source host no longer lists it. Then verify from inside the VM (or via a monitoring probe) that the application responds and the IP configuration survived the switch binding. Check Event Viewer under Microsoft-Windows-Hyper-V-VMMS and Hyper-V-Worker on both hosts for warnings — a migration that "succeeded" but logged network re-bind errors often means the VM is up but unreachable.

Limitations and when not to do it

• Local-storage-only VMs cannot use plain live migration; you must include storage or relocate files first.
• WAN or high-latency links are a poor fit: memory dirtying can outpace the copy loop, causing timeouts. Test with a non-critical VM first if the link is questionable.
• Migration changes where the VM runs, not its configuration — no rollback step is needed beyond migrating it back, which is itself a live migration.
• Windows 11 Pro supports Hyper-V live migration as a participant, but it is not a supported target for production clustered workloads; treat it as a dev/test path.

The practical rule: match generations, keep VHDX on SMB 3.0 or shared storage, keep migration traffic on a fast LAN, and always confirm post-migration reachability from the guest's perspective — not just from Hyper-V Manager.