Windows Server

Windows Server 2016 Domain Controllers: Migrate Before End of Support

Windows Server 2016 domain controller plan: why Microsoft prefers migration, the steps, cmdlets, rollback points and the mistakes that cause outages.

Published 06 November 2026

If any of your domain controllers still run Windows Server 2016, you have a short, well-defined job: add newer domain controllers, move the roles, retire the old ones. This guide covers that job end to end, with the cmdlets and admin tools Microsoft documents, a rollback point at each stage, and the mistakes that turn a routine change into an authentication outage. Sources checked 6 November 2026 against Microsoft Learn and Microsoft Lifecycle; they are listed at the end.

Verdict

Verdict: Migrate.

Microsoft recommends a clean install, promoting new domain controllers and demoting the old ones, over an in-place upgrade of an existing domain controller.

In-place upgrade is a documented path (Windows Server 2016 to 2019, 2022 or 2025), but a clean install gives you the Active Directory performance improvements of the newer version and leaves the old server untouched until you decide to demote it. That second point is the one that matters at 2 a.m.: with a side-by-side move, undoing the change is usually a matter of pointing clients back at a server that never stopped working.

Who this is for and what changes on the end-of-support date

This is for anyone who runs Active Directory Domain Services (AD DS) on Windows Server 2016, from a single-site office with two domain controllers to a multi-domain forest. It is also for anyone who inherited a forest and does not know which servers are domain controllers; step 1 fixes that.

Microsoft Lifecycle lists Windows Server 2016 under the Fixed Lifecycle Policy with mainstream support ended in January 2022. The Lifecycle table shows the extended support end as 1/13/2027 6:59:59 AM, while Microsoft's extended security updates page names 12 January 2027. Treat 12 January 2027 as the date to be finished by, not the date to start.

What changes for a domain controller on that date is simple to state and serious in effect. After extended support ends, Windows Server 2016 stops receiving security updates unless you enrol in Extended Security Updates (ESU). A domain controller holds every account, password hash and Group Policy object in the domain; it is the most valuable thing an attacker can compromise. Nothing stops working on the day. The risk is that the next critical vulnerability in Kerberos, Netlogon or LDAP has no fix for you.

On ESU, Microsoft's Azure Arc documentation says Windows Server 2016 reaches end of support on January 12, 2027, and that Extended Security Updates provide Critical and Important security updates for up to three years, through 2030, without new features, customer-requested nonsecurity hotfixes or design change requests. Arc-enabled ESU can be configured in the Azure portal from August 3, 2026, and its billing begins January 13, 2027. Standard and Datacenter editions are supported; physical-core licences need at least 16 cores per machine, and virtual-core licences need at least 8 per VM and use Standard. You must attest to Software Assurance or an equivalent server subscription, or license through SPLA. The pages I read show no price, so get a quote. Microsoft describes ESU generally as a last resort paid option and a temporary bridge, so treat it as a way to finish a migration, not as the plan.

Decision table

Option	What Microsoft documents	Fit for a domain controller
Stay and buy ESU	Azure Arc ESU: Critical and Important updates for up to three years, through 2030, billed from 13 January 2027; needs Software Assurance or an equivalent subscription	A temporary bridge, not a plan; no price is published on those pages, so get a quote
In-place upgrade	2016 to 2019, 2022 and 2025 are listed paths; you must run `adprep /forestprep` and `adprep /domainprep` manually	Supported but not preferred. Microsoft recommends clean install and demotion instead
Side-by-side migration	Promote new domain controllers on a newer Windows Server, move FSMO roles, demote the old ones	The recommended path. The old server remains a fallback until demotion
Move to Azure	Run domain controllers as Azure virtual machines in a virtual network connected to on-premises	Valid as a placement choice for new domain controllers; the process is the same promotion and demotion

A note on SaaS: there is no hosted option that simply takes over the domain controller role for existing domain-joined servers. Microsoft Entra Domain Services is a managed domain with a different feature set. Our comparison of Microsoft Entra Domain Services and self-managed AD DS covers that decision. This guide is about the case where you keep AD DS.

Steps, with the rollback point

