End of support

Windows Server 2016 End of Life: The January 12, 2027 Deadline

Extended support for Windows Server 2016 ends on January 12, 2027. That is close enough that planning should start now, and far enough that nothing has to be rushed.

Published July 29, 2026 · Last updated September 14, 2026

The date, and what it actually means

Windows Server 2016 end of life, end of support and EOL all refer to the same date: January 12, 2027. After that day Microsoft stops issuing security updates for the operating system unless you buy Extended Security Updates separately.

Windows Server 2016 reached the end of mainstream support on January 11, 2022. Extended support ends on January 12, 2027, per Microsoft's lifecycle documentation.

As with every Microsoft end-of-support date, the server does not stop working. It does not phone home, degrade, or refuse to boot. What ends is the supply of security patches for newly discovered vulnerabilities, unless you buy Extended Security Updates separately.

The distinction that matters: since January 2022, Windows Server 2016 has already been receiving security fixes only. No new features and no ordinary bug fixes have shipped for four years. January 2027 removes the last category — security patches — and that is the one with real exposure attached to it for an internet-facing web server.

Why this is the right time to plan, not to panic

There is a predictable rhythm to how these deadlines play out, and understanding it is worth more than any technical detail.

Roughly six months out, nothing feels urgent. The server is running fine, there is no visible symptom, and the deadline is comfortably in the future. Around two months out, someone external raises it — an auditor, an insurer, a client security questionnaire, or a compliance review. At that point the timeline is no longer yours, and the options narrow to whatever can be done quickly.

The difference between planning at six months and reacting at two is not mainly cost, though it usually is cheaper. It is that at six months you can choose the right path. You can test properly, run old and new in parallel, cut over in a planned window, and back out if something surprises you. At two months, the realistic option is whatever is fastest, which is usually a straight rehost whether or not a rehost is the right long-term answer.

As of September 2026, January 12, 2027 is about four months away. That is still the end of the window where the timeline is yours to choose — but it is no longer the comfortable end of it.

What matters specifically for an IIS website

A Windows Server 2016 box running IIS 10 has a few characteristics worth checking before deciding where it goes.

The .NET Framework version is a separate question. The operating system deadline and the framework lifecycle are not the same thing. .NET Framework 4.8 and 4.8.1 remain supported as components of the operating systems they are installed on, per Microsoft's .NET Framework lifecycle page. An application on 4.8 is not itself out of support just because the server underneath it is going out of support. That often means a rehost is genuinely sufficient and a rewrite is not required.

Older framework versions are a different story. .NET Framework 4.6.2 support ends January 12, 2027 — the same day as the operating system. If the application targets 4.6.2 or earlier, the framework and the server go out of support together, and retargeting to 4.8 is worth doing as part of the same project.

Custom IIS modules and COM dependencies drive the timeline. The single biggest variable in how long a move takes is not the size of the site. It is how much of the environment is undocumented — native IIS modules, registered COM components, ISAPI filters, scheduled tasks that nobody remembers creating, or file system paths hardcoded into configuration. A clean ASP.NET site with a SQL Server database moves quickly. A site with a decade of accumulated server-level customization takes longer, and the discovery work is most of it.

The realistic options

Four paths, in rough order of how often they turn out to be the right one.

Rehost to Azure App Service. If the application is a reasonably conventional ASP.NET site, this removes the server entirely — no operating system to patch, no end-of-support date to track next time. It is the cleanest exit from the treadmill. It is also the option most likely to expose hidden dependencies, because App Service deliberately does not give you a general-purpose Windows server. The article on moving IIS to Azure App Service covers what tends to break.

Rehost to an Azure virtual machine. The same Windows Server, running in Azure instead of on your hardware. This does not escape the patching treadmill, but it does eliminate the hardware risk, and Extended Security Updates come free with Azure-hosted workloads. A reasonable middle step when the application is too opaque to move to App Service confidently.

Rebuild. Right when the application is the actual problem rather than the server — unmaintainable, insecure at the application layer, or blocking work the business needs to do. The end-of-support date is the trigger, not the reason.

Replace. Right when the site turns out not to need a server at all, or when it runs on off-the-shelf software that can be swapped for a maintained equivalent. Both variants are covered in the main migration guide.

