A DHCP migration is not finished when a destination console displays the scopes. Clients must still discover the right server, renew existing leases without collision, receive the correct gateway and DNS settings, honour reservations and policies, update DNS as intended and survive the agreed failure scenario.

The most dangerous failure is not always an outage. Two servers issuing conflicting addresses can create intermittent faults that are much harder to diagnose.

Establish the current authority

Inventory every DHCP server, appliance and router that can answer on the affected networks. For each Windows DHCP server, record:

  • server-level and scope-level options;
  • scopes, subnet masks, ranges and lease durations;
  • exclusions, reservations and active leases;
  • policies, vendor/user classes and allow/deny filters;
  • DNS dynamic-update settings and credential ownership;
  • failover relationships and current partner state;
  • superscopes, multicast scopes or unusual dependencies;
  • Active Directory authorisation;
  • relay/IP-helper destinations on routers, firewalls and switches; and
  • monitoring, backup and alerting.

Compare configuration with the IP address management source of truth and with actual network devices. A stale spreadsheet is not authority, but neither is one DHCP console if a branch router also serves addresses.

Investigate conflicts, exhausted ranges, bad-address entries and abnormal decline/renewal patterns before migration. Carrying an unexplained fault into the destination makes cutover evidence ambiguous.

Choose the destination design first

Decide whether the target will be one server or a Windows DHCP failover pair. Failover shares IPv4 lease and state information between two Microsoft DHCP servers; it does not automatically update external relays, provide an IPAM process or fix DNS permissions.

For failover, choose load-balance or hot-standby behaviour from the site’s connectivity and recovery requirements. Define partner communication, shared secret custody, maximum client lead time, reserve capacity and the operational conditions for changing state. Do not treat “partner down” as a harmless button: it changes which server may allocate addresses and must reflect the real failure.

If migrating an existing pair, preserve the relationship between scope ownership and authoritative lease state. If two exports contain the same scope, do not import both blindly. Reconcile which data set is authoritative and follow Microsoft’s current same-scope/failover migration sequence.

Make an export that can support rollback

Use the Microsoft-supported export method for the exact Windows Server versions and include both configuration and leases. Protect the export because reservations, client identifiers, descriptions and DNS settings can expose operational data.

Record source version, time, scope counts, reservation counts, active-lease counts and configuration hash or other integrity evidence. Keep the source service recoverable until cutover validation is complete.

An export does not contain every dependency. Capture separately:

  • destination server role and patch readiness;
  • AD authorisation plan;
  • DNS update credentials and permissions;
  • firewall requirements;
  • relay/IP-helper changes;
  • monitoring/backup changes; and
  • static addresses or devices incorrectly sitting inside dynamic pools.

Prepare without serving too early

Install and patch the destination DHCP role, provide secure administrative access and confirm time, domain/DNS health and network reachability. Import the reviewed data while ensuring the destination cannot unintentionally answer production clients before the cutover point.

Read back the imported scopes, options, reservations, policies, filters and leases against the captured counts and selected spot checks. Inspect values, not only object totals: a wrong router option replicated perfectly is still wrong.

For failover, create or migrate the relationship using the supported sequence and verify both partners agree on configuration and state before exposing them to clients.

Coordinate one authority transition

The cutover plan should name the exact order and owners:

  1. freeze avoidable configuration changes;
  2. capture a final authoritative export and counts;
  3. stop or isolate the old serving authority at the agreed point;
  4. authorise the intended Windows DHCP server or servers in Active Directory;
  5. update relay/IP-helper destinations where the server address changes;
  6. permit the required traffic; and
  7. begin controlled client tests before broad acceptance.

Do not leave the source and destination serving an overlapping scope independently “for safety.” Safe overlap requires a designed failover relationship or deliberately partitioned, non-overlapping ranges—not hope that clients choose the right reply.

Test from the client’s side

Use a test matrix across local and relayed subnets:

  • a new client completes discovery and receives an address from the correct scope;
  • an existing client renews its current lease;
  • a client forced to rebind can reach the intended authority;
  • a reservation receives the expected address;
  • an excluded or denied identity is not allocated an ordinary address;
  • gateway, DNS servers, suffix, time and vendor-specific options are correct;
  • forward and reverse DNS behaviour matches policy;
  • leases appear on the authoritative server and, for failover, replicate to the partner; and
  • application connectivity works after lease acquisition.

Capture packet evidence when replies are missing or duplicated. A client may retain a cached valid lease and appear healthy without contacting the new server, so a successful ping from one existing workstation proves very little.

For failover, test the designed normal and failure state with synthetic clients. Confirm which partner allocates, how state is reported, and how the pair returns to normal. Do not manufacture a production outage merely to collect evidence; rehearse in isolation and use controlled operational tests.

Recover when the old server is unavailable

First confirm that the incident is a DHCP-server failure rather than a relay, VLAN, firewall, DNS or address-exhaustion problem. Preserve the latest known export and avoid merging unknown lease databases.

Restore to a supported destination, reconcile the age of lease data and choose a collision-control strategy. Clients with leases newer than the backup may continue using them. Monitor conflicts and consider conservative allocation/validation controls appropriate to the outage rather than shortening every lease or clearing the database blindly.

If no trustworthy backup exists, reconstruct scopes from authoritative network documentation and reservations from validated asset evidence, then introduce service cautiously. That is a rebuild, not a full recovery; say so in the incident record.

Retire the old server only after observation

After the agreed observation period, deauthorise the old Windows DHCP server, remove obsolete relays and monitoring, and prevent accidental service restart. Retain the protected export and migration record according to policy.

The migration is complete when intended clients across every relevant subnet acquire and renew correct configuration, DNS and failover behaviour are proven, only the intended authority can answer, and the organisation can restore the service again.