I'm still surprised how often Windows Server 2016 turns up in real environments. Sometimes it's a domain controller everything depends on, sometimes an abandoned app server nobody dares to touch. Now the clock is running: extended support for Windows Server 2016 ends on January 12, 2027. After that date there are no more security updates unless you arrange ESUs. If you haven't taken stock yet, do it now. By autumn 2026 every organization should have a reliable picture of what's still left in its landscape.

The end of support turns Windows Server 2016 into a real risk

The "Windows Server 2016 end of support" isn't just a date on a calendar, it's a practical deadline. Once it passes, servers stay unpatched and become easy targets. Compliance is the other issue. Unsupported servers stick out right away in an audit, and even more so when they're domain controllers or file servers. Keep a close watch on any application that still runs on 2016, and check the official lifecycle page for the product and the Microsoft ESU overview regularly, because Microsoft occasionally adjusts terms or eligibility at short notice. For breaking changes, the Message Center and Azure Service Health are your best sources.

No migration plan works without a reliable inventory

Any modernization or migration plan worth the name starts with an inventory you can trust. In practice I rely on three tools: Microsoft Defender Vulnerability Management (if Defender for Servers is in place), Microsoft Configuration Manager (if it's still around), and more and more often Azure Arc. Arc has become the standard tool for listing servers, whether on-prem or in the cloud, with tagging and visibility in Azure Update Manager and Security Center. If you haven't rolled out Arc yet, have a look at my guide on securely onboarding and managing Azure Arc servers in practice. What matters is that the data is current, complete and carries lifecycle details (build, edition, roles such as domain controller).

This diagram shows the inventory and assessment workflow I usually recommend:

flowchart TD
    S1["Collect server inventory"] --> S2["Consolidate Arc/Defender/SCCM"]
    S2 --> S3["Map roles & workloads"]
    S3 --> S4["Mark blockers (legacy apps, DCs)"]
    S4 --> S5["Assess upgrade/migration paths"]

Figure: Recommended inventory and assessment workflow for Windows Server 2016.

Four options remain for every Windows Server 2016 machine

Once the inventory is complete, the decisions get a lot easier. Most Windows Server 2016 systems can be upgraded in place to Windows Server 2022 or to 2025, which is now generally available. In many cases, though, a fresh install plus a workload migration is the safer approach, particularly for domain controllers and legacy apps. Some workloads are awkward: old apps tied to specific builds, kernel drivers that break after 2019, DCs that have drifted for years. If that's where you're stuck, my recent post on the key Windows Server 2025 updates for hybrid admins may help.

Many organizations choose to migrate to Azure. As with earlier versions, Windows Server 2016 VMs in Azure qualify for free ESUs (according to the current announcement) as long as they stay in Azure. That means migrating first, and Azure Migrate or Site Recovery both work well for this. Ideally you also onboard the VMs to Azure Arc so you can manage ESUs centrally. For on-premises systems, ESUs are available through Azure Arc, much like the approach for Windows Server 2012/2019. Check the Azure Portal for current eligibility and terms every time.

Practical tip: Before I buy ESUs, I always check whether the workload could be migrated or retired instead. ESUs are a last resort. They cost money and, more importantly, they're a compromise on security.

Sometimes retiring the server is simply the right call. In that case, confirm that nobody really needs the app or service anymore and document the decision. That saves you surprises in later audits or business continuity discussions.

Old apps and domain controllers block most projects

These are the obstacles I run into most often around the "Windows Server 2016 end of support":

  • Legacy apps that just won't run on a newer Windows version
  • Domain controllers that are still on 2016
  • Business units that have no idea about forgotten servers
  • Dependencies nobody has mapped (databases, integrations, scheduled jobs)

Upgrading DCs usually involves raising the forest and domain levels, removing old DCs cleanly, and testing replication and backup. With applications, you need a staging environment, a few trial migrations and, now and then, some uncomfortable conversations with vendors.

Lifecycle management makes the next deadline much easier

The Windows Server 2016 end of support is just the next domino, and these cycles don't stop. Without a thorough inventory and the willingness to finally pay off technical debt, every modernization effort falls short. If you go the ESU route, have an exit plan ready and start preparing for the next wave as well (see Windows Server 2025). My advice is to standardize on Azure Arc for all your servers now. The next deadline will be far less painful.