# Domain Controller Migration Runbook: Add New DCs and Retire Old Ones

This is a plain-text copy of a guide published by Ellington Technologies, made for pasting into an AI assistant. It's generated from the same source file as the web page. If the two ever differ, the web page is correct: https://jeremiahellington.com/resources/domain-controller-migration-runbook

- Source (authoritative web version): https://jeremiahellington.com/resources/domain-controller-migration-runbook
- Author: Jeremiah Ellington
- Published: 2026-10-27
- Last updated: 2026-10-27
- Last reviewed: 2026-10-27
- Next scheduled review: 2027-04-30
- Applies to: Adding Windows Server 2022 or 2025 domain controllers to an existing single-domain Active Directory forest, then demoting the older DCs. Commands for Windows PowerShell 5.1 with the ActiveDirectory, ADDSDeployment, DnsServer and DhcpServer modules. Checked against Microsoft Learn on 2026-10-26; not tested on hardware.
- Who it's for: Administrators who already run an Active Directory domain and need to replace its domain controllers with new servers, one at a time, without downtime.
- Level: Advanced
- Before you start: Domain Admins membership, and Enterprise Admins for the forest-wide FSMO roles and the automatic schema update; A current, tested system-state backup of at least two existing DCs; A maintenance window and a written rollback plan for each phase; The new servers' names, static IPv4 addresses and AD site, decided in advance

A ten-phase checklist for adding new Windows Server domain controllers to an existing Active Directory domain, moving the FSMO roles, and retiring the old DCs safely.

---

This runbook is for replacing the domain controllers in an Active Directory domain you already run. You add new DCs alongside the old ones, prove they're healthy, move the FSMO roles, repoint everything that used the old DCs, and only then demote the old ones. Done in that order, nobody should notice.

It doesn't cover building a new forest from nothing, an in-place OS upgrade of an existing DC, read-only DCs, or multi-domain forests. Every name and address below is a made-up example: `corp.example.com` and addresses from the documentation ranges in RFC 5737. Swap in your own before you run anything.

> **Warning:**
> Every command here was checked against Microsoft's documentation on Microsoft Learn, but none has been run in a lab or on real servers for this page. Try each phase on a test domain first, and read each command before you paste it. Steps marked **Changes production** alter live systems.

## Before you start

### New forest or existing domain?

These are different jobs, and mixing their commands is a classic way to break things.

| You're doing | Cmdlet | This runbook? |
|---|---|---|
| Building a brand-new forest (first DC of a new domain) | `Install-ADDSForest` | No. That creates a new, separate directory. |
| Adding a DC to a domain that already exists | `Install-ADDSDomainController` | Yes |
| Removing a DC that isn't the last one in its domain | `Uninstall-ADDSDomainController` | Yes |

> **Caution:**
> If you see `Install-ADDSForest` or `-LastDomainControllerInDomain` in a migration script, stop. Neither belongs in a migration where the domain keeps running.

### Example names used on this page

| Placeholder | Meaning | Example |
|---|---|---|
| `corp.example.com` | Your AD DNS domain (also the forest root here) | `corp.example.com` |
| `DC=corp,DC=example,DC=com` | The same domain as a distinguished name | |
| `<OldDC>` | A DC you're retiring (repeat per DC) | `DC-OLD-01` at `192.0.2.10` |
| `<NewDC>` | A new DC you're adding (repeat per DC) | `DC-NEW-01` at `192.0.2.20` |
| `<Site>` | The AD site the new DC belongs to | `Default-First-Site-Name` |
| `<Gateway>` | The subnet's default gateway | `192.0.2.1` |

### How to read the steps

- **Where to run it** is in each code block's title. "Elevated" means an administrator Windows PowerShell 5.1 session. Some cmdlets used here (`Add-Computer`, `Test-ComputerSecureChannel`) aren't in PowerShell 7.
- Steps tagged **Changes production** in the checklists change directory, DNS, DHCP or server state. Each has a caution above it and, where the cmdlet supports it, a `-WhatIf` or test run first.
- Only commands checked against Microsoft's documentation appear in copyable code blocks. Emergency procedures (seizing roles, metadata cleanup) are described in text on purpose: read the linked article before you do either.
- Nothing on this page runs anything. Your ticks and notes stay in your browser, and they're only saved if you turn saving on above.