Inventory the domain controllers. In an elevated PowerShell session as a Domain Admin, run Get-ADDomainController -Filter * to list every controller with its operating system, site and global catalog flag. Run Get-ADDomain | FL InfrastructureMaster, RIDMaster, PDCEmulator and Get-ADForest | FL DomainNamingMaster, SchemaMaster to find the FSMO role holders, as Microsoft's upgrade article does. Write them down.
Check health before you change anything. Run dcdiag /q on each controller and repadmin /replsummary for the forest. Fix replication errors first; a new controller joining an unhealthy forest inherits the problem. Confirm SYSVOL replicates with DFS Replication, not the older FRS: dfsrmig /getglobalstate reports the state. Microsoft describes the FRS to DFSR migration as one-way, so plan it as its own change if you are still on FRS.
Check functional levels and the schema. Windows Server 2019 and later need at least the Windows Server 2008 forest functional level, and no new functional levels have been added since Windows Server 2016. If your forest is already at the 2016 level, there is nothing to raise later. If any controller is older than the minimum, remove it first; setup blocks the install otherwise.
Take the backup that defines your rollback. Take a system state backup of at least two domain controllers, for example wbadmin start systemstatebackup -backupTarget:E: to a volume that is not on the controller. This is your last-resort recovery point, so confirm you can read it.
Build the new server and join it to the domain. Install a supported Windows Server, give it a static IP address, set DNS to point at existing domain controllers, and join it to the domain.
Promote it. Run Install-WindowsFeature AD-Domain-Services -IncludeManagementTools, then Install-ADDSDomainController -DomainName "corp.example.com" -InstallDns -Credential (Get-Credential). When you promote a server this way, or in Server Manager, adprep runs for you; you only run it by hand for an in-place upgrade. The account needs to be a Domain Admin to add a controller to an existing domain, and an Enterprise Admin to run adprep /rodcprep. Rollback point: the old controllers have not changed. If anything looks wrong, demote the new server and stop.
Verify the new controller before moving anything. Run dcdiag /q, repadmin /showrepl and nltest /dsgetdc:corp.example.com. Confirm net share shows SYSVOL and NETLOGON. Wait for at least one full replication cycle and check that Group Policy applies from it.
Move the FSMO roles. From the Active Directory module, run Move-ADDirectoryServerOperationMasterRole -Identity "DC-NEW" -OperationMasterRole 0,1,2,3,4, then confirm with Get-ADDomain and Get-ADForest. Rollback point: the same command moves the roles back, as long as both controllers are healthy. Do not seize roles for a planned move; seizing is for a controller that is gone for good.
Repoint everything that names a domain controller. This is the step that is not in Microsoft's article because it is specific to you. Update DNS client settings on servers, DHCP scope option 6, DNS forwarders and conditional forwarders, LDAP and LDAPS settings in applications, NPS and VPN, printers and scanners that bind to LDAP, Microsoft Entra Connect, and the time source (w32tm /query /source on the PDC emulator). Hard-coded names and IP addresses are what survive every inventory.
Run both side by side for a soak period. Leave the old controllers in service for long enough to cover your slowest process: month-end jobs, backup restores, the weekly report that nobody remembers. Rollback point: until demotion, you can fall back by pointing clients and moving roles back.
Demote the old controllers. Run Uninstall-ADDSDomainController, let it restart, then remove the role with Uninstall-WindowsFeature AD-Domain-Services. Microsoft warns that demotion cannot be halted or cancelled once it starts, and that removing the AD DS role with DISM is unsupported. Use -ForceRemoval only if the controller cannot reach the others, and then do metadata cleanup immediately.
Clean up. Remove stale DNS records and delegations, review sites and subnets, then raise functional levels if they are below the 2016 level. Microsoft notes you cannot lower a functional level once raised, with narrow exceptions, so do this last.

After demotion the old server is a member server and a plain Windows Server 2016 machine, with its own end-of-support date. Decommission it or rebuild it.

Mistakes that cause outages

Demoting before repointing. Servers, DHCP and applications that still name the old controller break the moment it leaves. Search DNS settings, not just the domain.
Skipping the health check. Promotion into a forest with failing replication or an old lingering object turns a two-hour job into a weekend.
Seizing roles that could have been moved. A seized role leaves the old controller unsafe to bring back online without cleanup.
Forced demotion without metadata cleanup. Microsoft warns that orphaned metadata is behind a significant share of AD DS, Exchange and SQL Server support cases.
Restoring a controller from an old snapshot or copying its disk. Domain controllers need consistent backups; follow Microsoft's backup and restore guidance rather than reverting a VM.
Forgetting Exchange. If Exchange is in the forest, check its support position before you place the Schema Master on Windows Server 2025. Microsoft's Exchange supportability matrix requires the November 2025 or later cumulative update on that server before any PrepareAD operation.

Checklist

Every domain controller identified, with FSMO holders and global catalog servers written down
Replication clean (repadmin /replsummary), dcdiag clean, SYSVOL on DFS Replication
System state backups of at least two controllers, restore tested or at least readable
New controllers promoted, verified and running through a soak period
FSMO roles moved and confirmed; DNS, DHCP, LDAP clients, NPS and Entra Connect repointed
Old controllers demoted cleanly, metadata checked, DNS cleaned
Functional levels reviewed last
Date set to finish before 12 January 2027, with the decision on ESU recorded if any server slips

Sources

Checked 6 November 2026.

Windows Server 2016 on Microsoft Lifecycle (Fixed Lifecycle Policy; extended end date)
Extended Security Updates for SQL Server and Windows Server (12 January 2027 milestone)
Prepare to deliver Extended Security Updates for Windows Server through Azure Arc (2016 dates, coverage, Software Assurance)
License provisioning guidelines for Extended Security Updates for Windows Server (editions, core minimums)
Billing service for Extended Security Updates for Windows Server through Azure Arc (billing start)
Product Lifecycle FAQ: Extended Security Updates (what ESU is, delivery options)
Upgrade domain controllers to a newer version of Windows Server (clean install recommended, adprep, FSMO move, functional levels)
Demote domain controllers and domains (Uninstall-ADDSDomainController, forced removal)
Plan your Windows Server upgrade path (supported in-place paths)
Upgrade and migrate roles and features (role matrix)
Migrate SYSVOL replication from FRS to DFS Replication
Deploy AD DS in an Azure virtual network
Exchange Server supportability matrix (Windows Server 2025 Schema Master note)

This is general planning information, not a design for your environment. Test in a lab or a quiet window first.