How to Migrate Active Directory from Windows Server 2012 R2 to 2022

Windows Server 2012 R2 went out of support in October 2023, which means every domain still running it for Active Directory is overdue for a move. The good news is that migrating to Server 2022 isn’t a risky in-place upgrade or a forklift rebuild. You add a new 2022 domain controller alongside the old one, let them replicate, shift the important jobs over, and then retire the old box.

The order matters more than any single command. Done right, the migration is invisible to users — nobody notices that the DC answering their logon changed. Done in the wrong order, you can strand FSMO roles, break SYSVOL replication, or leave clients pointing at a DNS server that no longer exists.

This guide walks the whole path: prep checks, promoting the 2022 DC, transferring FSMO roles, raising functional levels, moving DNS and DHCP, and demoting the old 2012 R2 server cleanly. There’s also one prerequisite — FRS to DFSR — that will stop you cold if you skip it, so it comes first.

The migration at a glance#

The whole job is a side-by-side migration, not an upgrade. At no point do you upgrade the 2012 R2 operating system in place. Instead you run both DCs together for a while, then remove the old one.

flowchart TD
A["Health + FRS/DFSR check"] --> B["Promote Server 2022 DC"]
B --> C["Confirm replication + DNS"]
C --> D["Transfer FSMO roles"]
D --> E["Move DHCP to new server"]
E --> F["Repoint clients to new DNS"]
F --> G["Demote old 2012 R2 DC"]
G --> H["Raise functional levels"]

Before you touch anything: prerequisites#

Two checks decide whether this migration goes smoothly or stalls on day one. Run both before you build the new server.

Confirm SYSVOL is on DFSR, not FRS#

This is the big one. The old File Replication Service (FRS) was deprecated years ago and was removed entirely from Windows Server 2019 and 2022. If your domain still replicates SYSVOL with FRS — common in domains that were originally built on 2003 or 2008 and upgraded — a 2022 DC simply won’t replicate SYSVOL, and Group Policy will break.

Check the current state with dfsrmig:

dfsrmig /getglobalstate

If it reports “DFSR migration has not yet initialized” or anything other than the Eliminated state, you must complete the FRS-to-DFSR migration first. The migration runs in stages:

# Stage 1: Prepared
dfsrmig /setglobalstate 1
dfsrmig /getmigrationstate   # wait until all DCs reach Prepared

# Stage 2: Redirected
dfsrmig /setglobalstate 2
dfsrmig /getmigrationstate   # wait until all DCs reach Redirected

# Stage 3: Eliminated (point of no return for FRS)
dfsrmig /setglobalstate 3
dfsrmig /getmigrationstate   # wait until all DCs reach Eliminated

Let each stage finish replicating to every DC before moving to the next. When dfsrmig /getglobalstate finally reports Eliminated, SYSVOL is on DFSR and you’re clear to add a 2022 DC.

Check forest health and functional level#

Confirm replication is clean and note your current functional level. A migration is the worst time to discover a replication problem that’s been festering for months.

# Replication summary across all DCs
repadmin /replsummary

# Current functional levels
Get-ADDomain   | Format-List DomainMode
Get-ADForest   | Format-List ForestMode

Your domain and forest must be at Windows Server 2008 functional level or higher to add modern DCs. Almost every 2012 R2 domain already is. If repadmin /replsummary shows failures, fix them before going further — our guide on Active Directory replication error 1722 covers the most common cause.

Step 1: Promote the Server 2022 domain controller#

Build the new Server 2022 machine, patch it fully, give it a static IP, and set its preferred DNS server to an existing domain controller (not itself, yet). Then join it to the domain as a member server.

Install the AD DS role and promote it:

# Install the AD DS role binaries
Install-WindowsFeature AD-Domain-Services -IncludeManagementTools

# Promote this server to a domain controller in the existing domain
Install-ADDSDomainController `
  -DomainName "corp.local" `
  -InstallDns:$true `
  -Credential (Get-Credential) `
  -SafeModeAdministratorPassword (Read-Host -AsSecureString "DSRM password")

When you promote a 2022 DC into an older domain through this process, the schema and forest/domain prep (adprep /forestprep and /domainprep) run automatically. You don’t run adprep by hand unless you’re scripting a staged prep ahead of time.

After promotion and a reboot, verify the new DC is healthy and replicating:

dcdiag /v
repadmin /replsummary

Both should come back clean. If dcdiag flags DNS or SYSVOL issues, resolve them before moving any roles onto this server.