## Phase 1: Health baseline and safety net

Record a known-good state before you change anything, and make sure you can get back to it. If the domain isn't healthy now, fix that first: a new DC copies whatever problems the old ones have.

> **Important:**
> A DC backup is only usable for a limited time, the tombstone lifetime (180 days by default in forests created since Windows Server 2003 SP1). Take fresh system-state backups of at least two DCs, and know how you'd restore one, before Phase 4.

*Changes production: On each <OldDC>, elevated: system-state backup to a dedicated volume*

```powershell
Install-WindowsFeature Windows-Server-Backup
wbadmin start systemstatebackup -backupTarget:E:
```

*On each <OldDC>, elevated: full diagnostics saved to a file*

```powershell
New-Item -ItemType Directory -Path C:\Migration -ErrorAction SilentlyContinue
dcdiag /v /c /s:<OldDC> /f:C:\Migration\dcdiag_<OldDC>_baseline.txt
dcdiag /test:DNS /v /s:<OldDC>
dcdiag /test:Advertising /test:NetLogons /test:SysVolCheck /test:DFSREvent /s:<OldDC>
```

*From any domain-joined admin host, elevated: replication summary*

```powershell
repadmin /replsummary
repadmin /showrepl * /csv > C:\Migration\showrepl_baseline.csv
repadmin /queue
```

*On the PDC emulator, elevated: SYSVOL replication state*

```powershell
dfsrmig /getglobalstate
```

`dfsrmig /getglobalstate` should report the **Eliminated** state, which means SYSVOL already replicates with DFS Replication. Windows Server 2019 and later can't be added as DCs while the domain still uses FRS for SYSVOL. If yours does, migrate first with [Microsoft's SYSVOL migration guide](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr), and treat that as its own change: moving to Eliminated can't be undone.

*From an admin host with the ActiveDirectory module: inventory and levels*

```powershell
Get-ADDomainController -Filter * | Select-Object Name,IPv4Address,Site,OperationMasterRoles
Get-ADForest | Select-Object Name,ForestMode
Get-ADDomain | Select-Object DNSRoot,DomainMode
Get-SmbShare -CimSession <OldDC> -Name SYSVOL,NETLOGON
w32tm /monitor
```

Check the functional levels against the new DCs' OS. Per [Microsoft's functional-level table](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels), a Windows Server 2025 DC needs domain and forest functional levels of at least Windows Server 2016. Earlier releases accept some lower levels, so look up your exact combination in that table. If your levels are too low for the release you want, plan an intermediate step.

**Phase 1 checklist**

- [ ] System-state backups taken on at least two existing DCs, stored off the DC, and a restore procedure written down
- [ ] `dcdiag` baseline saved for every existing DC, and every failure explained or fixed
- [ ] `repadmin /replsummary` shows no failures and `repadmin /queue` is empty or draining
- [ ] `dfsrmig /getglobalstate` reports Eliminated (SYSVOL on DFSR)
- [ ] Forest and domain functional levels recorded and checked against the new DCs' OS
- [ ] Current DCs, their sites and their FSMO roles recorded
- [ ] `w32tm /monitor` shows the DCs in sync, with the PDC emulator using a reliable time source
- [ ] Started the dependency list for Phase 7: anything that points at an old DC by name or IP

## Phase 2: Build and patch the new servers

Build each new server with a supported Windows Server release, give it its final name, and patch it fully before it joins the domain. Server Core is a good fit for a DC.

*On each <NewDC>, elevated*

```powershell
Rename-Computer -NewName <NewDC> -Restart
```

Patch with whatever your organization already uses (WSUS, your update management tool, or Windows Update). On Server Core, `sconfig` option **6** (Install updates) installs quality updates. Repeat until no updates are offered, then reboot.

Set the time zone if it isn't right (`Get-TimeZone -ListAvailable` lists the IDs). Don't configure a separate time source on a DC that isn't the PDC emulator: members of the domain follow the domain hierarchy.

*On each <NewDC>, elevated*

```powershell
Set-TimeZone -Id "<Time zone ID>"
```

