How to Migrate DHCP Server to a New Windows Server

Learning how to migrate DHCP server comes up for the same handful of reasons every time: the old box is going out of support, it’s getting consolidated into fewer hosts, or someone finally noticed it’s still running Windows Server 2012 R2. Whatever the trigger, the actual move is a short list of steps built around two PowerShell cmdlets, Export-DhcpServer and Import-DhcpServer, documented on Microsoft’s DhcpServer module reference, plus a few things around the edges that are easy to skip and expensive to skip.

What It Takes to Migrate DHCP Server

To migrate DHCP server, you export the server’s scopes and configuration from the old box with Export-DhcpServer, bring that file to the new server, and load it with Import-DhcpServer. Both cmdlets ship with the DHCP Server role and work against a remote computer, so none of this requires standing in front of either machine. The parts that actually cause outages aren’t the cmdlets, they’re forgetting to authorize the new server in Active Directory first, or forgetting that every router and switch on the network still has the old server’s IP address hardcoded as a DHCP relay target.

Prepare the New Server

Install the role before anything else:

Install-WindowsFeature -Name DHCP -IncludeManagementTools

No reboot is required for this step. Confirm the DhcpServer PowerShell module actually loaded before moving on, since a role install that silently failed partway through will otherwise surface later as a confusing cmdlet-not-found error:

Get-WindowsFeature -Name DHCP
Get-Module -Name DhcpServer -ListAvailable

If this server will also run DHCP failover with the old one during a staged cutover, remove or reconfigure any existing failover relationship on the old server first. Scopes that are still part of a failover pairing don’t migrate cleanly through export and import.

Authorize It in Active Directory

A DHCP server that isn’t authorized in AD won’t lease addresses, full stop, regardless of how correctly the scopes were imported. This step gets skipped more often than it should, usually because the import appears to succeed and nobody notices the server is still silently unauthorized until clients stop renewing.

Add-DhcpServerInDC -DnsName "newdhcp.contoso.com" -IPAddress 10.10.10.5
Get-DhcpServerInDCCode language: CSS (css)

Add-DhcpServerInDC needs Enterprise Admins rights, or delegated permission to the relevant AD container, so this is also the step most likely to stall waiting on someone else’s access. Confirm the new server actually appears in the Get-DhcpServerInDC output before continuing; a command that completes without error isn’t automatically proof the registration took.

Shorten Lease Times Before You Cut Over

This is optional, but it’s the difference between clients picking up the new server within minutes versus however long their current lease has left to run. On the old server, temporarily drop the scope lease duration to something short, two hours is a common choice, a day or two before the actual migration:

Set-DhcpServerv4Scope -ScopeId 10.10.10.0 -LeaseDuration 2.00:00:00Code language: CSS (css)

Clients renew well before a lease expires, not only at the moment it does, so a shorter duration means more of them have already renewed, and picked up whatever’s authoritative at that point, by the time you cut over. Remember to set it back to a normal duration (the default is eight days) on the new server once the migration is done.

Export the Configuration

Run this from the new server, pointing at the old one, so the exported file lands where you need it without a separate copy step:

Export-DhcpServer -ComputerName "olddhcp.contoso.com" -File "C:\DHCPMigration\dhcpexport.xml" -Leases -VerboseCode language: CSS (css)

Leaving off -ScopeId exports every scope along with the server-level configuration. The -Leases switch is optional, if the new server will issue fresh leases anyway shortly after cutover, skipping it makes the export noticeably faster on a server with a large number of active clients. Export-DhcpServer works against Windows Server releases going back to 2008, so this part of a project to migrate DHCP server isn’t blocked by how old the source box is.

Import on the New Server

Import-DhcpServer -File "C:\DHCPMigration\dhcpexport.xml" -BackupPath "C:\DHCPMigration\Backup" -Leases -VerboseCode language: JavaScript (javascript)

-BackupPath isn’t optional, it’s a mandatory parameter, and for good reason: the cmdlet backs up the new server’s own DHCP database to that location before touching anything, so a bad import can be rolled back. If a scope in the file already exists on the new server, it’s skipped with a warning rather than touched, unless -ScopeOverwrite is added, which deletes and recreates the matching scope from the imported data instead. Add -Force if this is running inside a script and the confirmation prompt would otherwise stall it unattended.

Verify Before Anyone Notices

Get-DhcpServerv4Scope
Get-DhcpServerv4Reservation -ScopeId 10.10.10.0
Get-DhcpServerv4ScopeStatistics -ScopeId 10.10.10.0Code language: CSS (css)

Check that scope options, exclusions, and reservations came across, not just the scope ranges themselves, since reservations in particular are easy to overlook until a printer or a server with a static-via-DHCP address silently gets handed something else. Open the DHCP console too; a scope that looks fine from Get-DhcpServerv4Scope can still be showing as inactive if it wasn’t explicitly activated after import.

Update Relay Agents

If DHCP clients reach this server across a router or Layer 3 switch rather than sitting on the same broadcast segment, those devices have the old server’s IP address configured as a relay target (IP Helper address), and nothing about Export-DhcpServer or Import-DhcpServer touches that configuration. It lives entirely on the network hardware. Walk through every router, switch, firewall, and wireless controller that’s relaying DHCP traffic and update the helper address to the new server’s IP. Skipping this is the single most common reason an attempt to migrate DHCP server looks successful on the server side and then generates a wave of tickets from a remote site the next morning.

Retire the Old Server

Once client leases confirm the new server is handling renewals correctly, stop the DHCP Server service on the old one and set it to disabled, rather than uninstalling anything immediately:

Stop-Service -Name DHCPServer
Set-Service -Name DHCPServer -StartupType DisabledCode language: JavaScript (javascript)

Give it a few days running disabled before unauthorizing and removing the role outright. If something was missed, a disabled service is a five-minute fix; a removed role and an unauthorized server is a slower one to walk back.

Remove-DhcpServerInDC -DnsName "olddhcp.contoso.com" -IPAddress 10.10.10.2
Get-DhcpServerInDCCode language: CSS (css)

Confirm only the new server shows up in Get-DhcpServerInDC before uninstalling the DHCP role and the RSAT-DHCP management tools from the old box.

Learn more: How to Connect to Remote PC with Windows App

References

Microsoft: Export-DhcpServer (DhcpServer) https://learn.microsoft.com/en-us/powershell/module/dhcpserver/export-dhcpserver

Microsoft: Import-DhcpServer (DhcpServer) https://learn.microsoft.com/en-us/powershell/module/dhcpserver/import-dhcpserver

Microsoft: Add-DhcpServerInDC (DhcpServer) https://learn.microsoft.com/en-us/powershell/module/dhcpserver/add-dhcpserverindc

Microsoft: Migrate Existing DHCP Failover https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/migrate-existing-dhcp-failover