Step 2: Verify DNS replicated to the new DC#

If your DNS zones are Active Directory-integrated (the normal setup), promoting the new DC with -InstallDns:$true makes it a DNS server automatically, and the zones replicate to it as part of AD replication. Confirm the zones are actually there:

Get-DnsServerZone -ComputerName "DC02"

You should see your forward and reverse lookup zones listed, matching the old DC. Point the new DC’s own preferred DNS at itself now, and add the old DC as secondary. Getting DNS right on the new server before you move clients over is what keeps the migration invisible — see best DNS settings for domain controllers for the recommended client and DC resolver layout.

Step 3: Transfer the FSMO roles#

With the new DC replicating cleanly, move the five FSMO roles to it. Because both DCs are online, this is a graceful transfer, not a seizure. The fastest method is PowerShell:

# Move all five roles to the new DC (DC02)
Move-ADDirectoryServerOperationMasterRole `
  -Identity "DC02" `
  -OperationMasterRole SchemaMaster, DomainNamingMaster, RIDMaster, PDCEmulator, InfrastructureMaster

Confirm the roles landed where you expect:

netdom query fsmo

All five should now report the new 2022 DC. For the full breakdown of each role, the GUI method, and what to do if the old DC had already failed, see how to transfer or seize FSMO roles.

Step 4: Move DHCP to the new server#

If your old 2012 R2 DC also ran DHCP, move it now. DHCP doesn’t replicate through AD, so you migrate the configuration explicitly. Install the role on the new server first:

Install-WindowsFeature DHCP -IncludeManagementTools

Then export the full configuration from the old server and import it on the new one. The export carries scopes, reservations, options, and active leases:

# On the OLD server — export everything
Export-DhcpServer -ComputerName "DC01" -File "C:\dhcp-export.xml" -Leases -Force

# Copy the file to the new server, then on the NEW server — import
Import-DhcpServer -ComputerName "DC02" -File "C:\dhcp-export.xml" -BackupPath "C:\dhcpbackup" -Leases -Force

Authorize the new DHCP server in Active Directory so it’s allowed to lease addresses, and stop the old one from competing:

# Authorize the new server
Add-DhcpServerInDC -DnsName "DC02.corp.local" -IPAddress 10.0.0.12

# Unauthorize the old server so two servers don't hand out the same scope
Remove-DhcpServerInDC -DnsName "DC01.corp.local" -IPAddress 10.0.0.11

Step 5: Repoint clients to the new DNS server#

Clients and DHCP-issued options usually point at the old DC’s IP for DNS. Update them before the old server goes away:

• Update the DNS server option (006) in each DHCP scope to list the new DC first.
• Update any devices or servers with static DNS entries pointing at the old DC.
• Renew leases (or wait for the lease cycle) so clients pick up the new resolver.

This is the step that’s easy to forget and embarrassing to rediscover — a demoted DC’s IP still sitting in a scope option means clients try to resolve names against a server that no longer answers.

Step 6: Demote the old 2012 R2 domain controller#

Once the new DC owns DNS, DHCP, and all FSMO roles, and replication is clean, demote the old server gracefully. Don’t just shut it down.

# Run on the OLD 2012 R2 DC — graceful demotion
Uninstall-ADDSDomainController -DemoteOperationMasterRole -Credential (Get-Credential)

A graceful demotion removes the DC’s metadata from the directory, updates the replication topology, and cleans up most of its DNS records automatically. After it reboots as a member server, you can remove it from the domain and decommission the hardware.

Step 7: Raise the functional levels#

With every 2012 R2 DC gone, you can raise the domain and forest functional levels to unlock the newest features. There is no 2022 functional level — the highest available is Windows Server 2016, so that’s your target.

# Raise the domain first, then the forest
Set-ADDomainMode  -Identity "corp.local" -DomainMode Windows2016Domain
Set-ADForestMode  -Identity "corp.local" -ForestMode Windows2016Forest

Quick reference#

Wrapping up#

The migration from 2012 R2 to 2022 is really a sequence, not a single event: prove SYSVOL is on DFSR, promote the new DC, confirm it replicates, move FSMO and DNS and DHCP onto it, repoint your clients, then demote the old box and raise the functional level. Each step sets up the next, and the only true point of no return is raising the functional level at the end.

Take it one step at a time, verify with dcdiag and repadmin between stages, and keep that system state backup handy. If you build the new DC carefully and move the roles deliberately, your users will never know the domain controller under their logon changed at all.