Upgrading the operating system underneath SQL Server is usually driven by someone else: a support deadline, a security policy, a hardware refresh. That does not make it someone else problem, because SQL Server is the thing that will be blamed if it comes back wrong.
There are three approaches, and the right one depends mostly on whether the instance is clustered.
The Three Approaches
Build the new OS on new hardware and migrate SQL Server onto it. The rollback is the old server, still running.
Faster, fewer moving parts, and the rollback is a restore. Needs a supported upgrade path and a verified backup before you start.
For a WSFC running an AG or FCI. Upgrade the passive nodes first, fail over onto an upgraded node, then upgrade what used to be the primary, and update the cluster functional level at the end.
Network Pre-Flight
This applies to the side-by-side approach, which is a migration underneath. In-place and rolling cluster upgrades keep their hosts and their firewall rules. Run these days before the window, from the machines that will actually make the connections.
- Port 1433 to the target from the source server, from every application server, and from your own workstation:
Test-NetConnection new-server -Port 1433. A named instance needs its fixed port instead, plus UDP 1434 if clients rely on the Browser service. Walkthrough: testing remote port connectivity with PowerShell. - Port 445 to the backup share, from both sides. The source writes the backups and the target restores them, so test the share from each server, not just the one you happen to be logged into.
- Firewall rules in both directions on the new host. Inbound 1433 is the rule everyone remembers; outbound to the backup share, monitoring, and any linked servers is the one that turns up mid-window. Reference: SQL Server default ports.
- Line of sight from the applications, before cutover. Every app server and VM that will connect must reach the target before the window opens, tested from those machines rather than from the DBA workstation. A connection that fails at pre-flight is a task; the same failure after cutover is an incident.
- After cutover: DNS and SPNs. Repoint the CNAME and respect the TTL, because clients keep the old record for exactly as long as you told them to. Then re-register the SPNs for the new host so Kerberos keeps working; miss that and connections either fall back to NTLM quietly or fail with the pre-login handshake error.
The In-Place Sequence
- Full health check and a verified database backup before anything starts
- Confirm the .NET Framework requirements for your SQL Server version
- Stop SQL Server Agent, which is recommended rather than required, but makes the restart predictable
- Run the Windows Server upgrade
- Validate SQL Server afterwards, then check Windows features and TLS settings
- Start Agent, verify the jobs, and finish with a health check
SQL Server 2016 and later require TLS 1.2, and an OS upgrade can leave it disabled. The symptom is applications that cannot connect at all, which looks like a much bigger problem than a registry setting. Check it as part of the upgrade, not after the phone rings.
The full version, with every command, is in the repo. Includes the SQL Server and Windows Server compatibility matrix, the supported in-place paths, the rolling cluster procedure and the key gotchas.
Frequently Asked Questions
Is an in-place Windows upgrade safe under SQL Server?
It is supported on specific paths, and the compatibility matrix in the runbook tells you which. What makes it risky is not the upgrade itself but doing it without a verified backup and a rollback you have thought through.
Do I need to stop SQL Server first?
The upgrade will handle the services, but stopping Agent first is recommended so jobs do not fire during the restart sequence and leave you diagnosing two problems at once.
What order do I upgrade cluster nodes in?
Passive nodes first. Pause the node, drain its roles, upgrade it, bring it back, then fail over onto it before touching the node that was primary.
What should I check immediately afterwards?
That SQL Server started, that TLS 1.2 is enabled, that Agent jobs are running, and then a full health check. In that order, because each one rules out a class of problem.
The OS upgrade is one half of the window. These cover the SQL Server half and the alternative to doing it in place.
- SQL Server Version Upgrade Runbook, the SQL Server side of the same maintenance window.
- SQL Server Migration Runbook: Standalone, the alternative to an in-place OS upgrade, which is to move the instance.
- SQL Server Change Management, the change order, and the rollback you need agreed before you start.
Leave a Reply