You are upgrading domain controllers. Two of them also run Windows DHCP in a failover load-balance pair. You want to keep hostnames and IPs for the new DCs. Someone asks: move DHCP first?
Yes. Move DHCP first.
DHCP on a DC is convenient until the weekend you rebuild that DC. Then every scope, every reservation, and the failover relationship sit on the box you are about to replace. Separate the services before you touch AD.
This note is the operator path: break the pair cleanly, park scopes on a temporary Windows DHCP host (or dedicated pair), finish the DC work, then either put DHCP back on the new DCs or leave it off them for good. Lattice framing at the end — honest about what we are not.
Sibling dump for scopes and reservations: Dump Windows DHCP scopes. Why one catalog beats scope + sheet: Why switch off Windows DHCP and the spreadsheet. Product path: Replace Windows DHCP.
Why DHCP on a DC bites during migration
Failover load-balance on two DCs works until you need to:
- Rebuild both partners for a 2016 → 2022 (or 2025) OS upgrade while keeping the same names and IPs
- Stage more than a handful of scopes without a big-bang weekend
- Update relays once, not twice mid-upgrade
Microsoft DHCP failover is a hashed pair / partner relationship — not “same pool on every node.” Discover on A and Ack on B is a problem in that model if the partnership is wrong; it is the design only when the pair is healthy (Replace Windows DHCP).
PowerShell backup and export jobs have their own sharp edges on a live pair (scope deactivation that replicates to the partner is a known operator war story). Prefer documented export/import over improvising replication mid-cut.
Sanity-check sequence (temp park)
For a small or mid estate where you are keeping Windows DHCP for now:
- Inventory. List scopes, reservations, exclusions, server/scope options, failover relationship name, partner, mode (load-balance vs hot-standby), and which relays point where. Write it down outside MMC.
- Backup. GUI backup of each DHCP server, plus
Export-DhcpServerto XML if you want a full dump for your records. Confirm what your Server version’s cmdlets accept — do not invent switches. - Break failover. Remove the failover relationship on purpose, on both sides, during a window. Do not leave a half-pair.
- Stand up the park. Temporary Windows DHCP host (or two if you need HA during the park). Same subnet reachability the relays need. Authorize in AD if your forest requires it.
- Export → import scopes. Move scopes and reservations to the temp host. Prefer one scope (or one site) at a time if you have dozens. Update
ip helper-address/ DHCP relay to the temp host before you deactivate the old scope. - Validate. Client renew on a test VLAN. Printers with reservations. Helpdesk “what IP is this MAC” still answers from the park.
- DC upgrade. Rebuild / replace DCs. Keep AD. DHCP is no longer on those boxes.
- Decide the landing.
- Back onto new DCs: export from temp → import to new_DC01 → re-establish failover with new_DC02 → point relays back.
- Off DCs for good: leave the park as dedicated DHCP VMs, or start a Lattice cutover (below).
At small user counts, do not invent two extra DHCP boxes “for HA theater” if you already had a working pair — keep one clear HA story, not three.
Large estates: stage the relays
If you have on the order of a hundred scopes, you cannot do it all in one go.
- Migrate by site or by relay group.
- Never dual-helper the same VLAN to old and new DHCP for “safety.” Two authorities on one broadcast domain is how you get duplicate Offers.
- Track which scopes are authoritative on the park vs still on the old pair.
What Lattice is — and is not — in this story
Lattice is software-only DDI: one catalog for prefixes, subnets, pools, reservations, and leases. dhcpd serves those rows. The reservation you save is the next Offer (latticeddi.com, Replace Windows DHCP).
Keep AD. A/PTR follow the grant into the DNS you already run. Option 6 stays on the resolver laptops already ask. Lattice is not Microsoft DNS and not your forest (Replace Windows DHCP).
HA is not Microsoft failover. No partner server. No split scope. Paid HA is three Ubuntu VMs, one Postgres, one VIP. Discover on one node and Ack on another is the same pool (HA docs, Replace Windows DHCP).
Cutover does not ingest live leases. Dump scopes and reservations — PowerShell mapping is on Migrate — POST /api/v1. Lattice does not parse Microsoft XML or lease files. Failover partners do not come with you. Live leases do not import; occupancy starts at the first Ack Lattice grants (Migrate, Replace Windows DHCP).
Deploy. Ubuntu tarball. No appliance. No phone-home (Deploy, Security).
Beta. Lifetime perpetual Starter so you can test three-node HA — 5,000 managed IPs. Same binaries as paid Starter. No SLA. Not a sale. Paid checkout is not open yet; the pricing table is the published list (Pricing). Cluster builds are still pre-GA (Releases).
If you only need a clean Windows park for the DC weekend, stay on Windows DHCP for that weekend. If the spreadsheet of used IPs is already lying to you, the why-switch note is the longer argument: Why switch off Windows DHCP and the spreadsheet.
Checklist before you break the pair
- Scope / reservation / exclusion inventory outside MMC
- GUI backup + export artifact you can re-open
- Temp host authorized and reachable from relays
- Window to break failover without a half-pair
- Relay change plan per VLAN (no dual helpers)
- Test renew + reservation check before DC rebuild
- Written decision: back to DCs, dedicated Windows DHCP, or Lattice cutover
Soft next step
Read Replace Windows DHCP for the one-catalog compare. Dump scopes with the sibling note Dump Windows DHCP scopes. When you want HA on one catalog instead of a hashed pair, join the beta for lifetime Starter (5k managed IPs, three-node HA, no SLA) at latticeddi.com.
latticeddi.com