Windows Server 2016 Ends Support in January: A Migration Checklist

Windows Server 2016 is close to the end of its support life. As of October 23, 2026, BleepingComputer reports that Microsoft says the OS will stop receiving security updates when support ends in January 2027. This post gives you a plan: find every 2016 server, decide what happens to each one, and cover the exceptions.

Step 1: Find every Windows Server 2016 machine

You can't plan around servers you don't know about. Start with Active Directory, then check sources that don't depend on it.

Query Active Directory

This lists domain-joined computers that report a 2016 OS:

Get-ADComputer -Filter 'OperatingSystem -like "Windows Server 2016*"' -Properties OperatingSystem,OperatingSystemVersion,LastLogonDate |
  Select-Object Name,OperatingSystem,OperatingSystemVersion,LastLogonDate |
  Sort-Object LastLogonDate |
  Export-Csv .\ws2016.csv -NoTypeInformation

Sort by last logon. Machines that haven't authenticated in months are retirement candidates, but confirm before you delete anything.

Look beyond AD

AD misses workgroup servers, DMZ hosts, lab machines and anything with a stale computer object. Cross-check against:

• Hypervisor inventories (Hyper-V, VMware, Proxmox), including powered-off VMs and templates.
• Your patch management or endpoint management console.
• Vulnerability scanner results, which often fingerprint the OS without an agent.
• Cloud inventories for IaaS VMs running 2016 images.
• Backup catalogs, which tend to remember servers that everyone else forgot.
• Network scans for hosts that answer on SMB or RDP.

Record the OS build (2016 is build 14393), whether the server is physical or virtual, and whether it is Standard or Datacenter edition. Edition matters for licensing later.

Step 2: Record what each server does

For every server, write down:

• Role and installed features (AD DS, DNS, DHCP, file services, IIS, SQL Server, Hyper-V, RDS, and so on).
• The business owner and the technical owner.
• Applications that depend on it, and any vendor support statements about newer Windows versions.
• Whether it is internet-facing or holds regulated data.
• Maintenance windows and what an outage costs.

The owner and dependency columns are where most delays come from. Chase them early.

Step 3: Pick a path for each server

Every server lands in one of four buckets: upgrade in place, migrate to a new build, retire, or exception.

Upgrade in place

This suits simple, well-understood servers with vendor support for the target OS and a solid rollback option. Microsoft has supported upgrading across multiple Windows Server versions in one step, so a 2016 server can go straight to a newer release without stopping at 2019. Confirm the exact supported paths for your target version in Microsoft's documentation.

Before you start:

• Take a full backup and, for VMs, a checkpoint or snapshot you have tested restoring.
• Run Windows Update fully and reboot.
• Remove or update third-party agents (antivirus, backup, monitoring) that block setup.
• Rehearse on a clone of the VM first.

In-place upgrades are weaker for servers with years of configuration drift. If you wouldn't trust the install to rebuild cleanly, don't upgrade it.

Migrate to a fresh install

A clean build on a current OS is usually the better choice for important or messy servers. You get a clean baseline, and the old server stays untouched as an instant rollback. Common approaches by role:

• Domain controllers: Add new DCs on the current OS, verify replication, transfer FSMO roles, update DNS and DHCP references, demote the old DCs, then raise the functional level when no older DCs remain. Don't upgrade DCs in place unless you have a good reason.
• File servers: Storage Migration Service can copy data, shares and permissions and cut over the identity of the old server. Check that it supports your source and destination versions.
• Hyper-V hosts: For clusters, look at Cluster OS Rolling Upgrade. For standalone hosts, build new hosts and live migrate or export and import VMs. Plan to update VM configuration versions afterward, which is one-way.
• SQL Server, IIS and line-of-business apps: Treat these as application migrations. Test with the app owner, and check the vendor's compatibility matrix before you pick the target OS.

Retire

Plenty of 2016 servers exist only because nobody turned them off. For each candidate:

1. Confirm there is no traffic, logons or scheduled jobs that matter.
2. Power it off (a "scream test") for a set period, such as a few weeks.
3. Take a final backup and keep it for your retention period.
4. Then delete the VM, remove DNS records and AD objects, and free the license.

Exceptions

Some servers can't move by the deadline because of vendor lock-in, unsupported software or hardware dependencies. Treat these as a documented risk, not a quiet one (see below).

Step 4: Plan the target OS and licensing

Decide on one or two standard target versions so you don't create a new mess. Check each version's support lifecycle, and make sure hardware, hypervisor versions and your management tools support it. Confirm Client Access Licenses and core licensing with your licensing partner or Microsoft. Newer releases have their own CAL and edition rules, and you should not assume your current agreement covers them.

Step 5: Sequence the work

Order the work by risk and dependency:

1. Retire dead servers first. It shrinks the problem cheaply.
2. Move infrastructure services (DCs, DNS, DHCP, certificate services) early, since other servers depend on them.
3. Do simple in-place upgrades in batches.
4. Leave the complicated application servers for the time when you have the most testing capacity, but start their planning now.

Keep a tracker with owner, target, status, test result and cutover date. A shared spreadsheet is enough.

What to do for servers that must stay

After the end-of-support date, a server keeps running but gets no new security fixes. For the ones you can't move:

• Look into paid options. Microsoft has offered Extended Security Updates for earlier server releases, including special terms for Azure workloads. I could not confirm from the news I found whether or how ESUs will be offered for 2016, so check Microsoft's current announcement and pricing.
• Isolate it. Put it in its own VLAN or segment, deny inbound access except what the application needs, and block outbound internet access.
• Reduce exposure. Disable unused roles, services and protocols (SMBv1, legacy TLS versions), remove it from internet-facing paths, and put a reverse proxy or gateway in front of anything that must be reachable.
• Tighten access. Limit administrative accounts, require a jump host, and keep it out of broad admin groups.
• Monitor it. Send logs to your SIEM, run endpoint protection, and keep vulnerability scans going so you know what you are accepting.
• Keep tested backups. Make sure you can restore it, because it is now more likely to be the one that gets compromised.
• Document the exception. Record the owner, the reason, the compensating controls, and a firm date to revisit. Get a named person to accept the risk in writing.

Also check cyber insurance and compliance requirements. Some policies and frameworks treat unsupported operating systems as a finding.

Next step

This week, run the inventory query, cross-check it against your hypervisors and backup catalog, and sort the results into the four buckets. Even a rough first pass will show how big the job is and which servers need long lead time. Start the exception paperwork now, before the deadline arrives.