Windows Server 2016 End of Support: January 2027

The date, and what it actually means

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.

January 2027 is currently about six months away. This is the comfortable end of that window.

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.

Frequently asked questions