Windows Server 2012 R2: the last security updates end on 13 October 2026. What now?
Windows Server 2012 R2 ESU ends on 13 October 2026, in Azure too. Where to move, what usually blocks it, and what to do if you cannot move in time.
Vlado Pandžić · Founder · Senior .NET architect
Published · 5 min read
Contents
Regular support for Windows Server 2012 and 2012 R2 ended on 10 October 2023. Since then, many companies have kept those servers alive with Extended Security Updates (ESU), bought outright or received for free in Azure. That bridge ends on 13 October 2026. Microsoft offered ESU for a maximum of three years, and this is the end of it, in Azure as well.
The servers will keep starting. The applications on them will keep working. But from 14 October, every vulnerability found in Windows Server 2012 stays open, for good.
What changes on 14 October
| Until 13 October 2026 | From 14 October 2026 | |
|---|---|---|
| Security updates | Critical and important fixes, through ESU | None |
| In Azure | Free ESU | No updates either |
| New vulnerabilities | Patched | Stay open |
| Audits, insurers, customers asking about security | An answer exists: ESU | An unsupported operating system on the list |
Where to go, and where not
Do not move to Windows Server 2016. It loses support on 12 January 2027, and you would be doing this again in three months. Windows Server 2019 runs until 9 January 2029. The sensible targets:
| Target | Supported until |
|---|---|
| Windows Server 2022 | 14 October 2031 |
| Windows Server 2025 | 14 November 2034 |
There are three ways to get there:
- A new server, side by side. A new Windows Server 2022 or 2025 next to the old one, the applications moved over and tested, then the switch. The old server stays untouched until the new one has proven itself. This is what we do most often.
- An in-place upgrade. Windows Server 2025 can be upgraded directly from 2012 R2, skipping up to four versions. It is faster, but everything old moves along with it, and if something breaks, there is no old server to go back to. Test it on a copy first.
- Off the server altogether. A .NET web application or API can often move to Azure App Service or a container, and then the operating system is no longer your problem at all.
Our Windows Server end of support tool shows the dates for every version, with a countdown.
What usually blocks the move
Upgrading Windows is rarely the hard part. These are:
- Nobody knows exactly what runs on the server. A scheduled task that sends invoices at night, a service someone installed in 2015, a shared folder another system writes to.
- Old applications. Applications on .NET Framework 4.x usually run on the new Windows Server without changes. Very old ones, 32-bit components and old COM libraries need testing, and sometimes a migration to modern .NET.
- An old SQL Server on the same machine. SQL Server 2012 and 2014 are out of support too, so the database has to move as well. Our article on upgrading SQL Server 2016 shows a safe way to do it.
- Hard-coded server names and paths in applications and configuration files.
The order that works
- Step 1Inventory of the old server
- Step 2New server, side by side
- Step 3Move and test, one application at a time
- Step 4Switch, keep the old one switched off
The inventory takes an hour and prevents most surprises. Run this in PowerShell on the old server:
Get-WindowsFeature | Where-Object Installed
Get-ScheduledTask | Where-Object TaskPath -notlike '\Microsoft\*'
Get-Service | Where-Object StartType -eq 'Automatic'The first line shows the installed roles, the second the scheduled tasks someone created, and the third the services that start on their own. Every line on those lists needs an answer: does it move to the new server, or can it go?
After the switch, keep the old server switched off but intact for a few weeks. If something was missed, you will find out at the end of the month, when the monthly job does not run.
If you cannot move in time
From 14 October, an old server is a risk you manage, not a solution. Until it is replaced:
- Isolate it. No internet access, a firewall that lets through only the ports the application really needs, no administrator logins from it to other servers.
- Take it out of the domain if the application allows it, so a compromised old server is not a way into everything else.
- Watch it. Logins, open ports and changes, with an alert when something unusual happens.
- Set a date. Weeks, not years. Every month on an unpatched server makes the next vulnerability more likely to be the one that matters.
How long it takes
Rough ranges for moving to a new server:
- one server with one application: a few days, including testing
- several roles, scheduled tasks and a database: two to four weeks
- a server many systems depend on, where nobody is sure what talks to it: longer, and the inventory is half the work
The same situation is waiting for Windows Server 2016 in January 2027. If you have both, plan them together; our article on Windows Server 2016 end of support covers the rest.
Moving the application to Azure instead? See App Service, a virtual machine or containers.
How we work
This is exactly what we do. ProCoding is a .NET studio in Split, Croatia, and we move business applications off old servers: the inventory, a new server or Azure, moving and testing one application at a time, and keeping an eye on everything after the switch. The first step is a free 30-minute call.
Sources
- Overview of Extended Security Updates for Windows Server 2012 and 2012 R2, Microsoft Learn
- Windows Server 2022 lifecycle, Microsoft Learn
- Windows Server 2025 lifecycle, Microsoft Learn
This article is general information only, not legal, tax, financial or other professional advice. Scenarios, examples and calculations are illustrative. Terms of use and disclaimer.