# Moving VMs from a Windows Server 2016 Hyper-V Cluster to a New 2025 Cluster: Shared-Nothing Live Migration, Kerberos Delegation, VM Versions and a Bandwidth-Based Calendar

> Move VMs from a Windows Server 2016 Hyper-V cluster to a new 2025 cluster: shared-nothing live migration, Kerberos delegation, VM versions and a calendar.

Canonical: https://o365hq.com/blog/moving-vms-from-a-windows-server-2016-hyper-v-cluster-to-a-new-2025-cluster-shared-nothing-live-migration
Provider: IT Partner LLC — US Microsoft partner since 2006. Book: https://o365hq.com/book

Published: 2026-10-18 · IT Partner

Build the Windows Server 2025 cluster beside the 2016 one and move the VMs across one at a time with shared-nothing live migration, each running while its disks copy; a VM that cannot go live takes a short export and import. Kerberos constrained delegation comes first, because CredSSP live migration stops working on Windows Server 2025; the one-way version upgrade comes last. Windows Server 2016 leaves extended support on 12 January 2027.

## The method in one paragraph, and the three gates

The [companion decision article](/blog/hyper-v-hosts-as-old-as-the-guests-upgrade-the-cluster-to-windows-server-2025-or-leave-on-premises) explains why a new cluster beside the old one beats three rolling hops from 2016; this is that runbook.

Build the Windows Server 2025 cluster on its own storage, in the same Active Directory domain as the 2016 hosts, and validate it. Move VMs one at a time with shared-nothing live migration, which copies a running VM's memory and virtual hard disks from a 2016 host to a 2025 host with no shared storage between them; a VM that cannot move live takes a short export and import. Every VM keeps configuration version 8.0 until the last one is off the old cluster, so each can still be copied back; then versions go to 12.0 in planned windows and the old cluster is retired.

| Gate | What must be true | How you prove it |
|---|---|---|
| Constrained delegation | Every host's computer object trusts every other host for cifs and Microsoft Virtual System Migration Service; all hosts use Kerberos | A disposable VM moves old-to-new cleanly |
| Network and storage paths | A migration VLAN both clusters reach, a destination Cluster Shared Volume path per VM, the same virtual switch name on both sides | The pilot lands where the per-VM list says |
| VM versions | Every VM at 8.0 or later; Windows Server 2025 runs 8.0 through 12.0, so a VM at 5.0 is raised on the old cluster first | `Get-VM` on each old host, Version column |

## Prerequisites on both sides: Kerberos instead of CredSSP, the network, processor compatibility

Supported versions. Microsoft's live-migration page (14 August 2025) lists hosts on Windows Server 2012 R2 and later in the same domain or trusting domains; its troubleshooting guide (12 February 2026) adds that migration works one way, not in reverse, once a VM has moved to a newer operating system. No Microsoft page names the 2016-to-2025 pair as such at the time of writing, hence the pilot VM.

Kerberos, not CredSSP. Windows Server 2025 enables Credential Guard by default on domain-joined servers that are not domain controllers, and Microsoft states that CredSSP-based live migration cannot be used with Hyper-V after upgrading to Windows Server 2025. On every host's computer object, the Delegation tab is set to "Trust this computer for delegation to the specified services only" and "Use any authentication protocol", and the cifs and Microsoft Virtual System Migration Service entries of every other host are added. Then every host switches to Kerberos (`Set-VMHost -VirtualMachineMigrationAuthenticationType Kerberos`). The change takes effect after it replicates to the hosts' domain controllers and a new Kerberos ticket is issued, so a delegation set at 17:00 can still fail at 17:05.

Network and processors. Live-migration traffic is not encrypted, so it gets a trusted VLAN both clusters reach, with the performance option (Compression by default, SMB where both sides have RDMA) set the same on every host. A VM crossing processor generations of the same manufacturer needs processor compatibility mode on, set while it is off (`Set-VMProcessor -CompatibilityForMigrationEnabled $true`), so it goes on in a planned stop before the move.

