What’s a sensible way to replace five Server 2016 domain controllers?

I’d do this as a side-by-side migration, not an in-place upgrade. First check the domain’s current health and confirm whether SYSVOL uses DFSR or the older FRS method. Resolve any replication problems and complete the SYSVOL migration before adding new controllers if FRS is still in use.

Then add the new controllers one at a time, confirm they replicate and provide DNS correctly, and move FSMO roles once to a healthy new controller. Retire old controllers gradually, checking replication and client services at each step. Raise the functional level only after all controllers are on a supported version and you’ve verified the change is appropriate for the environment.

The part I’d spend the most time on is finding dependencies before removing anything. Search for systems configured with a specific controller’s IP or hostname, including DNS settings, LDAP integrations, RADIUS, certificates, DHCP, and scheduled jobs. Having more than one DNS server configured on clients helps, but it doesn’t catch every hard-coded reference.

There are two reasonable approaches to naming. Keeping old names or IPs may reduce changes in an environment with lots of fixed references, but reusing a domain controller’s identity can create cleanup and stale-record risks. New names are cleaner if you can update dependencies. Document the choice and test it rather than assuming either approach is universally safest.

Move Entra Connect off the domain controller as a separate, planned task. Set up a supported replacement and use the documented staging or swing migration process so you don’t end up with two active sync servers exporting changes at once. Confirm the sync configuration and operation before decommissioning the old host.

Also check what else is installed on the controllers. A domain controller is easier to replace when it is only doing directory and DNS work. If another service is tied to it, migrate that service on its own schedule.

Don’t forget time service when moving the PDC Emulator role. Check how the current PDC gets its time and make sure the new role holder will have the intended configuration. Otherwise a role transfer can expose an existing time issue across the domain.

For each new controller, verify replication and directory diagnostics before retiring an old one. Keep backups, but don’t treat a snapshot rollback as a substitute for a tested recovery plan for directory services.

For five controllers across two sites, replace them in small batches and keep a healthy controller available at each site throughout. Check site and subnet mappings, DNS registration, replication between sites, and that clients can locate an appropriate controller. A short shutdown period before final demotion can help reveal overlooked dependencies, but only do that with monitoring and a clear rollback plan.