Which of these fits your site is not usually obvious from the outside. The two-minute assessment asks six questions about one specific site and names a path with its reasoning — free, no email, and nothing leaves your browser.

Frequently asked questions

What happens on January 13, 2027 if I do nothing?

Operationally, nothing. The server runs exactly as it did the day before. Microsoft stops issuing security patches for newly discovered vulnerabilities, so the risk grows over time rather than appearing all at once. The practical consequences usually arrive through a third party first, in the form of a failed security questionnaire, an insurance condition, or a compliance finding.

Can I buy Extended Security Updates for Windows Server 2016?

Yes. Extended Security Updates are available for Windows Server, priced annually and escalating each year. They cover critical and important security updates only, not features, bug fixes, or general support. They are included at no additional cost for workloads running in Azure.

Does my application need rewriting, or just moving?

Usually just moving. If the application targets .NET Framework 4.8, it remains supported and the operating system deadline does not force a rewrite. If it targets 4.6.2 or earlier, that framework version also goes out of support on January 12, 2027, and retargeting to 4.8 is worth folding into the same project.

Is Windows Server 2016 end of life the same as end of support?

Yes — they name the same date. Microsoft's own term is end of support, and for Windows Server 2016 that date is January 12, 2027. End of life and EOL are the phrases most people search for, and in practice they mean the same thing: the last day Microsoft issues security updates for the product without a paid Extended Security Updates agreement.

The distinction that actually matters is a different one. Mainstream support for Windows Server 2016 ended on January 11, 2022 — that is when new features and ordinary bug fixes stopped. January 12, 2027 is when security patches stop, and that is the one with real exposure attached to it for a public-facing web server.

Does Windows Server 2016 end of support affect IIS as well?

Yes. IIS is a component of the operating system rather than a separately licensed product, so IIS 10.0 follows the same lifecycle as the Windows Server 2016 installation it ships with. When the operating system stops receiving security updates on January 12, 2027, so does the web server software serving your site.

That is why an out-of-support server matters more for a public website than for an internal file server. The component that stops being patched is the one directly exposed to the internet.

Will Windows Server 2016 still pass a security audit or cyber-insurance review after January 2027?

Usually not, and this is how the deadline tends to turn urgent. An unsupported operating system is a standard finding in security questionnaires, compliance assessments and cyber-insurance renewals, because the control being tested is whether security patches are being applied — and after January 12, 2027 they are no longer being issued.

The timing is worth planning around, because these reviews run on their own calendar. A renewal date, an audit window, or a client's vendor assessment can land well before January 2027, which makes the practical deadline whichever of those comes first rather than the Microsoft date itself.

Which version of Windows Server should I move to from Windows Server 2016?

If the site is staying on a Windows server, Windows Server 2022 is the usual target: its extended support runs to October 14, 2031. Windows Server 2019 is generally not worth the move, because its extended support ends January 9, 2029 — close enough that you would be planning the next migration almost immediately.

The more useful question is whether the site needs a server at all. Moving to Azure App Service removes the operating system from your responsibility entirely, so there is no next end-of-support date to track. That is not always possible — App Service will not run COM components, installers or Windows services — but where it is, it ends the cycle rather than resetting it.

How do I find out which version of Windows Server my website is running on?

If you have Remote Desktop access to the server, running winver will report the version, and Server Manager shows the edition on its local server summary. If someone else hosts or manages the machine, the hosting provider or whoever originally set it up can tell you, and it is a reasonable thing to ask for in writing.

If nobody can answer the question, that is itself useful information. It usually means the server has been running unattended for years, which is exactly the situation where discovery is the largest part of a migration and the least safe thing to skip.

How long does a Windows Server 2016 migration take?

A straightforward ASP.NET site with a single SQL Server database is often one to three weeks. The variable that moves the timeline is not site size but how much undocumented server-level customization exists — custom IIS modules, COM components, ISAPI filters, or hardcoded paths. Discovery is usually the largest part of the work.

Running an IIS site on Windows Server 2016?

Thirty minutes, free, no obligation — bring your site address and whatever you know about the hosting.