Windows Server 2025 Migration — Planning Checklist and Gotchas

Windows Server 2025 has been out long enough now that “we’ll migrate eventually” isn’t really a plan anymore, especially with Windows Server 2012 R2 and 2016 both past or approaching end of extended support (a similar clock is ticking on the client side too — see our Windows 10 end of life planning guide). If you’re staring down a migration project, the good news is that the actual mechanics haven’t changed dramatically since Server 2019 or 2022 — but there are enough gotchas in the planning stage that a rushed migration will bite you later, and it’s worth checking Microsoft’s own system requirements for Windows Server 2025 before you order hardware. This is the checklist I actually use before touching a production domain controller.

Before You Touch Anything: Audit What You Actually Have

Every migration project I’ve seen go wrong started with an incomplete inventory. Before you plan anything, get a proper picture of your current estate:

• Run Get-ADDomainController -Filter * to list every DC, its OS version, and FSMO role holders.
• Check the current forest and domain functional levels with Get-ADForest and Get-ADDomain — Server 2025 needs at minimum Windows Server 2016 functional level to introduce new DCs cleanly.
• Inventory every service running on your current servers that isn’t AD itself — print servers, file shares, DHCP, WSUS, and especially anything running as a scheduled task nobody remembers setting up.
• Check firmware and hardware compatibility if you’re doing a physical-to-physical migration; Server 2025 has stricter Secure Boot and TPM expectations than 2019 did.

Plan the Order of Operations

The safest pattern is still the boring one: stand up new Server 2025 DCs alongside your existing ones, let replication settle, move FSMO roles deliberately, then decommission the old boxes once you’re confident. Don’t try to do this in a single maintenance window unless your environment is genuinely tiny.

A Realistic Sequence

1. Raise domain/forest functional level only after every remaining DC supports it — check this twice.
2. Promote at least one new Server 2025 DC per site, and verify AD replication with repadmin /replsummary before moving on.
3. Move FSMO roles one at a time with Move-ADDirectoryServerOperationMasterRole, verifying each one before touching the next.
4. Migrate DNS and DHCP roles — DHCP failover should be configured before you decommission the old scope holder, not after.
5. Update Group Policy Central Store and verify GPOs still apply correctly from the new DCs.
6. Decommission old DCs with Uninstall-ADDSDomainController, never just by turning the box off.

The Gotchas That Actually Bite People

1. SYSVOL Replication Method

If any of your existing DCs are still on the legacy FRS replication for SYSVOL (only really possible if you’ve been dragging an ancient domain along for a long time), you need to migrate to DFSR before you can introduce Server 2025 DCs cleanly. Check with dfsrmig /getglobalstate.

2. Licensing Confusion

Server 2025 licensing is still core-based, same as 2022, but double-check your Software Assurance status before assuming your existing agreement covers the new version outright — this trips up more people than the technical migration does.

3. Legacy Applications and SMB1

SMB1 is disabled by default and genuinely difficult to re-enable in some builds. If you have an ancient line-of-business app or a scanner/printer appliance that still needs SMB1, find that out in testing, not in production, on a Friday afternoon.

4. Hyper-V Version Requirements

If you’re virtualising your new DCs, make sure your existing hypervisor host actually supports Server 2025 guests before you start — older Hyper-V or VMware ESXi builds may need updates first. If you’re setting up Hyper-V from scratch, our Hyper-V on Windows Server 2025 setup guide covers it end to end.

Testing Before You Commit

Spin up a lab domain (even a throwaway Hyper-V lab) that mirrors your functional level and GPO structure. Test your actual line-of-business applications against it, not just “can I log in.” The migrations that go badly are almost never the AD/DNS parts — they’re the forgotten legacy app that assumed something about the old server that’s no longer true.

Frequently Asked Questions

Do I need to migrate all DCs at once?

No, and you shouldn’t. Run mixed-version DCs during the transition — that’s exactly what functional levels are designed to support.

Can I do an in-place upgrade instead of migrating to new hardware?

Microsoft supports in-place upgrades from Server 2022 to 2025, but for domain controllers specifically I’d still recommend a clean install-and-migrate approach. It gives you a rollback path that an in-place upgrade doesn’t.

How long should I keep the old DCs around after migration?

Once FSMO roles are moved and replication is confirmed healthy for at least a week, decommission properly rather than leaving old DCs powered off “just in case” — they become stale metadata problems if left too long.