Sanity Check: Moving DHCP to Windows Server 2025 While Reusing the Existing IP
Asked by
VelvetMaple47
I'm planning to migrate DHCP from an older Windows Server to a new Windows Server 2025 member server. To avoid changing IP helper configurations on our network devices, I'd like to move the old server's IP address to the new server.
Before the maintenance window, I'll install the DHCP role, create the required security groups, and record the existing scope, lease, and reservation counts. During the cutover, I plan to export the old configuration with leases, unauthorize and disable the old DHCP service, change the old server's IP, assign that address to the new server, import the configuration, and authorize the new server in Active Directory.
For validation, I'll compare scopes, leases, reservations, and options, then test address assignment from clients on multiple VLANs. Rollback would involve stopping DHCP on the new server and re-enabling and reauthorizing the old one.
We aren't using DHCP failover. I've also checked that there are no DHCP dynamic-update credentials or local DHCP Administrators group members that need to be recreated.
Is reusing the old IP a reasonable approach, or would it be better to use the new server's address and update the IP helpers? Are there ARP, DNS, import compatibility, scope-option, or ordering issues I should account for? How long should the old server remain available before decommissioning?
Answers
The alternative is to build the new server with its permanent address and update the relay or IP helper entries. That takes more network work, but it gives you a cleaner migration because both servers can coexist while you test one subnet at a time. If you use that method, configure and verify all reservations and options first, disable the corresponding old scope during each cutover, and make sure clients cannot continue receiving leases from both servers.
Reply to this answer
Keep the old server powered off but recoverable for at least one or two lease periods, and longer if your environment has long leases or rarely connected devices. Don’t leave both servers active with overlapping scopes unless you intentionally configure a supported failover arrangement. For rollback, stop and disable the new DHCP service, restore the old server’s original network settings, then start and authorize it again. Confirm that the gateway ARP entry points to the old server before testing clients.
Reply to this answer
The most important preparation is documenting the complete configuration and confirming the new server’s DHCP bindings after its IP changes. Depending on the installation and binding state, the interface may need to be selected again in the DHCP console or with the appropriate PowerShell commands. Follow the vendor’s documented migration procedure as a checklist, and verify DNS servers, default gateways, lease duration, reservations, and custom scope options after importing.
Reply to this answer
Reusing the old address is a reasonable way to avoid changing every relay, and the overall sequence looks sound. I’d save screenshots or an export of the complete DHCP configuration before starting, including scope options, policies, vendor and user classes, reservations, filters, and any custom options. After the import, compare those items rather than checking only scope and lease counts.
Once the new service is running, review the DHCP audit and server logs, then perform a release and renew from clients on several relayed VLANs. A switch reboot usually isn’t necessary. The important ARP entry is generally on the gateway in the server’s own subnet; clear that entry on the relevant gateway or HSRP/VRRP peers if it still points to the old MAC, then verify the new mapping.
CopperMoth22: Windows will often send a gratuitous ARP when the new server comes online, but some devices may not update immediately. Clearing the specific ARP entry is safer and much less disruptive than rebooting switches.
Reply to this answer
The export/import process is generally suitable for moving from older Windows Server versions to Server 2025, but don’t assume every setting transferred exactly as expected. Pay particular attention to scope options, DNS registration settings, policies, vendor or user classes, reservations, filters, and any options added by network appliances. If possible, perform a dry-run import on a test VM first and check the import output for warnings.
Also verify forward and reverse DNS records for both server names. If the reverse zone is separate, updating only the A record can leave stale PTR records. Lowering DNS TTL ahead of time can reduce confusion from cached records, although DHCP relays normally target the server IP directly.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MildOrbit31: A staged helper change also makes rollback simpler and gives you a chance to test on a low-impact VLAN. Since you’re migrating anyway, it’s worth considering DHCP failover or another redundant design instead of keeping a single server.