Introduction

A network migration can bring the new DHCP service online while routers or switches still relay requests to the old server. Clients get the wrong lease, gateways and DNS settings remain outdated, or one subnet works while another still depends on the retired DHCP environment because helper addresses and relay configuration were not updated everywhere during the cutover.

Treat this as a lease-delivery problem instead of a generic client networking issue. Start by checking which DHCP server actually answers requests for an affected subnet, because migrations often build the new scopes and failover pairs first while relay targets on the network devices remain unchanged.

Symptoms

  • Clients still receive leases from the old DHCP server after migration
  • New network settings never appear on affected devices
  • One subnet or site works while another still uses the previous DHCP environment
  • Leases fail only after the old DHCP server is shut down
  • Clients receive the wrong gateway, DNS server, or PXE-related options after cutover
  • The issue started after moving DHCP services, scopes, relay agents, or core network hardware

Common Causes

  • Router or switch helper addresses still point to the old DHCP server
  • DHCP relay configuration was updated on one VLAN or interface but not another
  • Scope activation, failover, or superscope ownership still leaves the old server authoritative
  • Relay agents or firewall rules still send DHCP traffic to the previous environment
  • Golden configs or network automation keep restoring the old helper target
  • Validation confirmed the new DHCP server had scopes but did not verify which server actually answered live requests

Step-by-Step Fix

  1. Capture one DHCP exchange from an affected subnet and record which server responds and which relay path forwarded the request, because the live responder determines where clients really get configuration.
  2. Compare that active DHCP path with the intended post-migration design, because one stale helper address can keep an entire VLAN tied to the retired server.
  3. Review helper addresses, relay agents, interface config, failover settings, and scope activation state for references to the old DHCP environment, because lease delivery depends on both server and network layers.
  4. Check every affected VLAN, SVI, or branch interface separately if only some clients are wrong, because DHCP migrations commonly fix one relay path while another still points at the previous server.
  5. Update the authoritative relay and server configuration so requests from the affected subnet reach the intended DHCP service, because moving scopes alone does not redirect network-device helpers.
  6. Renew a controlled client lease and confirm it receives the expected options from the intended server, because a valid IP address does not prove the right DHCP source answered.
  7. Verify the old DHCP server no longer receives requests from migrated segments, because partial relay drift can stay hidden while both servers remain reachable.
  8. Review lease timers, rogue DHCP sources, and firewall policy if behavior still looks inconsistent, because the target can be fixed while old leases or duplicate responders still interfere.
  9. Document which team owns helper addresses, DHCP failover, and cutover validation so future network migrations test the actual relay path before retiring the previous service.