## The move itself: a ten-step runbook

1. Pick the pilot, a VM nobody misses for an hour. Record its version, generation, virtual switch, VLAN and static MAC addresses; a pass-through disk, a shared disk or a virtual TPM disqualifies it from a live move.
2. Merge or delete checkpoints on the old host, so each volume is one virtual hard disk, and confirm the integration services are current.
3. Switch processor compatibility on in a planned stop when the processor generations differ.
4. Confirm with its vendor that the backup product supports Windows Server 2025 hosts.
5. Remove the VM from its cluster role on the 2016 cluster without stopping it, so the host owns it for the move.
6. From the old host: `Move-VM <name> -DestinationHost <new node> -IncludeStorage -DestinationStoragePath C:\ClusterStorage\<volume>\<name>`. The disks copy while the VM runs; the memory state hands over at the end.
7. Add it to the new cluster as a virtual machine role so it is highly available again.
8. Validate: it runs on the intended node, answers on its address, the application owner confirms the service, the event log is clean.
9. Follow up: the DNS record, the backup job re-pointed to the new cluster with a first run observed, the monitoring agent, the documentation, the old cluster's inventory.
10. Wait a day, then the next VM, smallest and least critical first; versions stay at 8.0 until the last VM has moved.

## VM configuration versions: what each unlocks and why 12.0 comes last

Microsoft's version page (30 June 2025) sets the rules: a configuration version cannot be downgraded, the VM must be shut down to upgrade it, and a VM at a newer version does not start on a host that does not support it. Windows Server 2025 runs 8.0 through 12.0; Windows Server 2016 runs 5.0 through 8.0.

| Version | Introduced with | What it unlocks, from Microsoft's feature table |
|---|---|---|
| 8.0 | Windows Server 2016 | Nested virtualization, guest Virtualization-Based Security, key storage drive, large-memory VMs |
| 9.0 | Windows Server 2019 | Hibernation, more processor features in Perfmon |
| 10.0 | Windows Server 2022 | Dynamic processor compatibility mode, used by Windows Server 2025 hosts |
| 12.0 | Windows Server 2025 | GPU partitioning |

Version 11.0 belongs to Windows 11 and is not a server step. Microsoft's advice is to upgrade once the hosts are done, the cluster functional level is raised and the VM will not need an older host again, so the version step is the last planned change, VM by VM in its own window, with a written list of any VM left lower and why.

## The calendar: 40 VMs and 8 TB over 10 Gb or 1 Gb

Storage sets the pace, not compute: a VM's memory copies in minutes, but shared-nothing live migration copies every byte of every virtual hard disk across the link, so the arithmetic is total disk bytes divided by what the link delivers in practice.

Take 40 VMs totaling 8 TB, an average of 200 GB each with one 2 TB file server among them. A 10 Gb link is 1.25 GB per second on paper; plan on about half, 600 MB per second, because the source array's reads, the destination's writes and the copy protocol take their share. Eight terabytes is 8,000 GB, and 8,000 divided by 0.6 is about 13,300 seconds: under four hours of copying. A 1 Gb link is one-tenth of that, 60 MB per second in practice, so the same 8,000 GB takes about 37 hours.

| | 10 Gb link | 1 Gb link |
|---|---|---|
| All 8 TB | under 4 hours | about 37 hours |
| One 200 GB VM | about 6 minutes | about 1 hour |
| The 2 TB file server | about 1 hour | about 9 hours |
| Four-hour evening windows for 40 VMs | three, paced by validation | ten, paced by the link |

On 10 Gb the link is never the constraint; validation and the application owner's sign-off are, so the calendar is three evenings in one week. On 1 Gb it is four VMs an evening, the file server alone on a weekend, and two to three weeks.

## What not to move live: domain controllers, clustered guests, pass-through and shared disks

