Windows Server 2016 end of support: migrate to 2025, upgrade in place, or buy ESU?

Windows Server 2016 reaches end of extended support on 12 January 2027. After that date there are no more security updates without paying for them, and "we'll deal with it later" quietly becomes a compliance and insurance problem — an unpatched, out-of-support server is exactly what a NIS2 assessment or a cyber-insurance renewal flags. 2026 is the planning year, so here is the honest decision: the three real options, what each costs you, and how to pick.

The three options

There is no fourth. You either move to a supported OS, upgrade the one you have, or pay to keep the old one alive a while longer.

• •Clean migration to Windows Server 2025. Stand up new 2025 servers and move roles and data across. The most work, the best result: a clean, current, right-sized estate with no accumulated cruft. Windows Server 2025 went GA in November 2024, so it is the natural target.
• •In-place upgrade. Upgrade the existing server's OS without rebuilding it. Faster and cheaper up front, but it carries forward whatever configuration drift and old decisions the box already has, and the supported path is version-dependent — depending on the source version you may need to step up through an intermediate release (via 2019 or 2022) rather than assume a single leap straight to 2025, which means more reboots and more risk on a production box. Check the current in-place-upgrade matrix before you count on a direct hop.
• •Extended Security Updates (ESU). Pay Microsoft for security-only updates past end of support. This buys time, not a solution — it is a stopgap for a workload you genuinely cannot move yet (a legacy app pinned to the old OS), priced to make it a deliberately temporary choice.

How to choose

The decision is mostly about the applications on the server, not the server itself:

• •Migrate cleanly when the roles are portable (file, AD, print, web, SQL, Hyper-V) and you would rather not inherit ten years of drift — the common and usually right answer. It is also the moment to right-size and to consolidate onto fewer, better-specified hosts.
• •Upgrade in place when the box is a single well-understood role, the hardware is modern, and rebuilding it would cost more than it is worth — accepting that you carry the old configuration with you.
• •Buy ESU only for the workload that is genuinely stuck: a vendor application certified only on 2016, with no upgrade path available before January 2027. Pair it with an actual plan to retire that dependency, or you will be buying ESU again next year at a higher price.

What actually needs checking before you move

The surprises are never the OS; they are the things running on it.

• •Application compatibility. The line-of-business app pinned to an old .NET, the driver with no 2025 build, the agent (backup, AV, monitoring) that needs a new version. Inventory these first — they decide the whole project.
• •Active Directory. If this is a domain controller, functional levels, FSMO roles and replication need handling deliberately; a botched DC migration is a company-wide outage. The state your AD is actually in is usually worse than assumed — see what ten years of Active Directory contains.
• •Licensing. Windows Server 2025 is licensed per core (16-core minimum per server), and CALs must match the server version. Factor this into the "migrate vs ESU" maths honestly.
• •Backups and a rollback. A tested backup before any in-place upgrade, and a documented rollback, are non-negotiable — an in-place upgrade that fails halfway is the worst place to discover your restore does not work. This is the backup discipline every migration leans on.

Rehearse, then cut over

Whichever path, do not learn what breaks in production. Clone or snapshot the server, run the upgrade or the migration on the copy, and test the applications and integrations against it. Only when that rehearsal is boring do you schedule the real change into a maintenance window — with the backup taken and the rollback ready. For a clean migration, run old and new in parallel long enough to validate before decommissioning the old host.

What we do

We run Windows (and Linux) server estates as a managed service, and Server 2016 end-of-life is exactly the kind of deadline we plan against. We inventory the roles and the application dependencies, recommend migrate / in-place / ESU per workload on honest cost grounds, and do the work — the 2025 build, the AD handling, the licensing, and the cutover with a tested backup behind it. The goal is not just "off 2016 in time"; it is an estate that is supported, right-sized, and documented — so the next end-of-life is a calendar entry, not a scramble.