Architecture
Windows Server 2016 End of Support and Your SQL Server
Windows Server 2016 leaves Microsoft's extended support on 12 January 2027. If SQL Server runs on it, the database is exposed even when the SQL Server version itself is still supported. The realistic options, ranked, and how to plan the move without disrupting the business.
By RadixTrie22 September 20264 min read
Windows Server 2016 reaches the end of Microsoft's extended support on 12 January 2027. From that date there are no more security updates for the operating system unless you pay for Extended Security Updates where Microsoft offers them. For most organisations that would be a routine platform refresh. For anyone running SQL Server on Windows Server 2016, it is a database problem, because the database is only as supported as the operating system underneath it. This article sets out what actually changes, why it matters more for database servers than for anything else in the estate, and the realistic options ranked from cleanest to riskiest.
What ends on 12 January 2027
Mainstream support for Windows Server 2016 ended in January 2022; extended support, which is security fixes only, ends on 12 January 2027. After that the operating system still runs, but any new vulnerability stays open. Auditors, insurers and payment-card assessors treat an unsupported operating system as a finding regardless of how well the software on top of it is patched. If the SQL Server instance on that machine is itself out of support, and SQL Server 2016 left extended support on 14 July 2026, the exposure is doubled: two unpatched layers under the same data.
Why the Windows Server 2016 end of support matters most for SQL Server
Database servers are the machines least likely to be rebuilt casually. They hold the state of the business, they have the tightest change windows, and the applications that depend on them are often certified only against specific versions. That is exactly why so many SQL Server estates still sit on Windows Server 2016: nobody wanted to touch what was working. The end-of-support date turns that caution into a liability. It also tends to arrive together with other deadlines. SQL Server 2017 leaves extended support on 12 October 2027 and SQL Server 2019 on 8 January 2030, so a plan that only moves the operating system will be back on the agenda within a year or two.
The options, ranked
- Build new and migrate side by side. A fresh Windows Server 2022 or 2025 host with a current SQL Server version, the databases restored or replicated across, applications tested against it, and a rehearsed cutover with the old server kept intact as the rollback path. This is the cleanest route and gives the longest runway: SQL Server 2022 is in extended support until January 2033 and Windows Server 2022 until October 2031.
- Upgrade the operating system in place. Possible where Microsoft's support matrix lists your SQL Server version on the newer Windows Server release, and attractive because the instance keeps its name and configuration. It carries more risk than a side-by-side build because there is no untouched server to fall back to, so it belongs behind a full backup that has been restore-tested.
- Move the workload to Azure. Either onto a SQL Server virtual machine on a supported operating system, or onto a managed service such as Azure SQL Managed Instance where the operating system stops being your problem. The move doubles as the version upgrade. It suits estates that were heading to the cloud anyway and needs the same compatibility assessment as any other migration.
- Buy Extended Security Updates as a bridge. Where Microsoft offers them for Windows Server 2016, they buy time rather than a solution, at a price that rises each year. Reasonable for a small number of servers with a hard dependency that cannot move yet, provided the plan to retire them has a date.
- Do nothing. This is a decision too, and it should be written down as one: which servers, which data, who accepted the risk, and what the compensating controls are, such as network isolation and tighter access. Most organisations find that writing it down is what moves the project.
Whichever option you choose, the first step is the same: an inventory of every SQL Server instance on Windows Server 2016, its edition and version, the applications that depend on it, and which of those applications are certified for newer versions.
How to plan the move without disrupting the business
Start with compatibility, not with hardware. Microsoft publishes which SQL Server versions are supported on each Windows Server release; that matrix decides whether an in-place upgrade is even available to you. Then check the application side: line-of-business vendors often certify a narrow band of SQL Server versions, and an upgrade that breaks certification trades one compliance problem for another. Build the target, restore a recent backup onto it and run the real application against it. Compare query performance across versions before cutover rather than after, because compatibility level changes can alter execution plans. Rehearse the cutover once end to end, including the rollback, and only then book the production window.
Most of this is ordinary senior DBA work; the difficulty is finding the time and the experience to do it properly while the day job continues. That is the gap our remote DBA services exist for: senior SQL Server engineers who plan and run upgrades and migrations for organisations wherever they are, from assessment through cutover, and who stay on afterwards under a fixed monthly retainer if you want them to. If the estate is still on SQL Server 2016 as well, our article on SQL Server 2016 end of support ranks those options, and how to migrate SQL Server to Azure covers the cloud route in detail. All of our database services are delivered by senior engineers, with no service desk between you and the person doing the work.
The short version
Windows Server 2016 is supported until 12 January 2027. SQL Server 2016 already is not. If either is under your data, decide now whether you are building new, upgrading in place, moving to Azure or buying time, write the decision down, and give it a date. Every one of those routes is easier with a rehearsed plan than with an emergency.
TAGSWindows ServerSQL ServerEnd of SupportUpgrade