Replace the domain controller instead of upgrading its operating system
The most predictable way to migrate a Windows Server 2016 domain controller is to install a new Windows Server 2025 machine, promote it into the existing domain, validate replication, transfer the required roles, and gracefully demote the old server. Microsoft recommends this clean-install approach over an in-place AD DS upgrade.
This guide is specifically about domain controllers. It complements the broader Windows Server 2016 exit plan without pretending to automatically migrate other roles the old server may host: DNS, DHCP, NPS, certificate services, Microsoft Entra Connect, file shares, or vendor applications each require their own procedure.
Do not start by transferring FSMO roles. Begin with a healthy directory, a recoverable backup, and an inventory of dependencies. Adding a 2025 controller to an unhealthy forest does not fix replication; it creates another copy of the same problems.
Target architecture and success criteria
Avoid placing every new DC on one host, storage array, or failure domain. In a small environment, two properly separated and backed-up DCs are more useful than many identical copies with no recovery plan.
| Area | Decision to document | Success criterion |
|---|---|---|
| Resilience | At least two writable DCs across relevant failure domains | One DC failure does not stop DNS or authentication |
| DNS | AD-integrated zones, forwarders, aging, and delegations | SRV records present and internal/external resolution validated |
| Global Catalog | GC in every site that needs it | Sign-in and forest-wide lookup tested |
| Replication | Subnets, sites, links, and source partner | No unexplained repadmin or dcdiag failure |
| FSMO and time | Five role holders and forest-root PDC NTP source | Roles confirmed and time hierarchy stable |
| Recovery | System-state backup and forest recovery procedure | Documented restore evidence, not only a green job |
1. Check functional levels and SYSVOL
A Windows Server 2025 domain controller is supported at Windows Server 2016 or Windows Server 2025 forest and domain functional levels. If the environment is still at 2012 R2, first remove incompatible DCs and raise the levels to 2016. The 2025 functional level is not required to introduce a 2025 DC.
Keep the 2016 functional level during coexistence: it supports 2016, 2019, 2022, and 2025 DCs. The 2025 level requires every DC in the domain and forest to run Windows Server 2025. Enable it as a separate change after migration and observation.
SYSVOL must use DFS Replication. Promotion is blocked in legacy domains still using FRS. The expected dfsrmig /getglobalstate value is Eliminated, and every DC must have reached that state. An FRS-to-DFSR migration is a prerequisite project, not an improvised promotion step.
Import-Module ActiveDirectory
Get-ADForest | Select-Object Name,ForestMode,SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object DNSRoot,DomainMode,PDCEmulator,RIDMaster,InfrastructureMaster
$schema = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schema -Property objectVersion | Select-Object objectVersion
dfsrmig /getglobalstate
dfsrmig /getmigrationstate
Get-SmbShare -Name SYSVOL,NETLOGON2. Capture a health baseline before the change
Run checks from an administrative workstation or a healthy DC and preserve the output before and after migration. An old, understood warning may be acceptable; a replication, DNS, SYSVOL, or DC advertising failure must be fixed before adding the server.
Repadmin exposes replication partners and errors. Dcdiag tests domain-controller services, DNS, SYSVOL and NETLOGON shares, and several dependencies. Add the Directory Service, DNS Server, DFS Replication, and System logs plus your monitoring alerts.
New-Item C:\Temp\AD-Migration -ItemType Directory -Force
repadmin /replsummary > C:\Temp\AD-Migration\replication-summary.txt
repadmin /showrepl * /csv > C:\Temp\AD-Migration\showrepl.csv
dcdiag /e /c /v /f:C:\Temp\AD-Migration\dcdiag-all.txt
dcdiag /e /test:DNS /v /f:C:\Temp\AD-Migration\dcdiag-dns.txt
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.<domain.example>
Resolve-DnsName -Type SRV _kerberos._tcp.<domain.example>Get-ADDomainController -Filter * | Sort-Object Site,HostName |
Select-Object HostName,IPv4Address,Site,OperatingSystem,
IsGlobalCatalog,IsReadOnly | Format-Table -AutoSize
Get-ADReplicationFailure -Target * -Scope Forest |
Select-Object Server,FirstFailureTime,FailureCount,LastError3. Inventory dependencies on the old DC
Do not immediately reuse the same name or IP to hide dependencies. That makes rollback harder and masks stale references. Correcting consumers to use the domain, SRV records, or multiple servers creates a more resilient architecture.
If the old DC hosts certificate services, NPS, DHCP, or Entra Connect, migrate that role with its own official documentation before demotion. AD DS replication does not move those configurations automatically.
- Applications, printers, NAS devices, and firewalls pointing to its IP for LDAP, LDAPS, Kerberos, or DNS.
- LDAPS certificates, alternate names, trust chain, and automated renewal.
- DHCP scopes and DNS options, static network settings, and conditional forwarders.
- NPS/RADIUS, DHCP, AD CS, Microsoft Entra Connect, backup, EDR, monitoring, and log collection.
- Scripts, scheduled tasks, administrative shares, or applications installed directly on the DC.
- Inter-site firewall rules for DNS, Kerberos, LDAP, SMB, RPC Endpoint Mapper, and dynamic RPC ports.
- FSMO roles, Global Catalog, sites/subnets, connection objects, and time source.
4. Back up before changing the schema
Take a recent system-state backup of at least one healthy writable DC per domain according to the forest recovery plan. Verify destination, retention, and actual restore capability. A hypervisor snapshot is not a replacement for an AD DS backup and tested recovery procedure.
Promotion of the first 2025 DC prepares the schema and domain automatically when the account has the required rights. For the first instance in the forest, Microsoft requires Enterprise Admins, Schema Admins, and Domain Admins in the schema master's domain. Use a temporary privileged account and remove those memberships afterward.
wbadmin start systemstatebackup -backuptarget:E: -quiet
wbadmin get versions5. Prepare the new Windows Server 2025 machine
Join the server as a member and restart it. Its network adapter must query an existing Active Directory DNS server, not public DNS. After promotion and DNS replication validation, configure a consistent local/peer DNS combination according to your standard; avoid making a new DC depend only on itself before it is healthy.
- Install supported cumulative updates and integration drivers or tools.
- Assign the final name, static IP, and correct VLAN; use an existing AD DNS server while joining.
- Create or verify the subnet and its site in Active Directory Sites and Services before promotion.
- Apply security, EDR, backup, and monitoring policies compatible with a domain controller.
- Avoid installing business applications or unnecessary roles on the new DC.
- Confirm bidirectional connectivity with expected replication partners.
6. Install AD DS and promote the new controller
Promote through Server Manager or ADDSDeployment. Explicitly set the site, DNS, and Global Catalog. Select a healthy replication source when topology or bandwidth warrants it. The DSRM password must be unique, stored in a vault, and retrievable during an incident.
Test-ADDSDomainControllerInstallation runs prerequisite checks without promotion. Read each warning instead of automatically converting the command into deployment. Promotion restarts the server.
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
$domain = 'corp.example'
$site = 'Montreal-HQ'
$dsrm = Read-Host 'DSRM password' -AsSecureString
Test-ADDSDomainControllerInstallation `
-DomainName $domain -InstallDns -SiteName $site `
-Credential (Get-Credential)
Install-ADDSDomainController `
-DomainName $domain -InstallDns:$true -SiteName $site `
-NoGlobalCatalog:$false -Credential (Get-Credential) `
-SafeModeAdministratorPassword $dsrm7. Validate the new DC before transferring anything
Wait for initial replication to finish. Verify every partition: domain, configuration, schema, and DNS application partitions. SYSVOL and NETLOGON must be shared, the DC must advertise in DNS, and the DFS Replication log must not indicate incomplete initialization.
Test from multiple subnets: sign-in, Group Policy, DNS resolution, password change, Kerberos, and LDAP/LDAPS where used. A local test on the DC does not prove that inter-site firewalls and DC Locator work.
repadmin /showrepl <DC2025>
repadmin /replsummary
dcdiag /s:<DC2025> /test:Advertising /test:Services /test:Replications /v
dcdiag /s:<DC2025> /test:SysVolCheck /test:NetLogons /test:DNS /v
Get-SmbShare -CimSession <DC2025> -Name SYSVOL,NETLOGON
Resolve-DnsName -Type SRV _ldap._tcp.dc._msdcs.<domain.example>
Get-ADDomainController -Identity <DC2025> |
Select-Object HostName,Site,IsGlobalCatalog,OperationMasterRoles$since = (Get-Date).AddHours(-24)
'Directory Service','DNS Server','DFS Replication','System' | ForEach-Object {
Get-WinEvent -ComputerName <DC2025> -FilterHashtable @{
LogName=$_; StartTime=$since; Level=1,2
} -ErrorAction SilentlyContinue
} | Select-Object TimeCreated,LogName,Id,LevelDisplayName,Message8. Transfer FSMO roles and verify time service
Transfer roles only after several successful replication cycles. Small domains can place all five roles on one DC; larger designs may distribute them. Planned migration uses a normal transfer. Force seizes a role when the old holder is permanently unavailable and must never return without remediation.
If the forest-root PDC Emulator moves, immediately verify W32Time. The root PDC should use the authorized NTP source; other DCs and members normally follow the domain hierarchy. Do not blindly copy an old registry configuration without comparing it to the current standard.
$target = '<DC2025>'
Move-ADDirectoryServerOperationMasterRole -Identity $target `
-OperationMasterRole SchemaMaster,DomainNamingMaster,`
PDCEmulator,RIDMaster,InfrastructureMaster
Get-ADForest | Select-Object SchemaMaster,DomainNamingMaster
Get-ADDomain | Select-Object PDCEmulator,RIDMaster,InfrastructureMaster
w32tm /query /source
w32tm /query /status
w32tm /query /configuration9. Redirect dependencies and observe
Update DHCP options, static DNS configurations, LDAP applications, certificates, firewall rules, backups, monitoring, and log collectors. Confirm that clients discover the new DC through SRV records and that no critical flow still relies on the old address.
Keep the old DC online for an observation period that covers business cycles: nightly processing, payroll, backups, monthly applications, and site failover. A week may be enough for a small simple environment; it is not enough when integrations run only at month end.
- Monitor Kerberos, Netlogon, LDAP, DNS, and replication errors.
- Compare DNS queries and authentication traffic reaching old and new DCs.
- Test a controlled restart or temporary old-DC outage where risk permits.
- Obtain business test sign-off and retain the evidence.
10. Gracefully demote Windows Server 2016
Before demotion, confirm that the old DC no longer carries required FSMO roles, other servers provide DNS and Global Catalog, dependencies were moved, and replication is healthy. Use Server Manager or Uninstall-ADDSDomainController; never remove AD DS with DISM while the server is still a domain controller.
Forced demotion is a last resort when the DC cannot contact any peer. It leaves orphaned metadata and loses unreplicated changes, so immediate metadata cleanup is mandatory. In a normal migration, any need to force is a stop-and-investigate signal.
Get-ADDomainController -Identity <DC2016> |
Select-Object HostName,IsGlobalCatalog,OperationMasterRoles
repadmin /showrepl <DC2016>
repadmin /replsummary
# Prompts for the local Administrator password and validation.
Uninstall-ADDSDomainController11. Clean up, validate, and separate the 2025 functional level
Do not raise the 2025 functional level in the same window as the final demotion. It excludes 2016, 2019, and 2022 DCs and enables 2025-specific capabilities, including optional 32K database pages. Treat it as a separate change based on a real requirement.
Migration ends when the environment is operable and recoverable, not when the old server is off. Keep before/after reports, backup evidence, test results, and the retirement decision.
- Verify removal of the old NTDS Settings and expected server object in Sites and Services.
- Remove old DNS records only after confirming they are actually stale.
- Rerun repadmin, dcdiag, DNS, and SYSVOL tests across every DC.
- Update documentation, CMDB, diagrams, backups, and emergency procedures.
- Remove temporary privileged memberships used for Adprep and promotion.
- Keep a stability period before considering the Windows Server 2025 functional level.
A realistic rollback plan
Temporary coexistence is the best rollback: while the old DC is healthy, replicated, and not demoted, roles and dependencies can be moved back cleanly. After demotion, recovery depends on the remaining controllers and forest recovery plan—not an improvised snapshot.
| Point | Available rollback | Limit |
|---|---|---|
| Before promotion | Fix the server or postpone | No AD DS change if Adprep did not run |
| After promotion | Gracefully demote the new DC | Schema updates are not uninstalled |
| After FSMO transfer | Transfer back to a healthy old DC | Never bring a seized former holder back untreated |
| After 2016 demotion | Use remaining DCs and the recovery plan | Do not restore an arbitrary old VM as rollback |
| After 2025 functional level | Use only documented lowering options | Treat it as a separate change |
A DC migration is also an AD maturity test
The technical path is short; inventory and validation determine project quality. Failures often come from a forgotten DNS zone, a device with a hard-coded IP, SYSVOL still using FRS, or a secondary role installed on the DC without an owner.
This procedure is an execution guide, not a substitute for an Active Directory assessment. An assessment also puts delegation, privileged accounts, legacy protocols, AD CS, backups, attack paths, and real recovery capability into context.