Hyper-V Failover Cluster Upgrade to Windows Server 2025
IT Partner upgrades Hyper-V failover clusters of 2 to 16 nodes to Windows Server 2025 with the virtual machines kept running. The engagement starts with cluster validation and a hardware, firmware and driver check against Windows Server 2025, then follows the path your starting version allows: Microsoft's Cluster OS Rolling Upgrade for clusters on Windows Server 2022 — one node at a time, VMs live-migrated around the work, the cluster in mixed-OS mode until the last node is done — or, for clusters still on 2019 or 2016, either sequential rolling upgrades or a new Windows Server 2025 cluster built alongside with the VMs moved by cross-cluster live migration, because the rolling process moves one operating-system version at a time and cannot skip. The storage path is handled for what you actually run: Storage Spaces Direct, SAN-backed Cluster Shared Volumes, or SMB file shares. Kerberos constrained delegation is configured for live migration, since CredSSP stops working once a host is on Windows Server 2025. Then the cluster functional level is raised, the storage pool updated, virtual machine configuration versions moved to 12.0 in planned windows, Cluster-Aware Updating re-enabled, System Center Virtual Machine Manager compatibility confirmed, and as-built documentation handed over. Three weeks covers one cluster on a single-hop or new-cluster path; multi-hop paths take longer and the plan states the real dates. Pricing is an estimate at $1,250 per cluster node — the 'server' unit on our price list — plus a $2,950 base fee, confirmed as a fixed written quote after validation; multi-cluster and stretched-cluster estates are quoted per estate. Three boundaries up front: we do not procure hardware, we do not upgrade the guest operating systems inside the VMs, and Windows Server 2025 licensing — Software Assurance, subscription or new licences — is yours to hold, checked before the first node is touched.
What this engagement is
A Hyper-V failover cluster is the one server upgrade that sits underneath every other server you own, which is why it is usually the last one anyone volunteers for. The calendar is now forcing the question. Windows Server 2016 leaves extended support on 12 January 2027 and Windows Server 2022 leaves mainstream support on 13 October 2026, both per Microsoft's product lifecycle; Windows Server 2019 has runway until January 2029, but as we explain below it is two upgrade hops away from 2025, so waiting makes the job longer, not shorter. Add the organizations rebuilding on Hyper-V because of VMware's licensing changes, and there is a clear window in which mid-size and enterprise clusters need to land on Windows Server 2025 deliberately rather than under duress. This engagement does that for one cluster of 2 to 16 nodes, with the virtual machines running throughout, at a per-node price — and it starts by telling you, with validation output in hand, which of three paths your cluster can actually take. For a cluster already on Windows Server 2022 the path is Microsoft's Cluster OS Rolling Upgrade, and it is the good news of this page. One node at a time is drained, its VMs live-migrated to its neighbours, rebuilt on Windows Server 2025 and rejoined; the cluster runs in mixed-OS mode with 2022 and 2025 nodes side by side, workloads stay up, and the whole thing is reversible right up to the moment the cluster functional level is raised. Microsoft recommends finishing the process within four weeks; we plan it inside the three weeks of this engagement. Each node can be clean-installed or in-place upgraded — Microsoft supports both — and our default is a clean install, because a hypervisor host carries almost no state worth preserving and a fresh build sheds years of driver and agent residue; we take the in-place route when a node's configuration is heavy and the schedule argues for it. Two things people learn the hard way come standard: CredSSP-based live migration stops working once a host is on Windows Server 2025, because Credential Guard is on by default, so Kerberos constrained delegation is configured before the first 2025 node joins; and the VM configuration versions are left alone until every node is done and the functional level is raised, because a VM moved to version 12.0 can never run on a 2022 host again. Clusters on Windows Server 2019 or 2016 face a harder fact: the rolling-upgrade process moves a cluster one operating-system version at a time. Microsoft's guidance for going from 2016 to 2025 is to run the upgrade sequentially — 2016 to 2019, 2019 to 2022, 2022 to 2025 — and each hop is a full pass through every node, with Storage Spaces Direct clusters on 2016 following a separate procedure for their first hop. That is one option, and for a small cluster on hardware the OEM still supports it can be the right one. The other is to build a new Windows Server 2025 cluster beside the old one — on new nodes, or on nodes carved out of the existing cluster where capacity and storage resiliency allow — and move the VMs by cross-cluster live migration: each VM leaves the old cluster's high-availability configuration while it keeps running, live-migrates with its storage to a node of the new cluster, and is made highly available again there. Which path wins is a week-one decision made with numbers: node count, hardware age against the OEM's Windows Server 2025 support matrix, storage type, spare capacity, and the licensing you hold. Windows Server 2025 also requires processors with the POPCNT and SSE4.2 instructions, and recommends UEFI, Secure Boot and TPM 2.0 for Secured-core features — the validation report says exactly where your hardware stands before anyone commits. What you get at the end is not just a supported cluster. Windows Server 2025 raises Hyper-V's limits considerably, makes Generation 2 the default for new VMs, adds a dynamic processor compatibility mode that stops mixed CPU generations from costing you performance, supports live migration for VMs using GPU partitioning, and makes Network ATC's intent-based host networking available on Windows Server rather than only on Azure Local. Hosts connected through Azure Arc can also use hotpatching, which turns most monthly host reboots into a handful of planned events a year — our Azure Arc Hybrid Server Management service is the separate engagement that gets the upgraded cluster there. And one honest framing before any of it: not every cluster should be upgraded. Some estates are better served by moving the VMs to Azure or by rebuilding on Azure Local, and if the numbers point that way we say so in the validation report and route you to the right page rather than upgrading a platform you are about to leave.
Which one applies to you
Three paths reach Windows Server 2025. The cluster's starting version decides which are open; the week-one validation report recommends one with the reasons written down.
| Rolling upgrade — single hop | Sequential rolling upgrades | New 2025 cluster + cross-cluster live migration | |
|---|---|---|---|
| Starting version | Windows Server 2022. | Windows Server 2019 (two hops) or 2016 (three hops, with the Storage Spaces Direct-specific procedure for 2016 to 2019). | Any version — and the only path when the hardware fails Windows Server 2025 validation. |
| Hardware | Existing nodes; each is clean-installed or in-place upgraded and rejoined. | Existing nodes, rebuilt once per hop — so OEM support for every intermediate version matters too. | New nodes, or nodes carved out of the old cluster where capacity and storage resiliency allow; procurement is yours. |
| VM downtime | None for the OS moves. A shutdown per VM later, in planned windows, for the configuration-version update. | None for the OS moves; the same planned shutdowns for VM versions at the end. | None for most VMs — cross-cluster live migration moves them running. A shutdown where processor compatibility mode has to be switched on for a CPU-generation change, and the same planned window for VM versions. |
| Storage | Storage Spaces Direct pool updated after the functional level; SAN volumes and SMB shares carry through mixed-OS mode. | As single hop, once per hop; Storage Spaces Direct resync gates each node move on every pass. | Shared-nothing migration copies each VM's disks over the network to the new cluster's storage; SAN LUNs are re-presented only where planned. |
| Inside the 3 weeks? | Yes, for one cluster of 2 to 16 nodes. | No — each hop is a full pass; the plan states the real dates and the estimate covers them. | Yes for the cluster build and the migration of a typical estate; very large VMs and thin network links extend the migration calendar. |
| Our recommendation | Take it — this is the cleanest upgrade Microsoft offers. | Right for small clusters on supported hardware where new nodes are not an option; otherwise the third column usually wins. | Usually the better answer for 2016 clusters and for anyone replacing hardware anyway; also the path used for clusters rebuilt after leaving VMware. |
Multi-cluster estates, stretched clusters using Storage Replica, and cluster sets are quoted per estate after a scoping call — the per-node price on this page assumes one cluster.
Reversibility: the rolling paths can be rolled back until the cluster functional level is raised; the new-cluster path keeps the old cluster intact until the last VM has moved and you sign the decommission.
Success criteria
What you receive
How the work unfolds
We inventory the cluster — nodes, versions, storage, networking, VMM, backup and monitoring agents — and run Microsoft's cluster validation plus the hardware, firmware and driver check against Windows Server 2025. The licensing check happens here too, because a cluster without version rights to 2025 is not a cluster we upgrade.
You receive the validation report and the recommended path with the hop count, node order, maintenance windows and rollback points. Kerberos constrained delegation is designed. Backups are verified as current and restorable, and the backup product's support for Windows Server 2025 hosts is confirmed with its vendor. You approve the plan before anything is changed.
The first node is drained, its VMs live-migrated away, rebuilt on Windows Server 2025, patched, given its drivers and agents, and rejoined. We watch it carry production VMs in mixed-OS mode and validate live migration in both directions before touching a second node. On the new-cluster path, this milestone is the first two nodes of the new cluster built and validated.
The remaining nodes follow the same procedure inside their windows — typically one or two nodes per day, slower on Storage Spaces Direct where repair jobs must finish before the next node leaves. On the new-cluster path, VMs are cross-cluster live-migrated in the agreed order, with checks on each after it lands. Large clusters can run into week 3; the plan states the real dates.
With every node on Windows Server 2025 and the pilot period behind us, the cluster functional level is raised on a date you confirm, the storage pool updated where present, VM configuration versions moved to 12.0 in their planned shutdown windows, Cluster-Aware Updating re-enabled and VMM reconciled.
Cluster validation runs on the finished cluster, the success criteria are checked one by one, and your team receives the as-built documentation, the runbook and the handover session. On the new-cluster path, the old cluster's decommission checklist is delivered for your signature.
Prerequisites
Who does what
IT Partner
- Run validation, produce the path decision and plan, and design the delegation, storage handling and node order.
- Execute every node move, storage step, functional-level raise, VM version update and CAU re-enablement inside the approved windows.
- Build and validate the new cluster and run the cross-cluster live migrations on that path.
- Reconcile VMM, verify the quorum witness and live migration after each change, and stop and roll back when validation says so.
- Deliver the as-built documentation, runbook, handover session and the finished-cluster validation report.
- Say plainly when a cluster should not be upgraded, and route it to the right alternative.
Your team
- Hold Windows Server 2025 licensing for every node, and Datacenter edition where the design needs it.
- Provide hardware, firmware access and OEM support entitlements, and procure new nodes where the plan requires them.
- Provide access, approvals and maintenance windows, including the domain administrator for constrained delegation.
- Confirm backups are current and the backup product is on a version that supports Windows Server 2025 hosts.
- Sign the functional-level raise date, the VM configuration-version list and, on the new-cluster path, the old cluster's decommission list.
- Own the guest operating systems inside the VMs and the applications on them, including their testing after each planned shutdown.
What's not included
Limitations & technical notes
Frequently asked questions
Can we upgrade a Windows Server 2016 or 2019 Hyper-V cluster straight to 2025?
Not with a rolling upgrade. Microsoft's Cluster OS Rolling Upgrade moves a cluster to the next version only, so 2019 needs two passes (2019 to 2022, then 2022 to 2025) and 2016 needs three, with a separate procedure for Storage Spaces Direct on the first hop. The alternative is a new Windows Server 2025 cluster beside the old one, with the VMs moved by cross-cluster live migration — for most 2016 clusters, and for anyone replacing hardware anyway, that is the path we end up recommending. The week-one validation report puts the two side by side with your numbers.
Will our virtual machines go down?
Not for the operating-system moves. Rolling upgrade live-migrates VMs off each node before it is rebuilt and the cluster keeps serving in mixed-OS mode; cross-cluster live migration moves running VMs to the new cluster. Two steps do need a short planned shutdown per VM, scheduled in windows you approve: updating the VM configuration version to 12.0 at the end, and enabling processor compatibility mode where a VM is crossing CPU generations. Application testing after those shutdowns is yours; we tell you exactly which VMs and when.
What is mixed-OS mode and how long can we stay in it?
It is the cluster running Windows Server 2022 and 2025 nodes together while the upgrade is in progress. Everything works, VMs move freely between the two versions, and the process stays reversible — a 2025 node can be rebuilt back to 2022 — until the cluster functional level is raised. Microsoft recommends completing the pass within four weeks and notes that new features stay off until the functional level is raised; we plan the entire pass inside the three-week engagement so mixed mode is a corridor, not a destination.
What happens to Storage Spaces Direct during the upgrade?
Each node goes into storage maintenance mode before it leaves, so the pool tolerates its absence, and after it rejoins we wait for the storage repair jobs to finish before the next node moves — that waiting is why S2D clusters roll more slowly than SAN clusters. After the last node and the functional-level raise, the storage pool version is updated, which is also one-way. S2D needs Datacenter edition, and a 2016 S2D cluster follows Microsoft's specific 2016-to-2019 procedure for its first hop, which is one more reason the new-cluster path often wins for 2016.
We use a SAN with Cluster Shared Volumes — is that easier?
Usually, yes. The LUNs stay where they are and Cluster Shared Volumes carry through mixed-OS mode; the gating items are HBA and multipath driver support for Windows Server 2025 from your storage vendor, and array firmware the vendor supports with the new OS. Those are checked in validation. On the new-cluster path, VMs move by shared-nothing live migration onto the new cluster's storage; re-presenting existing LUNs to the new cluster is possible but is an offline operation we plan only where it clearly beats copying.
Why do you insist on Kerberos constrained delegation?
Because CredSSP-based live migration is not available once a host is on Windows Server 2025 — Credential Guard is enabled by default and blocks it. If delegation is not in place before the first 2025 node joins, live migrations involving that node fail, which is exactly the moment you need them. Setting delegation up requires Domain Admins rights, so we design it, your domain administrator applies it with us, and it is documented per host in the as-built.
Should we update the VM configuration version, and what does it get us?
Yes, once every node is on Windows Server 2025 and the functional level is raised — not before, because a VM at version 12.0 can never run on an older host again, and the update needs the VM shut down. Version 12.0 unlocks the Windows Server 2025 features for that VM, including the higher limits and the dynamic processor compatibility mode. We do it VM by VM in planned windows, and any VM you want held back — a vendor appliance, a system with a fragile change process — is listed with the reason rather than silently skipped.
Do we need new hardware?
Not by default. Rolling upgrade reuses your nodes. Windows Server 2025 does require processors with the POPCNT and SSE4.2 instructions and recommends UEFI, Secure Boot and TPM 2.0 for Secured-core features, but the practical gate is whether your server OEM supports the model on Windows Server 2025 with current firmware and drivers — and 2016-era hardware often fails that test. Validation gives you the answer in week 1; if the answer is no, the plan becomes a new-cluster build on nodes you procure, and we move the VMs across.
We manage the cluster with System Center Virtual Machine Manager. What changes?
Your VMM version has to support Windows Server 2025 hosts before the first node is upgraded, or VMM loses visibility of the cluster mid-flight. Microsoft's system requirements list Windows Server 2025 as a supported host for VMM 2025; whether your current version qualifies is confirmed in week 1 against Microsoft's current matrix, and a VMM upgrade, if required, is a prerequisite we document and scope separately. Where VMM's own rolling-upgrade orchestration fits your estate we use it; otherwise the native process is used with VMM reconciled afterwards.
What licensing do we need for Windows Server 2025 on the cluster?
Rights to run the new version on every node: active Software Assurance, a subscription licence, or new Windows Server 2025 licences, with the standard 16-core minimum per host. Datacenter edition is required for Storage Spaces Direct and for unlimited virtual machines per host; Standard covers two virtual machines per fully licensed host. Client access licences are unaffected by the host upgrade. We check what you hold in week 1 and route open questions to our Volume Licensing advisory; the licences themselves are yours to buy.
Should we upgrade this cluster at all, or move to Azure or Azure Local?
A fair question, and the validation report answers it honestly. A cluster with supported hardware, a workload that belongs on-premises and licensing in hand should be upgraded — it is the cheapest supported state available. A cluster on end-of-life hardware, or one hosting workloads that are mostly candidates for the cloud, may be better retired: the Azure Migrate Datacenter Discovery and Assessment prices that alternative against your real costs, the Hyper-V to Azure Virtual Machine Migration is the page that moves them, and Azure Local is the on-premises rebuild option with its own hardware catalogue and subscription model. We do not upgrade a platform you are about to leave.
We are leaving VMware. Can you build the new Windows Server 2025 cluster?
Yes — the new-cluster path of this service is the same build: nodes, networking, storage, quorum, validation and Cluster-Aware Updating, on Windows Server 2025 from day one. What it does not include is converting the VMware virtual machines to Hyper-V, which is a conversion engagement with its own tooling and testing and is quoted separately. If Azure rather than Hyper-V is where the VMs should land, the VMware to Azure migration is the honest page.
What about our backup software and other host agents?
They need versions their vendors support on Windows Server 2025, and the backup product also needs to support VM configuration version 12.0 or the upgraded VMs stop being protected. We inventory the agents in week 1, you obtain the supported versions, and we stage them on the pilot node before anything else moves. If the backup product cannot get there, the plan pauses rather than proceeding unprotected — and Azure Backup for servers is the separate engagement that removes the dependency.
What if we cannot finish before 12 January 2027?
Then the 2016 nodes need Extended Security Updates for the interval, which Microsoft sells per core per year, billed to your Azure subscription when enrolled through Azure Arc; the charge is Microsoft's and yours. Our Managed ESU and Legacy Server Lifecycle service handles that enrolment and the exit plan. The better answer is to book validation now: a 2022 cluster fits inside three weeks, and even a three-hop 2016 estate has room before the date if the decision is made promptly — the Windows Server 2016 End of Support Assessment and Roadmap is where a wider 2016 estate gets that sequence.