Remote Support Start download

Windows Server 2016 End-of-Life: Migration Options for SMBs

WindowsMigrationLinuxCompliance
Windows Server 2016 End-of-Life: Migration Options for SMBs

On 12 January 2027 extended support for Windows Server 2016 ends. From that day on, Microsoft will no longer ship security updates — neither via Windows Update nor via WSUS. For SMBs this means: anyone who misses the deadline runs production systems without patches, typically violating their own IT policy as well as GDPR, NIS2 and cyber insurance requirements.

The good news: there is more than one way forward. In practice we see three realistic migration paths, which we compare objectively here — including costs, effort and the typical pitfalls.

What exactly ends — and what does not

All editions of Windows Server 2016 (Standard, Datacenter, Essentials) are affected, as are the roles running on them: Active Directory Domain Services, DHCP, DNS, print services, IIS and Hyper-V hosts of that generation. The matching System Center 2016 also reaches end-of-life in early 2027.

Not affected, but often confused: Windows Server 2016 IoT (separate lifecycle), SQL Server 2016 (support already ended in 2026) and Exchange Server 2016, whose support ran out in 2025. If you are still running Exchange 2016 on-prem, you have a separate — and more urgent — problem.

In the next few months you should first do a full inventory: which VMs run on 2016? Which applications are tied to them? Which licences do you actually own (OEM, volume licence, Software Assurance)? Without that data, no serious migration decision is possible.

Option 1: In-place or side-by-side upgrade to Server 2022/2025

The obvious route leads to Windows Server 2025, available since November 2024 and supported until 2034 (mainstream) or 2039 (extended). Server 2022 is still a valid option but, from October 2031 onwards, only runs in extended support.

A direct in-place upgrade from 2016 to 2025 is not officially supported. You either go 2016 -> 2019 -> 2022 -> 2025, or — which we almost always recommend — set up clean installs as a side-by-side migration. For domain controllers, this is mandatory anyway: promote a new DC, transfer FSMO roles, demote the old DC.

Important for planning: Windows Server 2025 requires an AD functional level of at least 2016, but introduces new features like 32k database pages and improved Kerberos cryptography (AES SHA-256), which make a DFL lift to 2025 worthwhile — as soon as all DCs are migrated.

Option 2: Move workloads to Linux

Many roles historically running on Windows Server can be mapped to Linux cheaply and reliably. This saves licence costs and visibly reduces the patching effort. Typical candidates:

  • File and print services — Samba 4.20+ delivers SMB3 with multichannel, encryption and ACL-compatible shares.
  • Active Directory — Samba AD DC has been production-ready for years and supports FSMO roles, group policies and LDAP replication against Windows DCs.
  • Web services / reverse proxy — Nginx or Caddy replace IIS 1:1 in most cases.
  • DHCP/DNS — ISC Kea and BIND9 or dnsmasq are faster than the Windows stack in homogeneous networks.

Mixed operation also works: Samba DC as a second DC next to a Windows Server, with simultaneous LDAP replication. This lets you stretch migrations over several months. For the storage layer we typically deploy TrueNAS, which combines SMB shares with ZFS snapshots, replication and Active Directory integration.

# Example: join Samba 4.20 as a member server to an existing AD
sudo apt install samba winbind libpam-winbind libnss-winbind
sudo samba-tool domain join company.local MEMBER \
  -U "administrator" --realm=COMPANY.LOCAL
# Then extend nsswitch.conf with winbind and create kerberos.keytab

Option 3: Azure Extended Security Updates (ESU)

If you need to keep a specific application on 2016 — for example because the vendor never certified newer OS versions — you can buy ESU. After January 2027 you continue to receive security-relevant patches for up to three years.

There are two delivery models: ESU via Azure (free for VMs running in Azure or connected via Azure Arc, but only the patches — Azure infrastructure costs are separate) and on-prem ESU as a paid add-on via volume licensing. The latter is significantly more expensive and stops after year 3 at the latest.

ESU is a transition tool, not a strategy. Anyone who fails to use those three years for a real migration will face the same problem again in 2030 — with even less vendor-ecosystem momentum behind modernisation.

Cost comparison for a typical SMB site

Sample scenario: 3 physical hosts, 12 VMs on Server 2016, 50 users with AD integration, file and print services, 1 terminal server. The values are rough indicators (net, excluding migration services):

OptionLicence cost year 1Recurring cost/yearMigration effortLifecycle until
Upgrade to Server 2025 (Standard, 16 cores)approx. EUR 1,000 per hostpatches includedmedium (side-by-side)2034
Datacenter edition (>2 VMs/host)approx. EUR 6,300 per hostpatches includedmedium2034
Linux + Samba AD (e.g. Debian 13)EUR 0optional support EUR 300—800high (training, tooling)rolling
Azure ESU on-premapprox. 75% of current licence/yearrises annuallylow01/2030
Workload in Azure VM + free ESUcompute + storage per workloadcompute ongoingmedium01/2030

Pure licence costs are only part of the picture. Hardware (Server 2025 has higher minimum requirements), CALs, possibly new backup agents and the time spent on testing and rollout all add up. For realistic SMB projects we budget 8—25 person-days, depending on complexity.

Active Directory migration: pitfalls from the field

Regardless of which path you take, the AD migration is usually the trickiest part. Items that come up regularly in projects:

  • Check functional level — if the forest is still on 2008 R2 (not that rare), it must be lifted beforehand.
  • SYSVOL replication — if FRS is still active instead of DFSR, migrate before promoting the first new DC (dfsrmig).
  • DNS aliases and SPNs — renaming old servers easily breaks Kerberos tickets and file shares.
  • Group policies — import ADMX templates of the new OS into the central store, check old policies for compatibility.
  • Time sync — the PDC emulator needs a valid external time source, otherwise Kerberos fails.
  • Print server — a good moment to use the print migration wizard and clean up driver inventory.

For the parallel virtualisation layer, many customers also replace Hyper-V 2016 with Proxmox VE, which saves additional licence costs and offers elegant disaster recovery via ZFS replication.

Recommendation: decide now, migrate in Q3/Q4 2026

If you do not want to be cut off in January 2027, you should kick off the migration no later than the third quarter of 2026. The sequence we use in projects:

  1. Inventory and licence audit (1—2 weeks)
  2. Target architecture and decision on path 1/2/3 (workshop)
  3. Test migration in an isolated environment
  4. Production migration in waves, starting with non-critical services
  5. Demote/decommission the 2016 systems, recycle licences

With enough lead time, the EOL is not a drama — but rather a good opportunity to clear out organically grown structures, modernise backup and monitoring concepts and rethink licence costs.


DATAZONE supports SMBs in the Neuburg/Donau, Ingolstadt and Augsburg region with planning and execution of server migrations — from licence audit and AD modernisation to replacement by Linux-based services. Get in touch if you need a solid roadmap for your 2016 servers.

More on these topics:

Need IT consulting?

Contact us for a no-obligation consultation on Proxmox, OPNsense, TrueNAS and more.

Get in touch