> **Note:**
> The source this runbook was adapted from used a community PowerShell module to install updates. It isn't a Microsoft module, so it's left out here. If you use it, review it as you would any third-party code on a server that's about to hold your directory.

**Phase 2 checklist**

- [ ] Each new server runs a supported Windows Server release that your functional levels allow
- [ ] Final computer name set, before the domain join
- [ ] Fully patched, rebooted, and no further updates offered
- [ ] Your normal server baseline applied (antivirus exclusions for AD, monitoring agent, backup agent)

## Phase 3: Static IP, DNS client and domain join

Point each new server at the existing DCs for DNS before it joins, so the join resolves the domain correctly.

*On each <NewDC>, elevated (example: 192.0.2.20/24)*

```powershell
New-NetIPAddress -InterfaceAlias "Ethernet" -IPAddress 192.0.2.20 -PrefixLength 24 -DefaultGateway 192.0.2.1
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.0.2.10,192.0.2.11
```

Adding a static address this way turns DHCP off on that interface. Run it at the console or through out-of-band access: if you're connected over the old address, you'll lose the session.

*On each <NewDC>, elevated, Windows PowerShell 5.1*

```powershell
Add-Computer -DomainName "corp.example.com" -Credential (Get-Credential) -Restart
```

*On each <NewDC> after the reboot (still a member server)*

```powershell
Test-ComputerSecureChannel -Verbose
nltest /dsgetdc:corp.example.com
```

**Phase 3 checklist**

- [ ] Static IPv4 address, prefix and gateway set, and reachable from the existing DCs
- [ ] DNS client points at existing healthy DCs
- [ ] Joined to the domain and rebooted
- [ ] `Test-ComputerSecureChannel` returns True and `nltest /dsgetdc` finds a DC

## Phase 4: Install AD DS and promote, one server at a time

Promote one server, let it replicate cleanly, and only then start the next. Run the prerequisite test with the same parameters first: it changes nothing and tells you what would fail.

> **Caution:**
> The first DC running a newer Windows Server release updates the forest schema and domain automatically (adprep). That's a forest-wide change you can't undo except by forest recovery. It needs Schema Admins, Enterprise Admins and Domain Admins, and it needs to reach the schema master and the infrastructure master. Make sure Phase 1's backups are current.

*On each <NewDC>, elevated*

```powershell
Install-WindowsFeature AD-Domain-Services,DNS -IncludeManagementTools
Import-Module ADDSDeployment
Test-ADDSDomainControllerInstallation -DomainName "corp.example.com" -SiteName "<Site>" -InstallDns:$true -Credential (Get-Credential) -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password")
```

*Changes production: on the same <NewDC>, elevated: promote (prompts before it reboots)*

```powershell
Install-ADDSDomainController -DomainName "corp.example.com" -SiteName "<Site>" -InstallDns:$true -Credential (Get-Credential) -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password")
```

The new DC is a global catalog by default. Store the DSRM password the way you store other break-glass credentials: you'll need it for a directory restore.

**Phase 4 checklist**

- [ ] `Test-ADDSDomainControllerInstallation` passed with the same parameters you'll promote with
- [ ] Promoted the first new DC and it rebooted (changes production)
- [ ] DSRM password stored with your other break-glass credentials
- [ ] Waited for Phase 5 and 6 checks to pass before promoting the next server

## Phase 5: Validate replication

Confirm each new DC is a healthy replication partner before you move on.

*From an admin host, elevated: against each <NewDC>*

```powershell
dcdiag /v /s:<NewDC>
repadmin /showrepl <NewDC>
repadmin /replsummary
repadmin /kcc <NewDC>
Get-ADReplicationPartnerMetadata -Target <NewDC> -Scope Server | Format-Table Partner,LastReplicationSuccess,LastReplicationResult -AutoSize
```

If you need to push a change out quickly, `repadmin /syncall <NewDC> /AdeP` synchronizes all partitions across all sites, pushing from that DC. It's safe, but it generates replication traffic across every site link.

**Phase 5 checklist**

- [ ] `dcdiag /v /s:<NewDC>` passes, or each failure is understood
- [ ] `repadmin /showrepl` shows successful inbound replication for every partition
- [ ] `LastReplicationResult` is 0 for every partner

