Windows Server 2012 R2 gets its last updates on October 13, 2026 and 2016 on January 12, 2027: the per-server decision

Windows Server 2012 R2 left support in October 2023. Microsoft sold three years of paid Extended Security Updates after that, and the third year, the last one on offer, ends on October 13, 2026. A machine still running it after that date receives nothing.

Windows Server 2016 reaches the end of extended support on January 12, 2027. Microsoft has said paid Extended Security Updates will be offered for it for up to three years, with pricing to follow, so a bridge exists; it is a bridge priced to be walked across quickly, not a place to live.

For the sequence after that: Windows Server 2019 ends on January 9, 2029, Windows Server 2022 is in support until October 2031, and Windows Server 2025 until October 2034. SQL Server 2016 has already gone, on July 14, 2026, which matters because the database server is often the one that decides the operating system.

The server keeps running. What stops is the monthly fix for whatever is found next; attackers read the fixes for newer versions and try the same holes on the old ones, and from that Tuesday the old ones stay open.

The paperwork changes sooner than the risk does. Cyber-insurance questionnaires ask whether every operating system is in support, and an honest 'no' moves the premium or the coverage. A written security program of the kind Texas SB 2610 rewards expects supported software as a matter of course. And application vendors quietly stop testing on the old version, so the next update of the line-of-business system arrives with a note that it needs 2019 or later.

One row per server, before anyone chooses a method. The columns are the ones that decide the method:

• Role: domain controller, file server, print server, SQL, application, remote desktop, hypervisor host, or the box that does three of those
• The application that pins the version, and what its vendor says it supports today
• Hardware age and warranty, because a server replaced with its hardware is cheaper than one replaced twice
• What depends on it: service accounts, ODBC connections, mapped drives, scheduled tasks, scanners saving into a share, the copier's address book
• Backup state: when it last backed up, where the copy is, and when anyone last restored from it
• Who owns it, which is the column most often blank

In place. Windows Server 2025 supports an in-place upgrade from 2012 R2 and later, and for a simple member server with a supported application it is the cheapest route: an evening, a verified backup first, the vendor's blessing in writing. It is the wrong route for a server whose history nobody knows, because the upgrade carries the history with it.

Beside. A new server is built clean on the new version, the role moves across, the two run in parallel, and the old one is switched off but kept for a month. This is the right route for domain controllers, which should be replaced by promoting a new one and demoting the old rather than upgraded, and for file and print servers, which move well with the migration tools Windows ships. It costs more hours and produces a server somebody understands.

Gone. A surprising share of 2012 R2 machines exist to hold a share that could live in SharePoint, a print queue that Universal Print would replace, or an application that was retired two years ago. The inventory is where those come to light, and retiring one is the cheapest migration there is.

1. Hypervisor hosts first: a 2012 R2 Hyper-V host has to move before the machines on it can
2. Domain controllers next, and never as the last in-place upgrade of the day
3. The database server before the applications that use it, with the vendor's supported-version matrix open
4. Servers that coincide with a hardware refresh, so the migration and the replacement are one project
5. The application the vendor still pins to the old version last, on paid updates as a bridge, with a date on the bridge

A verified backup of the old machine and a restore test from it. A new virtual machine on the new version, patched and joined. The role migrated: shares copied with permissions intact, print queues exported and imported, the database moved and its logins recreated. A week of parallel running with the old name still answering. A cutover on a Friday evening, the DNS name pointed at the new machine, the old one shut down and kept. Then the write-up: what moved, what changed, and where the new server's documentation lives.

That last paragraph is the whole difference between a migration and a weekend. Our legacy modernization and migration page describes the parallel-run habit in more detail; the end-of-support table on the IT page holds the dates and is checked twice a year, and the server, virtualization, and backup work there is where these projects get done.