Introduction

A data center or provisioning migration can bring the new imaging environment online while PXE clients still download boot files from the old TFTP server. New machines fail to image, boot into the wrong provisioning workflow, or hang before the installer starts because DHCP, relay, or bootfile settings still reference the retired infrastructure.

Treat this as a network-boot path problem instead of a generic hardware or operating system issue. Start by checking which boot server and bootfile a failing client actually receives during PXE, because migrations often move the imaging platform itself while DHCP options and helper addresses remain tied to the previous site.

Symptoms

  • Bare-metal or VM provisioning still contacts the old PXE or TFTP server after migration
  • New systems fail during network boot even though the replacement imaging platform is online
  • Different VLANs or sites boot from different provisioning environments
  • Clients download the wrong bootfile or reach an outdated installer menu
  • PXE works in one network segment while another still depends on the previous boot server
  • The issue started after moving DHCP, imaging services, or data center network infrastructure

Common Causes

  • DHCP options such as next-server or bootfile name still point to the old PXE environment
  • IP helper or relay settings on routers still forward PXE traffic to the retired server
  • BIOS and UEFI clients were migrated differently, leaving one boot path on the old infrastructure
  • The new TFTP or HTTP boot service is online, but scope-specific DHCP policies still advertise the previous target
  • Provisioning templates, WDS or imaging roles, or boot media metadata still publish the old server address
  • Validation confirmed the new imaging service existed but did not capture a real PXE exchange from an affected subnet

Step-by-Step Fix

  1. Capture a PXE attempt from an affected subnet and record the advertised boot server, bootfile, and relay path, because the live DHCP and PXE exchange shows where the client is really being sent.
  2. Compare that active boot path with the intended post-migration PXE design, because one stale next-server or helper entry can keep every client tied to the retired imaging stack.
  3. Review DHCP scopes, reservations, policy-based options, router IP helpers, and provisioning templates for references to the old TFTP or boot server, because PXE configuration often spans both server and network layers.
  4. Check BIOS versus UEFI boot definitions separately if only some hardware fails, because different architectures often use different bootfile names or transport methods.
  5. Update the authoritative DHCP, relay, and provisioning configuration so new PXE sessions advertise the correct boot target, because changing the imaging server alone does not move clients off the old path.
  6. Boot a controlled test machine from the affected network and confirm it downloads the expected boot program from the intended server, because a healthy TFTP service does not prove the subnet advertises it correctly.
  7. Verify the old PXE or TFTP server no longer receives requests from migrated segments, because partial helper or scope drift can leave network boot split across environments.
  8. Review firewall rules, MTU, and TFTP or HTTP boot reachability if clients now point to the new server but still fail, because the migration may have fixed the advertised target but not the transport path.
  9. Document which team owns DHCP options, relay configuration, and imaging services so future infrastructure moves validate the full PXE path before retiring the previous environment.