Windows Server 2016 loses support in January 2027
There is only one date to remember. Extended support for Windows Server 2016 ends on 12 January 2027. Mainstream support ended back on 11 January 2022, so since then the system has been receiving security updates only. After January 2027 it will not receive even those.
This calendar is no surprise. Windows Server releases in the long term servicing channel get a fixed ten year life: five years of mainstream support and five years of extended support. The date has been known since launch. It is just that almost nobody writes it into the company calendar.
The real trap is that on 13 January 2027 the server will boot as usual. Nothing goes dark, nothing shows a warning on the sign in screen, applications work exactly as they did the day before. One thing changes and it changes invisibly. The next vulnerability found in that system will no longer be fixed.
It pays to look past a single version. Windows Server 2019 has extended support until 9 January 2029. Windows Server 2022 leaves mainstream support on 13 October 2026 and has extended support until 14 October 2031. If you are buying a new server right now, that has a direct bearing on which version you install.
A server without patches is a problem for the whole company
Microsoft states the consequence plainly. End of support means the end of security updates and bulletins, which can cause security or compliance issues and put business applications at risk. That sentence comes from the vendor documentation, not from a service provider pitch.
In practice it starts with questions somebody has to answer in writing. An audit asks whether the systems in use are still supported by their vendor. Renewing a cyber risk policy means filling in a questionnaire where the same question usually appears. Large customers ask about it in their supplier surveys. A negative answer rarely ends the matter on the spot, but it always opens a conversation about conditions.
There is another layer that is easy to forget. Business software vendors list in their requirements which systems they support their product on. Once a system drops off that list, a ticket to their support desk ends with a request to upgrade. A failure that would normally take one day turns into a quarter long project.
And the most practical point of all. The longer a system sits without patches, the harder it becomes to touch it later. The number of things that have to happen inside one maintenance window keeps growing: the system, the drivers, the application, the database, sometimes the hardware. A migration done under the pressure of an incident looks nothing like one planned six months ahead.
Start with an inventory, not with a decision
Before anyone starts choosing between an upgrade and the cloud, you need to know how many machines you are talking about. In many companies the first answer is two or three, and after a look at the hypervisor it turns out to be eight. Servers from 2016 are rarely the ones in plain sight. More often they are the machines nobody touches, because one application runs on them and everyone is nervous about it. For each machine the inventory should answer a few questions:
- which version and edition of the system is actually installed
- which roles the machine holds, for example domain controller, file and print server, application server, database
- which application or business process runs on it and who uses it
- whether it is physical or virtual, and on which hypervisor it runs
- what the licensing status is, and whether the company has active Software Assurance or a suitable subscription
- who on the software vendor side is responsible for the application running on it
Devices that are not formally servers deserve a separate pass. Access control systems, video surveillance recorders, industrial machine controllers and appliances shipped with preinstalled software often have Windows Server inside. Not all of them can be upgraded, but you need to know they are there and plan separate protection for them.
While you count servers, count databases too. That calendar is even tighter. Extended support for SQL Server 2016 ended on 14 July 2026, so that line is already behind us. SQL Server 2017 reaches it on 12 October 2027 and SQL Server 2019 only on 8 January 2030. List your instance versions alongside the systems, because a database and the system underneath it very often get replaced in the same project.
Route one, upgrading in place
The simplest to describe and the most commonly chosen. You install a newer system on the same machine, keeping roles, settings and data. From Windows Server 2016 you can move directly to the 2019, 2022 or 2025 release. Microsoft also sets a rule on how far you can jump. If the target is the 2025 release, you may cross up to four versions at once. If the target is 2022 or older, the limit is two versions. In a cluster the rule is stricter, there the upgrade goes one version at a time.
Here is what hurts. Not every role survives an in place upgrade, so this has to be checked for your specific configuration rather than assumed. A domain controller has its own rules and its own order of operations. You cannot switch a Server Core installation to the desktop version, or the other way round, while you are at it. If the machine uses NIC Teaming, it has to be turned off before the upgrade and back on afterwards. A system that boots from a VHD file cannot be upgraded this way at all.
There is also a cost customers tend to discover last. Every Windows Server upgrade requires a separate licence. This is not a free swap of an older release for a newer one, the way it works on a staff laptop.
And then there is the quiet drawback of this route. An in place upgrade carries everything that has accumulated over ten years onto the new system. Old firewall exceptions, service accounts nobody remembers, settings added over one afternoon back in 2018. Sometimes it is exactly those that cause later failures nobody manages to link to the upgrade. A backup taken before you start and a tested way back are not extras here, they are the condition.
Route two, a new server and a role migration
You build a clean installation of the new system and then move roles, data and permissions across. More work than an in place upgrade, but the result is a machine with no history. This is usually the only route when the hardware is reaching the end of its life anyway, when the software vendor does not support the application on a newer system in the same installation, or when one of the roles will not survive an upgrade.
This route gives you one more thing an in place upgrade cannot. The old server stands next to the new one and keeps running until the switchover, so the way back is natural. You go back to what is still working. With an in place upgrade, going back always means restoring from backup, which means a longer outage and far more stress.
Here is what hurts. You need somewhere to stand up the second machine, even if only as a virtual machine for the duration. You have to work through the things that are easiest to forget: DNS records, certificates, shares and permissions, scheduled tasks, service accounts, integrations with other systems, printers. You also have to agree with the software vendor how the licence and the installation move to the new machine.
The biggest cost here is not hardware. It is the time for a calm switchover and for the testing that comes before it. A role migration squeezed into one night with no testing is the same amount of work, only with a worse ending.
Route three, moving to the cloud
The third option is to move the server to the cloud, in practice most often to Azure or Google Cloud. The machine is still a machine, it just sits with a cloud provider. The cost model changes along the way. Instead of one hardware purchase every few years there is a monthly bill, and a decision to add capacity no longer needs a purchase order.
In this particular scenario one thing speaks clearly in favour of Azure. Updates from the Extended Security Updates programme are free of charge for virtual machines in Azure, while outside Azure they have to be bought. If the company is considering the cloud anyway, end of support is a good moment for that conversation.
Here is what hurts. Not every application likes the cloud. Systems that talk to devices in the office or on the shop floor need a good link and a predictable response time, and sometimes they simply have to stay where they are. Cloud licensing is counted differently than on your own hardware, and it is worth working that out before the migration rather than after the first invoice.
There is also an easy trap. Moving an old system to the cloud does not make it any younger. Windows Server 2016 running in the cloud is still Windows Server 2016 and it still loses support in January 2027. That is why a split is usually the sensible answer. Some machines go to the cloud, some stay on site on a newer system, and each decision follows from what runs on that machine rather than from one rule for the whole company.
ESU buys three years, it does not solve anything
If the deadline cannot be met, the Extended Security Updates programme is what remains. Microsoft calls it a last resort option and a temporary bridge while you migrate, not a destination. The programme covers fixes for vulnerabilities rated critical and important, for a maximum of three years from the end of extended support.
It is worth knowing what ESU does not give you. No new features, no fixes unrelated to security, no changes on request. No ordinary technical support either. The programme covers the updates themselves, and assistance is limited in practice to deploying them and to problems they cause, not to general issues with the system. ESU does not extend the product lifecycle, it only defers one specific consequence.
On top of that come conditions that surprise people at the first quote. Outside Azure the updates have to be purchased, and active Software Assurance or a suitable subscription is a precondition. You cannot skip ahead between years, the second year requires the first. Sign up late and you pay for the months that have already passed. And after the third year the updates simply stop and the problem returns in exactly the same place.
The practical conclusion is simple. ESU makes sense as time deliberately bought to finish a migration that has already started and has an end date. As a way to push the subject out by a year it is just a more expensive form of delay.
What to do before it gets late
Under six months remain until January 2027, and for databases some of the deadlines have already passed. That is still enough to run the migration calmly, in maintenance windows you choose yourselves. But only if the inventory happens now rather than next quarter.
An order of work that holds up:
- build an inventory of machines and system versions, together with your SQL Server instances
- for every machine write down what runs on it and who depends on it
- choose a route for each machine separately, because one rule for all of them almost never works
- agree with your software vendors which systems they support their products on
- plan the maintenance windows and the way back before you touch anything
- only at the very end decide whether you need ESU, and for how long
If you do not know where to start, the simplest first step is a review of what is actually standing in the server room and an honest list of dates for each machine. Two conversations are usually enough to see which servers are urgent and which will comfortably last another year. We are happy to run that review together with your team.