Domain controllers. A 2016 domain controller moved to 2025 hosts is still a 2016 domain controller, out of support on 12 January 2027, so domain controllers are replaced, not migrated, in the order our [order-of-operations article](/blog/replacing-windows-server-2016-domain-controllers-with-windows-server-2025-order-of-operations) sets out. At least one domain controller per site stays off the cluster it authenticates, because Microsoft's guidance on virtualized domain controllers says a clustered host needs a domain controller it does not itself host to start its resources; so the replacement is promoted off the cluster before that site's VMs move. A forest with several sites is the [Multi-Site Domain Controller Migration to Windows Server 2025](/services/multi-site-domain-controller-migration-windows-server-2025) service's job.

Clustered guests. A guest cluster on a shared VHDX or VHD Set does not move live: Microsoft's troubleshooting guide states that shared virtual disks can only be used in clustered VM roles and cannot be migrated by standard methods. The application's own high-availability feature does the move instead.

Pass-through disks and virtual TPMs. A physical disk attached directly to a VM is not part of a storage move; it is converted to a VHDX in a planned stop first. A VM with a virtual TPM moves cold unless its key-protector certificates are on the destination hosts.

## Two plans in progress

A medical practice of about 200 users is being acquired by a hospital group, with a possession date about four weeks out and an acquirer's checklist that requires central management of all servers. About a dozen servers, the Hyper-V hosts among them, are rebuilt on Windows Server 2022 and connected to Azure Arc as each reaches a supported operating system. The hosts are not rolled: each is emptied with shared-nothing live migration in an after-hours window, rebuilt, connected and refilled, with Kerberos constrained delegation set now so the later pass to Windows Server 2025 needs no second change, and VM versions held at 8.0 until the last host is rebuilt.

A hardware manufacturer with six sites on three continents and about ten Windows Server 2016 domain controllers runs virtual domain controllers on clusters that need Active Directory at boot; each site's replacement domain controller is promoted off the cluster first, and that site's VMs move after replication to it is confirmed.

## What it costs

[Hyper-V Failover Cluster Upgrade to Windows Server 2025](/services/hyper-v-cluster-upgrade-windows-server-2025) is $1,250 per server plus a $2,950 tenant fee over three weeks, "server" meaning a cluster node, and covers the new-cluster path: validation and delegation design, the cluster build and the moves in order, then functional level, versions, documentation and the decommission list. Hardware and Windows Server 2025 licenses are yours, Standard or Datacenter per node at the 16-core minimum plus 2025 CALs, priced in the [Windows Server calculator](/tools/windows-server-calculator) with the CAL version rule in [Licensing a domain-controller refresh](/blog/licensing-a-domain-controller-refresh-windows-server-2025-cores-and-the-cal-version-rule). A 2016 guest is upgraded separately through the [Windows Server 2016 to 2025 Upgrade Service](/services/windows-server-2016-to-2025-upgrade), $650 per server plus a $1,950 tenant fee over four weeks; a backup product that will not support 2025 hosts is the [Legacy Backup to Azure Backup Migration](/services/legacy-backup-to-azure-backup-migration), $120 per server plus a $2,950 tenant fee over three weeks. If the question is whether to leave on-premises, the [Azure Migrate Datacenter Discovery and Assessment](/services/azure-migration-discovery-assessment), $1,950 per project over two weeks, prices the Azure path first, and [Hyper-V to Azure Virtual Machine Migration](/services/hyper-v-to-azure-migration) runs from $4,950 over six weeks. Azure consumption, Arc add-ons and Azure Update Manager are Microsoft's charges, billed to you; our fees are quoted in writing.

## Frequently asked questions

### Can we live-migrate VMs from a Windows Server 2016 cluster to a new 2025 cluster without downtime?

With the VM running, yes, for a VM at 8.0 or later with Kerberos constrained delegation on all hosts. Microsoft documents the move as one-way and names no 2016-to-2025 pair at the time of writing, so a pilot proves it; a VM that fails it takes a short export and import.

### Why does cross-cluster live migration fail with a Kerberos or CredSSP error?