## Phase 6: Confirm SYSVOL and NETLOGON

A DC can finish promotion but not yet share SYSVOL. Until it does, it can't hand out Group Policy or logon scripts, so check for this explicitly.

*From an admin host, elevated: against each <NewDC>*

```powershell
Get-SmbShare -CimSession <NewDC> -Name SYSVOL,NETLOGON
Test-Path "\\<NewDC>\SYSVOL"
Test-Path "\\<NewDC>\NETLOGON"
dcdiag /test:NetLogons /test:SysVolCheck /test:DFSREvent /s:<NewDC>
```

*From a host with the DFS Management tools (RSAT-DFS-Mgmt-Con)*

```powershell
Get-DfsrState -ComputerName <NewDC>
```

**Phase 6 checklist**

- [ ] SYSVOL and NETLOGON shares exist on each new DC
- [ ] `dcdiag` NetLogons, SysVolCheck and DFSREvent tests pass
- [ ] A test client receives Group Policy while pointed at the new DC

## Phase 7: Find and repoint everything that uses the old DCs

Do this before you move roles or demote anything. The usual surprises are DHCP's DNS option, DHCP relay on routers, static DNS settings on servers, LDAP binds in applications, RADIUS, backup software and monitoring.

> **Caution:**
> Export the DHCP configuration before you change it. Server-level options apply only where a scope doesn't set its own: check scope-level values too, or some clients keep the old DNS servers.

*On each DHCP server, elevated: read the DNS server option (6)*

```powershell
Export-DhcpServer -File C:\Migration\dhcp-before.xml -Leases
Get-DhcpServerv4OptionValue -OptionId 6
Get-DhcpServerv4Scope | ForEach-Object { Get-DhcpServerv4OptionValue -ScopeId $_.ScopeId -OptionId 6 -ErrorAction SilentlyContinue }
```

*Changes production: on each DHCP server, elevated: set the server-level DNS option (validates the servers)*

```powershell
Set-DhcpServerv4OptionValue -DnsServer 192.0.2.20,192.0.2.21 -WhatIf
Set-DhcpServerv4OptionValue -DnsServer 192.0.2.20,192.0.2.21
```

For each scope that sets its own option 6 (the read step above lists them), set it on the scope too:

*Changes production: on each DHCP server, elevated: set the DNS option on one scope (example scope 192.0.2.0)*

```powershell
Set-DhcpServerv4OptionValue -ScopeId 192.0.2.0 -DnsServer 192.0.2.20,192.0.2.21 -WhatIf
Set-DhcpServerv4OptionValue -ScopeId 192.0.2.0 -DnsServer 192.0.2.20,192.0.2.21
```

On routers and layer-3 switches, look for DHCP relay (helper) addresses that point at an old DC that also runs DHCP. Add the new relay address before you remove the old one, and save the configuration. The syntax depends on the vendor and OS version, so follow your platform's documentation.

*From an admin host: look for hard-coded names and addresses (example values)*

```powershell
Get-ChildItem -Path C:\Scripts -Recurse -Include *.ps1,*.psm1,*.config,*.ini | Select-String -SimpleMatch -Pattern "DC-OLD-01","192.0.2.10"
Get-DnsClientServerAddress -CimSession <host>
Resolve-DnsName corp.example.com -Type NS
```

For applications that bind to LDAP, check each one's settings for a DC name or address. Test LDAP and LDAPS reachability on each new DC (this only tests the TCP port, not the certificate):

*From an application server*

```powershell
389,636 | ForEach-Object { Test-NetConnection -ComputerName <NewDC> -Port $_ }
```

*On each <NewDC>: a certificate for LDAPS that names this DC*

```powershell
Get-ChildItem Cert:\LocalMachine\My | Where-Object { $_.DnsNameList.Unicode -contains "<NewDC>.corp.example.com" }
```

On an NPS server, `Get-NpsRadiusClient` lists the RADIUS clients (switches, wireless controllers, VPN) that send authentication there. NPS itself finds DCs through the domain, but check any client that was configured with an old DC's address directly.

**Phase 7 checklist**

