If your domain controllers still run Windows Server 2016, what is your plan for the morning of January 13, 2027, when they stop receiving security updates? For many small and mid-sized businesses the honest answer is "we will get to it," usually because the server works fine and nobody wants to touch the system every login depends on. With the deadline now a matter of weeks away, that plan needs to be decided rather than deferred.
Windows Server 2016 end of life is a hard date: extended support ends January 12, 2027, and Microsoft's Windows release health message center states that the January 2027 security update will be the last one available for this version. After that, newly discovered vulnerabilities stay open unless you pay for Extended Security Updates or move off the platform.
The servers keep running, but Microsoft stops shipping security fixes, bug fixes, and support for them. For a domain controller, that means the system that authenticates every user, device, and application in your environment accumulates known, unpatched weaknesses month after month. The only supported ways to keep receiving fixes are paid Extended Security Updates for eligible editions or migration to a supported version.
Microsoft has made Extended Security Updates available, but with conditions that matter for small businesses. Microsoft's Windows Server and SQL Server end of support planning page says ESUs are available for three more years for workloads moved to Azure, while on premises, eligible customers with Software Assurance can buy them through Azure Arc on a pay-as-you-go subscription or as classic ESUs purchased through volume licensing in yearly increments. ESUs apply only to the Standard and Datacenter editions, and Microsoft's end of support notice for Windows Server 2016 Essentials is direct: ESUs are not available for Essentials at all, a common edition in smaller offices.
The common belief is that a domain controller is a low-risk server to leave alone: it does not run the website or the ERP, it just answers logins. We think that gets the risk exactly backwards. Because every other system trusts the domain controller, a single exploitable flaw on it is a path to everything, and that makes it the last server that should be running without patches.
There is a well-documented example. In 2020, the Netlogon vulnerability known as Zerologon (CVE-2020-1472) allowed an unauthenticated attacker with network access to a domain controller to completely compromise Active Directory identity services. CISA treated it as an emergency: Emergency Directive 20-04 ordered federal agencies to apply Microsoft's August 2020 update to every domain controller within weeks, or remove any that could not be patched from the network. The lesson for an SMB is simple. That fix arrived because the affected servers were supported. A domain controller past end of support, without ESUs, would simply have stayed exposed.
The same logic applies to cyber insurance and audits. Expect underwriters and auditors to ask whether critical systems run supported software, and an unsupported domain controller is a hard answer to defend on a renewal questionnaire. Our breakdown of what cyber insurance underwriters actually require covers how those questions are framed.
Because a domain controller holds the Active Directory database, replication, DNS, and Group Policy that every other system relies on, migrating one changes the foundation under all of them. The work involves functional levels, replication, role transfers, and compatibility with older applications and devices, and mistakes show up as users locked out of files, email, and line-of-business software.
Microsoft's own guidance is clear that the preferred path is not an in-place upgrade. Its article on upgrading domain controllers to a newer version of Windows Server recommends promoting new servers built from a clean install, transferring the FSMO roles to them, and then demoting the older domain controllers. In-place upgrades are technically supported, including directly from Windows Server 2016 to Windows Server 2025, but the clean side-by-side approach gives you a rollback path and avoids carrying a decade of configuration drift onto the new server.
Three issues come up repeatedly in older environments. The first is functional level: Microsoft's Active Directory functional level documentation states that Windows Server 2025 domain controllers are supported only at the Windows Server 2016 or 2025 forest and domain functional levels, so a domain still sitting at 2012 R2 level must be raised first, which in turn means retiring any older domain controllers. The second is SYSVOL replication: domains that were built long ago and never migrated from the deprecated File Replication Service to DFS Replication cannot promote Windows Server 2019 or later domain controllers until that migration is done.
The third is application and device compatibility. Microsoft's notes on what is new in Windows Server 2025 say that new Active Directory deployments require LDAP signing by default and that the Kerberos Key Distribution Center no longer issues ticket-granting tickets using RC4 encryption. Those are good security changes, but older copiers, scanners, line-of-business applications, and appliances that authenticate with legacy methods can break when they meet a new domain controller. Finding them before cutover is the difference between a quiet weekend and a Monday full of tickets. The same discipline applied during the Windows 10 transition, where we saw firms surprised by what happens to applications when support ends.
Most SMBs are choosing among four realistic paths. The right one depends on how many domain controllers you run, what edition and licensing you have, and whether you still need on-premises Active Directory at all.
| Option | Best fit | Main trade-off |
|---|---|---|
| New Windows Server 2025 domain controllers, then demote 2016 | Most SMBs with on-premises Active Directory | Requires prerequisite checks and compatibility testing, but is Microsoft's recommended path |
| In-place upgrade to Windows Server 2025 | Simple single-site domains on healthy, current hardware | Carries existing configuration and drift forward; harder to roll back |
| Extended Security Updates via Azure Arc | Standard or Datacenter servers with Software Assurance that cannot move in time | Ongoing monthly cost; a bridge for up to three years, not a destination; not available for Essentials |
| Move identity to the cloud and retire on-premises servers | Businesses already largely in Microsoft 365 with few on-premises applications | Larger project; older applications and file shares may still need a server |
Whatever you choose, look at what else lives on those servers. In small environments a 2016 domain controller often doubles as a file server, print server, or database host, and SQL Server 2016 has already left support: the same Microsoft end of support timeline shows SQL Server 2016 extended support ended July 14, 2026. Untangling those roles is usually the real scope of the project.
If you have not started, the goal is to make a decision and get the first new domain controller into production before the January deadline, with ESUs in reserve only for servers that genuinely cannot move in time. The sequence we use with clients looks like this:
The account cleanup step is worth more attention than it usually gets. Over a decade, domain controllers collect shared service accounts with standing administrator rights, and those are among the first things attackers look for. The same principle we apply to automation in our AI Lab article on why AI agents need their own identity rather than a shared service account applies to every scheduled task and integration in Active Directory. If you are also catching up on patch cadence, our look at CISA's newer patching expectations for small business IT is a useful companion.
We start with an Active Directory health and dependency assessment, so the migration plan is based on what your environment actually contains: functional levels, replication state, legacy authentication, and every role riding on the 2016 servers. From that, we schedule the new domain controllers, role transfers, and cutovers in windows that do not interrupt the business, with a tested rollback at each step.
For companies with their own IT staff, we often run the migration alongside the internal team, handling the domain controller and compatibility work while they own application testing; our view on what separates a co-managed IT partner from a ticket vendor explains how that split works. Where ESUs make sense as a bridge, we confirm eligibility and set an exit date so a temporary fix does not become permanent.
If any of your domain controllers still run Windows Server 2016, the most useful thing you can do now is confirm your edition, licensing, and functional level. Those three facts decide which path is open to you before January 12, 2027.
To see how we plan and run server migrations as part of ongoing managed IT, review Securafy's managed IT plans and features.
If you would rather talk through your specific environment first, book a strategy call with Securafy and we will walk through your Windows Server 2016 footprint, your options, and the fastest safe path off it.