Windows Server 2016 Hyper-V Hosts and Clusters: Rolling Upgrade or New Cluster

Hyper-V hosts are the one role where Windows Server 2016 end of support hits twice: the host itself, and every guest that also runs Windows Server 2016. This guide covers the host side, for a standalone Hyper-V server and for a failover cluster. It is built from Microsoft's own upgrade documentation and includes the cmdlets, the points of no return and the version-hop arithmetic that catches people out. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: Either.

Standalone hosts can be upgraded in place or replaced; a cluster can use Cluster OS Rolling Upgrade, but only one Windows Server version at a time, so 2016 to 2025 means three hops, or a new cluster.

The cluster rule is the one to plan around. Microsoft's article says you can upgrade only to the next newer version; to go from Windows Server 2016 to 2025 you run the process sequentially, first to 2019, then 2022, then 2025, or you migrate to a new cluster. For a small cluster, building a new one on a current version is often less work than three rolling upgrades.

Who this is for and what changes on the end-of-support date

This is for anyone running Hyper-V on Windows Server 2016: a single host in a branch office, a two-node cluster in a server room, a larger cluster with Cluster Shared Volumes or Storage Spaces Direct.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Plan to finish before 12 January 2027.

For a host, the date means that the operating system that sees every guest's memory, network and storage stops receiving security updates unless you buy Extended Security Updates (ESU). On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

Guests are separate. A Windows Server 2016 virtual machine on a new host is still a Windows Server 2016 machine with the same end date, so build your VM inventory now and treat each guest as its own item in the series.

Decision table

Licensing changes with new hosts: Windows Server Standard and Datacenter are licensed per physical core, and a cluster must cover every host a VM can move to. Our Windows Server licensing guide works through that arithmetic.

Steps, with the rollback point

These steps cover both cases. Where the cluster differs, it says so.

1. Inventory hosts, guests and versions. List virtual machines and their configuration versions with Get-VM * | Format-Table Name, Version, and see what each host supports with Get-VMHostSupportedVersion. For a cluster, Get-ClusterNode shows node state and Get-Cluster | Select ClusterFunctionalLevel shows the level; value 9 is Windows Server 2016, 10 is 2019, 11 is 2022 and 12 is 2025.
2. Check blockers. Microsoft's cluster article names several. Hyper-V hosts need CPUs with Second-Level Address Translation (SLAT). VM configuration versions older than 8.0 cannot run on Windows Server 2022. LBFO network teams are not supported with Hyper-V in Windows Server 2022 and newer, so virtual switches built on one need to be rebuilt on Switch Embedded Teaming (SET). The rolling upgrade article does not apply to clusters that use virtual hard disk files as shared storage. If you use System Center Virtual Machine Manager, Microsoft points to its own rolling-upgrade procedure.
3. Back up and test. Back up every VM, and back up the cluster database with a System State backup. Microsoft notes that if you find a problem after the functional level is raised, an authoritative restore on a node running the previous version using that backup is the way back.
4. Check capacity. With one node out, can the cluster still run the workload with the fault tolerance you need? Microsoft suggests temporarily adding a node to a two-node cluster. Confirm cluster health with Test-Cluster and apply the latest updates to every node.
5. Pause the update tooling. If you use Cluster-Aware Updating, check Get-CauRun and run Disable-CauClusterRole so a node is not drained mid-upgrade. Pause backup jobs that touch the cluster.
6. Standalone host, in place. Plan guest downtime, disable NIC Teaming as Microsoft requires, run Setup from installation media and keep files and settings, then check the virtual switches. If you can, build a replacement host first and move the guests across: Microsoft notes a host can import virtual machines created on an older Hyper-V version but not on a newer one.
7. Cluster, node by node. For each node: drain it with Suspend-ClusterNode -Name Node1 -Drain; if you are doing a clean install, evict it with Remove-ClusterNode -Name Node1; install the newer Windows Server; recreate the virtual switch (use New-VMSwitch with SET if you removed an LBFO team); rejoin with Add-ClusterNode after a clean install, or Resume-ClusterNode -Name Node1 -Failback Immediate after an in-place upgrade. The first upgraded node puts the cluster into mixed-OS mode. Microsoft recommends finishing the whole cluster within four weeks, managing it from a node on the newer version, and not creating or resizing storage while versions are mixed.
8. Rollback point 1: before the functional level. Microsoft states that the process is fully reversible until you update the cluster functional level: add nodes running the original version and remove nodes running the newer one. Do not move to the next step until every workload has run on the new nodes for long enough to trust them.
9. Raise the functional level. With every node up and in the cluster, run Update-ClusterFunctionalLevel, then Get-Cluster | Select ClusterFunctionalLevel to confirm. If you use Storage Spaces Direct or other storage pools, run Update-StoragePool as well. Microsoft warns this cannot be undone and that earlier nodes can no longer join. Rollback point 2: the System State backup from step 3.
10. Repeat for the next hop. Each version is its own cycle with its own four-week window and its own point of no return. Re-enable Cluster-Aware Updating with Enable-CauClusterRole only when you finish.
11. Upgrade VM configuration versions last. Once hosts and functional level are final and you are sure you will not move a VM back, shut down the VM and run Update-VMVersion <vmname>. Microsoft states the upgrade cannot be reversed and that the VM will not start on hosts that do not support the new version.
12. Azure route. For VMs going to Azure, install the Azure Site Recovery provider on each host or cluster node, register it with the key from the Azure Migrate project (valid for five days), run a test migration into a non-production network, then migrate and select Complete migration. By default Azure Migrate shuts down the source VM and runs a final sync, which avoids data loss.