- [ ] DHCP configuration exported before any change
- [ ] DHCP option 6 points at the new DCs at server level and in every scope that sets its own (changes production)
- [ ] Router and switch DHCP relay addresses updated, new one added before the old one removed, and saved (changes production)
- [ ] Servers and appliances with static DNS settings repointed
- [ ] Applications with LDAP binds, RADIUS clients, backup and monitoring checked and repointed
- [ ] Dependency list complete, with an owner and a test for each item

## Phase 8: Transfer the FSMO roles

Move all five operation master roles onto new DCs while the current holders are online. That's a transfer, the safe path, as long as you don't add `-Force`. Moving forest-wide roles (schema master, domain naming master) needs Enterprise Admins; the domain roles need Domain Admins.

*On any DC, elevated: current role holders*

```powershell
netdom query fsmo
```

> **Caution:**
> Never add `-Force` to the transfer command below "just to get it done". On that cmdlet, `-Force` means **seize**. Seizing is only for a role holder that's gone for good. If you seize the schema master, domain naming master or RID master, the old holder must never come back online as it was: rebuild it from scratch, don't restore it. Read [Microsoft's transfer-or-seize article](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/transfer-or-seize-operation-master-roles-in-ad-ds) before seizing anything.

*Changes production: from an admin host, elevated: graceful transfer (preview, then transfer; prompts to confirm)*

```powershell
Move-ADDirectoryServerOperationMasterRole -Identity "<NewDC>" -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster -WhatIf
Move-ADDirectoryServerOperationMasterRole -Identity "<NewDC>" -OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMaster
netdom query fsmo
```

You can split the roles across new DCs if that suits your sites. If not every DC is a global catalog and the AD Recycle Bin is off, keep the infrastructure master off a global catalog server. Once the PDC emulator moves, configure the new holder's external time source, and set the old one back to the domain hierarchy.

**Phase 8 checklist**

- [ ] Current role holders recorded
- [ ] All five roles transferred (not seized) to new DCs (changes production)
- [ ] `netdom query fsmo` shows only new DCs
- [ ] New PDC emulator syncs with your chosen external time source

## Phase 9: Demote the old DCs, one at a time

Demote one old DC, confirm the domain is still healthy, then do the next. Run the uninstall test first.

Before the first demotion, repoint each new DC's own DNS client. Phase 3 pointed the new DCs at the old DCs (`192.0.2.10`, `192.0.2.11`) so they could join the domain. If they still point only there, they lose name resolution when the old DCs go. List another new DC first and the DC's own address last:

> **Caution:**
> This changes the DC's own name resolution. Run it at the console or over a session that doesn't depend on DNS, and check that `Resolve-DnsName corp.example.com` still answers before you move on.

*Changes production: on DC-NEW-01 (192.0.2.20), elevated: other new DC first, then itself*

```powershell
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 192.0.2.21,192.0.2.20
Get-DnsClientServerAddress -InterfaceAlias "Ethernet" -AddressFamily IPv4
```

Microsoft's [DNS client recommendations](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings) say that after any change to a DC's DNS client settings you clear the resolver cache and register its DNS records. `ipconfig /flushdns` only empties this server's local resolver cache; it changes nothing on any DNS server. `ipconfig /registerdns` starts a dynamic registration of this server's DNS names and IP addresses, so it writes to the live zone.

> **Caution:**
> `ipconfig /registerdns` updates this DC's records in live DNS. Run it only after `Get-DnsClientServerAddress` shows the new servers and `Resolve-DnsName corp.example.com` answers.

*Changes production: on the same new DC, elevated: clear the local cache, then re-register its DNS records*

```powershell
ipconfig /flushdns
ipconfig /registerdns
```

Do the same on each new DC with its own addresses. Some admins use the loopback address (`127.0.0.1`) as the last entry instead of the DC's own address. Whichever you choose, test name resolution and a reboot on a test domain first: it hasn't been tested for this page.

> **Caution:**
> Demotion removes the server from the directory. Check that the DC holds no FSMO roles (Phase 8), that nothing still points at it (Phase 7), and that it isn't the last DNS server for any zone. Don't use `-ForceRemoval`, `-DemoteOperationMasterRole` or `-LastDomainControllerInDomain` here: they're for forced or last-DC removal, not a planned migration.

*Changes production: on the <OldDC> being retired, elevated (each prompts for a new local Administrator password)*

```powershell
Import-Module ADDSDeployment
Test-ADDSDomainControllerUninstallation -Credential (Get-Credential)
Uninstall-ADDSDomainController -Credential (Get-Credential)
```

After it reboots as a member server, remove the roles it no longer needs. If it also runs DHCP or file shares, leave those until they've moved.

> **Caution:**
> Removing the DNS role takes this server out of service as a DNS server. Confirm clients and forwarders no longer point to it.

*Changes production: on the same server after the reboot, elevated (restarts it)*

```powershell
Uninstall-WindowsFeature AD-Domain-Services,DNS -WhatIf
Uninstall-WindowsFeature AD-Domain-Services,DNS -Restart
```

*From an admin host: confirm it's gone before starting the next one*

```powershell
Get-ADDomainController -Filter * | Select-Object Name,Site
repadmin /replsummary
```

If an old DC is dead and can't demote itself, don't just leave it powered off: its metadata keeps it in the replication topology. Clean it up as described in [Microsoft's metadata cleanup article](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup). Deleting the DC's computer object in Active Directory Users and Computers does the cleanup; in Sites and Services, delete the NTDS Settings object before the server object.

**Phase 9 checklist**

- [ ] Every new DC's DNS client lists another new DC first and itself last, never only the old DCs; cache flushed and records re-registered (changes production)
- [ ] No FSMO roles on this DC, nothing pointing at it, and `Test-ADDSDomainControllerUninstallation` passed
- [ ] Demoted, rebooted as a member server (changes production)
- [ ] AD DS and DNS roles removed once nothing else depends on the server (changes production)
- [ ] `repadmin /replsummary` clean before demoting the next DC

## Phase 10: Clean up DNS and AD, then final checks

A clean demotion removes most of what it should. Look for leftovers, and remove them only after you've confirmed what they are.

*On a new DC, elevated: find records still naming an old DC (read-only)*

```powershell
Get-DnsServerResourceRecord -ZoneName "corp.example.com" | Where-Object { $_.HostName -like "*DC-OLD-01*" -or $_.RecordData.NameServer -like "DC-OLD-01.*" -or $_.RecordData.DomainName -like "DC-OLD-01.*" -or $_.RecordData.IPv4Address.IPAddressToString -eq "192.0.2.10" }
Get-DnsServerResourceRecord -ZoneName "_msdcs.corp.example.com" | Where-Object { $_.RecordData.HostNameAlias -like "DC-OLD-01.*" -or $_.RecordData.NameServer -like "DC-OLD-01.*" -or $_.RecordData.DomainName -like "DC-OLD-01.*" }
Get-ADObject -SearchBase "CN=Sites,CN=Configuration,DC=corp,DC=example,DC=com" -Filter 'Name -eq "DC-OLD-01"'
```

> **Caution:**
> Without `-RecordData`, `Remove-DnsServerResourceRecord` deletes **every** record with that name and type. If the server is still running as a member server, its own host A record (`DC-OLD-01`) is legitimate: leave it. The usual leftovers are the old DC's address on the domain's same-as-parent record (`@`) and on `DomainDnsZones` or `ForestDnsZones`. Run with `-WhatIf` first and leave off `-Force` so it asks before deleting.

*Changes production: on a new DC, elevated: remove one confirmed leftover, the old DC's address on the same-as-parent record (preview, then remove)*

```powershell
Remove-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "@" -RRType A -RecordData 192.0.2.10 -WhatIf
Remove-DnsServerResourceRecord -ZoneName "corp.example.com" -Name "@" -RRType A -RecordData 192.0.2.10
```

The demoted server's object under Sites and Services usually stays behind as an empty server object. Delete it in Active Directory Sites and Services once it has no NTDS Settings child.

Lingering objects are a separate problem, usually after a DC was offline longer than the tombstone lifetime. If replication logs event 1388 or 1988, see Microsoft's guidance on `repadmin /removelingeringobjects`, and run it with `/advisory_mode` first.

*From a client that gets its address by DHCP, at the console: final checks*

```powershell
nltest /sc_query:corp.example.com
Resolve-DnsName corp.example.com -Type NS -Server <NewDC>
ipconfig /all
389,636,88,445 | ForEach-Object { Test-NetConnection -ComputerName <NewDC> -Port $_ }
```

Renew the client's DHCP lease from its own console (renewing over a remote session drops it), then check `ipconfig /all` shows only the new DNS servers.

Once the old DCs are gone and stable, you can raise the domain and forest functional levels. Treat that as its own planned change: Microsoft describes raises as generally irreversible.

**Phase 10 checklist**

- [ ] Leftover DNS records reviewed, and only confirmed stale ones removed (changes production)
- [ ] Empty server objects removed from Sites and Services
- [ ] Clients get the new DNS servers by DHCP and log on, and Group Policy applies
- [ ] Every item on the dependency list tested against the new DCs
- [ ] New DCs are in the backup schedule, and a system-state backup of one has been taken
- [ ] Functional level raise planned as a separate change, if wanted

## Next steps

Keep the dependency list: it's the start of documentation for the next migration. Put the new DCs in monitoring and backups, and schedule a test restore.

---

## Sources and official documentation

- [Microsoft Learn: Active Directory Domain Services functional levels](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/active-directory-functional-levels)
- [Microsoft Learn: Upgrade domain controllers to a newer version of Windows Server](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/upgrade-domain-controllers)
- [Microsoft Learn: Migrate SYSVOL replication to DFS Replication](https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/migrate-sysvol-to-dfsr)
- [Microsoft Learn: Windows Server version 1709 and later no longer supports FRS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/windows-server-version-1709-no-longer-supports-frs)
- [Microsoft Learn: dcdiag](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dcdiag)
- [Microsoft Learn: dfsrmig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/dfsrmig)
- [Microsoft Learn: wbadmin start systemstatebackup](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/wbadmin-start-systemstatebackup)
- [Microsoft Learn: Install-ADDSDomainController](https://learn.microsoft.com/en-us/powershell/module/addsdeployment/install-addsdomaincontroller)
- [Microsoft Learn: Test-ADDSDomainControllerInstallation](https://learn.microsoft.com/en-us/powershell/module/addsdeployment/test-addsdomaincontrollerinstallation)
- [Microsoft Learn: Uninstall-ADDSDomainController](https://learn.microsoft.com/en-us/powershell/module/addsdeployment/uninstall-addsdomaincontroller)
- [Microsoft Learn: Test-ADDSDomainControllerUninstallation](https://learn.microsoft.com/en-us/powershell/module/addsdeployment/test-addsdomaincontrolleruninstallation)
- [Microsoft Learn: Transfer or seize Operation Master roles in AD DS](https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/transfer-or-seize-operation-master-roles-in-ad-ds)
- [Microsoft Learn: Move-ADDirectoryServerOperationMasterRole](https://learn.microsoft.com/en-us/powershell/module/activedirectory/move-addirectoryserveroperationmasterrole)
- [Microsoft Learn: Clean up Active Directory domain controller server metadata](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/deploy/ad-ds-metadata-cleanup)
- [Microsoft Learn: Remove-DnsServerResourceRecord](https://learn.microsoft.com/en-us/powershell/module/dnsserver/remove-dnsserverresourcerecord)
- [Microsoft Learn: Set-DhcpServerv4OptionValue](https://learn.microsoft.com/en-us/powershell/module/dhcpserver/set-dhcpserverv4optionvalue)
- [Microsoft Learn: Recommendations for DNS client settings (KB 825036)](https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/best-practices-for-dns-client-settings)
- [Microsoft Learn: ipconfig](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/ipconfig)
- [Microsoft Learn: Test-NetConnection](https://learn.microsoft.com/en-us/powershell/module/nettcpip/test-netconnection)
- [Microsoft Learn: Server Core SConfig](https://learn.microsoft.com/en-us/windows-server/administration/server-core/server-core-sconfig)
- [RFC 5737: IPv4 address blocks reserved for documentation](https://www.rfc-editor.org/rfc/rfc5737)

## Review history

- Technical review: Jeremiah Ellington, 2026-10-27
- Editorial review: Jeremiah Ellington, 2026-10-27