Treat the cluster functional-level update as a rolling-upgrade decision point

Source facts

Microsoft’s rolling-upgrade procedure advances a cluster by one Windows Server version at a time. The process is reversible until all nodes run the new release and the cluster functional level is updated. Before upgrading, the source calls for checking that storage, compute, and network capacity remain sufficient with a node removed. Microsoft documentation.

Applicability

Check the supported workload, version path, VM configuration, storage design, and management tooling. Review the source’s exclusions and special instructions rather than applying this procedure to every cluster workload.

DSE recommendation

Record an acceptance checkpoint before raising the functional level. Have workload owners review service tests, node versions, remaining capacity, and unresolved incidents from the mixed-version phase. Keep the decision to finalize separate from the completion of the last node installation.

Verification

Verify every node’s release and cluster state, then test representative workload moves and client transactions. Reconcile failures and backup readiness before the owner authorizes finalization. Preserve the before-and-after functional level and the accepted workload results so the irreversible transition has a clear evidence record.

Official references

Microsoft Learn: Upgrade the OS of a Windows Server failover cluster by performing a cluster OS rolling upgrade. Source reviewed September 8, 2026.