Migrating DHCP from your router to Pi-hole sounds simple until half your devices lose internet for ten minutes. I have seen it happen on three different home networks, and the cause is almost always the same: a router that restarts its DHCP service the moment you disable it, handing out zero leases while Pi-hole warms up. This guide walks you through migrating DHCP to Pi-hole in 2026 without that brief but painful DNS outage, with explicit timing, a rollback plan, and a verification checklist at the end.
Table of Contents
Why Migrate DHCP to Pi-hole?
Running DHCP on Pi-hole puts both IP assignment and DNS filtering in one place. I switched my own network about nine months ago, and the biggest win was seeing every device show up in the query log with its hostname instead of a generic MAC address from the router’s pool.
There are four real benefits to this migration. First, you gain consistent DNS redirection: every device that pulls a lease from Pi-hole automatically uses Pi-hole for DNS, so nothing bypasses the blocklists through a hardcoded resolver. Second, you get reliable hostname registration, which makes per-device blocking rules actually usable. Third, you centralize lease management, so static reservations and lease times live next to your blocklists and upstream DNS settings. Fourth, you reduce the number of services your router runs, which matters on older ISP gear that struggles under any extra load.
The catch is the handover window. Most routers do not gracefully hand off DHCP duties; they stop serving leases the instant you click disable, and that creates the outage everyone complains about on Reddit. The rest of this guide is designed to close that window without leaving devices stranded.
Prerequisites Before Migrating DHCP to Pi-hole
Before you touch anything, work through this list. Skipping steps here is how migrations turn into multi-hour outages.
1. Confirm Pi-hole is healthy. Open the admin console and verify the status shows “running” with a low query load. Update to the latest version through Settings > System. A misbehaving Pi-hole will turn your outage into an extended one.
2. Give Pi-hole a static IP. Either set it inside Pi-hole itself or, preferably, pin it via a DHCP reservation on your router that survives the migration. Pi-hole cannot dynamically lease an address to itself. If you have not done this yet, do it now and reboot the Pi so the new address sticks.
3. Record every DHCP setting on the router. You need the following values: starting address, ending address, subnet mask, default gateway, lease time, and DNS server values currently handed out. Screenshot them. Write them down in a text file. You will need them to recreate the same lease space in Pi-hole.
4. Export your static DHCP reservations. Every router UI calls this something different. ASUS shows them under LAN > DHCP Server > Manually Assigned. Netgear hides them under Advanced > Setup > LAN Setup. Grab the MAC address and desired IP for each one. If your router has no export button, photograph the screen or transcribe the list. Pi-hole does not have a one-click importer.
5. Reduce the router lease time to 5 minutes temporarily. This is the most overlooked step. A 24-hour lease means every device holds a stale address for up to a full day. Dropping it to 5 minutes forces every device to ask for a new lease shortly after you switch DHCP servers. Set this back to a longer value later, after the migration is verified.
How to Migrate DHCP From Your Router to Pi-hole Step by Step
Follow these steps in order. Do not skip the verification between steps.
Step 1: Enable the Pi-hole DHCP server first, but leave the router’s DHCP running. Log into Pi-hole’s admin console. Go to Settings > DHCP. Toggle “DHCP server enabled” on, then enter the same address range, subnet mask, gateway, and lease time you recorded from the router. Click Save. Pi-hole is now listening but the router is still authoritative. Two DHCP servers on the same subnet will conflict, so this is a temporary state lasting only minutes.
Step 2: Add your static reservations to Pi-hole. In the same DHCP settings screen, scroll to “Static DHCP leases” and enter each MAC and IP pair you exported. Save each one. Pi-hole will assign these the moment it becomes authoritative.
Step 3: Disable the router DHCP server. This is the moment of truth. Go into your router’s LAN or DHCP settings and disable the DHCP server. On most consumer routers, this causes the router to send DHCPNAK to clients so they immediately renegotiate. On ASUS AiMesh setups, you must keep DHCP enabled on the main router and disable it only on the node running Pi-hole in the wrong mode.
Step 4: Force devices to renew quickly. Renewing a lease on a workstation takes about three seconds. I ran ipconfig /release followed by ipconfig /renew on my Windows machines right after flipping the router DHCP off. On Linux and macOS, dhclient -r and sudo dhclient re-acquires the lease immediately. Mobile devices renew when they wake or move between access points.
Step 5: Re-enable on Pi-hole and verify. After about 60 seconds, log into Pi-hole and look at Settings > DHCP. You should see a counter of active leases climbing. Open the query log. If devices are querying through Pi-hole, the migration worked. If you see old router leases still active after five minutes, repeat the renewal step on stubborn devices manually.
Preventing DNS Outages During DHCP Migration
The outage everyone dreads comes from lease timing, not from Pi-hole itself. Here is what actually happens during a botched migration.
DHCP leases have two timers: T1, which is 50% of the lease time, and T2, which is 87.5%. At T1, a device asks to renew with whichever server last gave it an address. If the router stops serving and Pi-hole is not yet authoritative, the device sits there waiting. Modern operating systems retry eight times with backoff before falling back to a 169.254.x.x address. That fallback is where DNS dies, because the device has no upstream resolver.
To avoid this, three things have to happen at once. The router must stop issuing leases. Pi-hole must be ready to issue leases. Devices must immediately ask for new leases. That is why reducing the lease time to 5 minutes before the migration is so important: it collapses the natural T1 timer to 2 minutes and 30 seconds, so devices cycle through the failure window fast.
There is also a lesser-known trap. If you point Pi-hole to use itself as the upstream DNS resolver, and then Pi-hole goes down, every device on the network loses DNS entirely. A safer setup uses an external resolver like 1.1.1.1 or 8.8.8.8 as the upstream, with Pi-hole’s conditional forwarding turned on only if you actively need local hostname resolution. Most home users can leave conditional forwarding disabled during the migration and turn it on later once everything is stable.
Migrating Static DHCP Reservations
Static reservations do not survive the migration on their own. Each one needs to be re-created in Pi-hole before you disable the router DHCP server.
Open your exported list. For each entry, copy the MAC address as twelve characters with colons, like aa:bb:cc:dd:ee:ff. In Pi-hole, go to Settings > DHCP and scroll to the static leases section. Enter the hostname, MAC address, and IP. Click Add. Repeat for every device. After they are all in Pi-hole, test by pinging one of the reserved IPs from another device; if the lease shows up in Pi-hole with the right hostname, the reservation works.
If your router and Pi-hole disagree on a reservation, devices will receive whichever answer arrives first. Resolve conflicts before flipping the router DHCP off.
Testing and Verification Checklist
Run this list before declaring the migration successful.
All previously-leased devices show up in Pi-hole’s DHCP leases tab within 10 minutes.
Query log shows DNS traffic from every active device, not just one or two.
Static reservation devices receive the same IP they had before, confirmed via ipconfig or ifconfig.
No device has a 169.254.x.x fallback address.
Conditional forwarding, if enabled, resolves local hostnames to their new leases.
Devices waking from sleep reconnect to the network within 30 seconds.
If any check fails, jump to the rollback procedure. There is no benefit to troubleshooting a broken migration when you can restore the old state in 90 seconds.
Rollback Procedure If Migration Fails
Open the router admin page, find DHCP settings, and re-enable the router DHCP server. Reset the lease time to your original value. Disable Pi-hole’s DHCP server under Settings > DHCP by toggling it off. Devices will auto-recover because Pi-hole had no clients to lose, but verify with a quick ping test from a workstation. Once everything works again, document what failed and decide whether to retry the migration with a different approach or leave Pi-hole as a pure DNS server.
Frequently Asked Questions
Can DHCP work without DNS?
Yes. DHCP and DNS are independent services. A DHCP server hands out IP addresses, default gateway, and DNS server values. Devices use the DNS values to reach a resolver. If your router only assigns IP addresses and leaves DNS servers blank, devices fall back to public resolvers like 8.8.8.8. That is why Pi-hole still filters traffic even when DNS is handed out elsewhere, and why running DHCP on Pi-hole gives the most reliable filtering.
What happens to DHCP leases during migration?
When you disable DHCP on the router, the router sends DHCPNAK to every client, telling them their existing lease is invalid. Devices immediately try to renew. If Pi-hole is already listening with overlapping settings, renewal succeeds within seconds. If Pi-hole is not yet ready, devices keep retrying for a few minutes before falling back to a self-assigned 169.254 address, at which point DNS breaks entirely. Shortening lease times before migration forces fast renewals and avoids this window.
How do I stop DNS outages when migrating DHCP?
Three actions prevent the outage. First, shorten the router lease time to 5 minutes before starting, so devices renew quickly. Second, have Pi-hole DHCP already configured with the same range and gateway before you disable the router. Third, force a lease release and renew on at least one workstation right after the swap, so you confirm renewals work before walking away.
Do I need to disable router DHCP for Pi-hole?
Yes. Two DHCP servers on the same subnet will fight over every lease request, and devices will receive whichever answer arrives first, which causes intermittent DNS failures. Disable the router DHCP server as the last step in the migration. Leaving both running is the most common reason for the random internet dropouts reported on Pi-hole forums.
How long does DHCP migration take?
The active work takes five to ten minutes: configure Pi-hole DHCP, copy static reservations, lower the lease time, flip the routers DHCP off, force a few renewals. The cleanup takes longer, since returning the lease time to 24 hours and verifying every device on the network connects normally can stretch to an hour. Plan to do this during a quiet window when no one is streaming.
Final Thoughts on Migrating DHCP to Pi-hole
Migrating DHCP from your router to Pi-hole in 2026 is a routine change once you understand the lease timing problem. The whole process comes down to three rules: shorten lease times before you start, configure Pi-hole before disabling the router, and verify on at least one device before walking away. With those three rules and the rollback procedure in this article, you can do the migration without the DNS outage everyone warns about. Take it slow, test as you go, and you will end up with a cleaner network than the one you started with.