A delegation entry misses a host or a service, "Use any authentication protocol" is not selected, a host is still on CredSSP, which Credential Guard blocks on Windows Server 2025, or the change has not replicated and the host holds its old ticket. Errors 0x8009030E and 0x8009030D point at delegation or SPNs; 0x80070005 is access denied.

### When do we upgrade the VM configuration version?

After the last VM is off the old cluster and the new cluster's functional level is final: the upgrade is one-way, needs a shutdown, and a VM at 12.0 never runs on a 2016 host again.

### How long will 40 VMs take over a 10 Gb link?

For 8 TB of virtual disks, under four hours of copying at 600 MB per second, so validation sets the calendar: about three evening windows. Over 1 Gb it is about 37 hours and ten windows.

### Can a VM be moved back to the 2016 cluster if something goes wrong?

Not live: Microsoft's guide says migration works one way, not in reverse, after a move to a newer operating system. The way back for a VM still at 8.0 is a cold export and import or a restore, so the old cluster stays intact until you sign the decommission list.

## Sources

- Microsoft Learn, "Set up hosts for live migration without Failover Clustering" (windows-server/virtualization/hyper-v/deploy/set-up-hosts-for-live-migration-without-failover-clustering), ms.date 14 August 2025, retrieved October 2026
- Microsoft Learn, "Use live migration without Failover Clustering to move a virtual machine" (windows-server/virtualization/hyper-v/manage/use-live-migration-without-failover-clustering-to-move-a-virtual-machine), ms.date 19 February 2025, retrieved October 2026
- Microsoft Learn, "Upgrade virtual machine version in Hyper-V on Windows or Windows Server" (windows-server/virtualization/hyper-v/deploy/upgrade-virtual-machine-version-in-hyper-v-on-windows-or-windows-server), ms.date 30 June 2025, retrieved October 2026
- Microsoft Learn, "Cluster OS Rolling Upgrade" (windows-server/failover-clustering/cluster-operating-system-rolling-upgrade), ms.date 19 March 2025, retrieved October 2026
- Microsoft Learn, "Configure processor compatibility in Hyper-V virtual machines" (windows-server/virtualization/hyper-v/configure-processor-compatibility-mode), ms.date 6 August 2025, retrieved October 2026
- Microsoft Learn, "Hyper-V Virtual Machine Live Migration Troubleshooting Guide" (troubleshoot/windows-server/virtualization/hyper-v-virtual-machine-live-migration), ms.date 12 February 2026, retrieved October 2026
- Microsoft Learn, "Considerations and known issues when using Credential Guard" (windows/security/identity-protection/credential-guard/considerations-known-issues), retrieved October 2026
- Microsoft Learn, "Things to consider when you host Active Directory domain controllers in virtual hosting environments" (troubleshoot/windows-server/active-directory/ad-dc-in-virtual-hosting-environment), retrieved October 2026
- IT Partner Microsoft deadlines page: Windows Server 2016 end of extended support

## Key takeaways

- Build the 2025 cluster beside the 2016 one and move VMs one at a time with shared-nothing live migration.
- Kerberos constrained delegation on every host replaces CredSSP, which no longer works for live migration on Windows Server 2025.
- Keep every VM at 8.0 until the last one has moved, then raise versions to 12.0 in planned windows; the step is one-way.
- Disk bytes set the calendar: 8 TB is under four hours of copying over 10 Gb and about 37 hours over 1 Gb.
- Domain controllers are replaced, not moved; shared disks, pass-through disks and virtual TPM VMs move cold.

---

**Start with the delegation design and the pilot VM, not the first production move.** [Hyper-V Failover Cluster Upgrade to Windows Server 2025](/services/hyper-v-cluster-upgrade-windows-server-2025) ($1,250 per server plus a $2,950 tenant fee, three weeks) builds and validates the new cluster, moves the VMs in an agreed order and raises the versions last. Price the node licenses and CALs first with the [Windows Server licensing calculator](/tools/windows-server-calculator).