Mistakes that cause outages

• Planning one hop when you need three. The cluster rule is one version at a time. Put each hop on the calendar with its four-week window.
• Leaving the cluster in mixed mode. Microsoft recommends four weeks; features are not tuned for mixed clusters and storage changes on a mixed cluster can cause failover problems.
• Upgrading VM configuration versions early. It removes your way back to older hosts, and Microsoft says to do it after the functional level is final.
• Forgetting LBFO. A virtual switch tied to an LBFO team needs rebuilding as SET on 2022 and newer.
• Running a two-node cluster at full load. Draining the only other node removes your fault tolerance.
• Letting update tooling drain nodes mid-upgrade. Disable Cluster-Aware Updating first.
• Forgetting hardware support. Check the server vendor's support and drivers for the target Windows Server version before you start.
• Treating the guests as done. Guests on Windows Server 2016 still reach end of support.

Checklist

• Hosts, guests, VM configuration versions and cluster functional level documented
• Blockers checked: SLAT, VM versions below 8.0, LBFO, shared VHDX storage, VMM
• Backups taken, System State backup of the cluster, a restore tested
• Hop plan written: 2019, 2022, 2025, or a new cluster
• Cluster-Aware Updating paused; capacity checked
• Mixed-OS window of four weeks or less per hop
• Functional level and storage pool raised only after validation
• VM configuration versions upgraded last
• Guest operating systems added to the 2016 inventory
• Finish before 12 January 2027

Related tools and reading

Start with the role-by-role Windows Server 2016 end-of-support planner on our licensing calculator. If you are weighing hardware against the cloud, the Hyper-V vs Azure VMs vs Azure Local three-year cost model shows how we modelled it, and the licensing guide covers cores, stacking and clusters.

Sources

Checked 6 November 2026.

• Windows Server 2016 on Microsoft Lifecycle
• Extended Security Updates for SQL Server and Windows Server
• Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
• License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
• Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
• Product Lifecycle FAQ: Extended Security Updates
• Plan your Windows Server upgrade path
• Upgrade and migrate roles and features
• Cluster OS rolling upgrade (requirements, limits, cmdlets, reversibility)
• Upgrade virtual machine version in Hyper-V (configuration versions, irreversibility)
• Migrate Hyper-V VMs to Azure with Azure Migrate

General planning information, not a design for your environment. Rehearse the first hop on a non-production cluster if you can.