Renumbering a Network Without Downtime: A Phased Migration Playbook

Every network eventually ends up with addresses it wishes it had chosen differently. The small office that started on 192.168.1.0/24, the factory default of most home routers, now has three hundred devices and a server that runs out of addresses to hand out by mid-morning. The company that picked a block at random in 2009 discovers that the block belongs to someone else on the public internet, and a customer's website is unreachable from inside the building. The new manager who inherits fifteen years of subnets, handed out in whatever order people asked for them, finds that no two sites follow the same pattern and no firewall rule can be written without listing a dozen ranges. The fix in all three cases is renumbering: giving the network a new set of IP (Internet Protocol) addresses that fit its size and shape. Our guide to merging networks after an acquisition covered the renumbering a merger forces on you. This guide covers the renumbering you choose, and it walks through a phased plan that moves a network onto new addresses while everyone keeps working on it.

Renumbering has a fearsome reputation because other things depend on every address. A printer knows the print server by its address. A backup agent on every laptop knows the backup server by its address. The monitoring system, the badge reader controller, the phone system, the license server for the accounting software, and the DNS (Domain Name System, the service that turns a name like mail.example.com into an address) server all carry addresses in their settings, and so do the firewall rules and ACLs (access control lists, the rules on routers and firewalls that decide which traffic may pass) that protect them. Some software licenses are tied to the address of the machine that runs them and stop working when it changes. Remote employees' VPN (virtual private network) clients hold a list of which ranges to send through the tunnel. Change one address and everything that named it has to change too, and nobody has the full list. That is why the "big bang" approach, where everything moves over one weekend, so often turns into a very long weekend. The plan below trades one enormous change for a sequence of small ones, each with a way back, so that the item missing from the list becomes an inconvenience on a Tuesday afternoon instead of an outage on a Monday morning.

Choose the destination before touching anything, and choose it with room to spare. The private ranges set aside for internal networks by RFC 1918 (RFC stands for Request for Comments, the documents that define internet standards) are 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16, and our guide to reserved IP ranges explains what each one is for. Most organizations that renumber land somewhere inside 10.0.0.0/8, which has room for sixteen million addresses, and they stay well away from 192.168.0.0/24 and 192.168.1.0/24, because those are what every home router and coffee shop uses and they collide with employees' VPN connections forever, a problem our guide to VPN and overlay addressing describes in detail. Lay the new plan out hierarchically, one block per site with each site's subnets inside it, so that each site collapses to a single route the way our guide to supernetting and route summarization explains; our worked example of designing an IP plan from scratch shows the whole process, and the subnet calculator will check the arithmetic. One rule matters more than any other for a renumbering in particular: the new block must not overlap the old one anywhere, because for weeks or months the two will run side by side on the same wires and the same routers.

An office that grew by accident, and the plan it is moving to

Old (assigned as requested)              New (one /16 for the site, planned)
192.168.1.0/24    everything, full         10.20.10.0/24    users
192.168.2.0/24    "servers" (and a printer) 10.20.20.0/24    servers
192.168.50.0/24   Wi-Fi (nobody knows why 50) 10.20.30.0/24  Wi-Fi
10.1.1.0/24       the phone VLAN           10.20.40.0/24    phones
                                           10.20.50.0/24    printers and badge readers
                                           10.20.250.0/24   routers, switches, management
                                           10.20.0.0/16      the whole site, one route

The next job is an inventory, and it has to be honest rather than tidy. You cannot renumber a device you do not know exists, and every network has devices nobody remembers: the temperature sensor in the server room, the projector with an address typed into it, the old file server someone keeps around "just in case." Our guide to building an inventory of an inherited network describes how to assemble one from routing tables, lease lists, ARP caches, and careful scans. For a renumbering, the inventory needs three columns beyond the usual: the device's current address, the address it will have after the move, and how it gets its address. That last column decides how much work each row will be, because a device on DHCP (Dynamic Host Configuration Protocol, the service that hands out addresses automatically) moves itself, a device with a DHCP reservation moves when you edit the server, and a device with a static address typed into it has to be visited. Our guide to choosing between DHCP, static, and reservations explains the trade-offs, and a renumbering is a fine time to convert stubborn statics into reservations. Finish the inventory by scanning each subnet and reconciling the results against your records, so that anything on the network your records do not mention gets a row before it gets a chance to surprise you halfway through.

A device's own address is one thing to track; the places that address is written down are another, and there are always more of the second. This is the hunt for hardcoded references, and the most useful tool for it is a plain text search. Gather every configuration you can export: router, switch, and firewall configs, the DHCP server's scope options, DNS zone files, application settings, the hosts files on servers, the monitoring system's device list, backup job definitions, printer settings, and cloud security groups. Then search all of it for the old range. On a Linux or Mac machine the command is grep, a search tool that prints every line matching a pattern, and a single pass over a folder of config backups will produce a list longer than anyone expected.

One search across a folder of config backups

$ grep -rn "192\.168\.[0-9]*\.[0-9]*" /backups/configs/
fw-core.cfg:212:      set srcaddr 192.168.2.10           firewall rule, database server
fw-core.cfg:340:      set dns-server 192.168.1.5         firewall's own resolver
sw-floor2.cfg:18:     ip default-gateway 192.168.1.1     switch management
sw-floor2.cfg:22:     ntp server 192.168.2.5             time source
dhcp.conf:44:         option routers 192.168.1.1         handed to every client
dhcp.conf:45:         option domain-name-servers 192.168.1.5
backup-agent.ini:3:   server=192.168.2.20                on 300 laptops
monitoring.yml:118:   host: 192.168.2.15
printer-fleet.csv:7:  HP-3F-East,192.168.2.44,static     the printer in the server subnet
... 214 lines

Every hit becomes a row on the migration list with an owner and a phase. Some of the rows point at things that can only be fixed by hand: the gateway and DNS options in the DHCP scope, the NTP (Network Time Protocol, how devices set their clocks) server address typed into a switch, and the license locked to a server's address, which usually means an email to the vendor and a waiting period best started today. Many of the rest reveal something you can fix permanently. Wherever a setting names another machine by address, ask whether it could name it by DNS name instead, because a name survives a renumbering with a single record change. The backup agent that points at backup.corp.example.com keeps working after the server moves, and the one that points at 192.168.2.20 breaks on three hundred laptops at once. Converting references to names before the move shrinks the list, and it also spares whoever does the next renumbering. Our guide to keeping DNS and the IP inventory in sync covers how to make the names trustworthy first, and the DNS lookup and reverse DNS tools will show you what your existing records say about any address in the old range.

The technique that makes all of this survivable is borrowed from the transition to IPv6 (Internet Protocol version 6, the newer addressing scheme), where networks routinely run two address families at once and call it dual-stack. A renumbering does the same thing with two IPv4 (Internet Protocol version 4) ranges. Nothing loses its old address until its new address is working, and the old and new ranges coexist on the same network for the whole transition. The mechanism on most routers is a secondary address: the interface that serves a VLAN (Virtual Local Area Network, a way of running several separate networks over the same switches) is given its new address alongside its old one, so the router answers on both. A device still on the old range talks to the router at the old gateway address, a device that has moved talks to the router at the new one, and the router carries traffic between them. Traffic between an old-range device and a new-range device on the same VLAN takes a detour through the router instead of travelling directly, a small performance cost that disappears when the migration ends.

The router answers on both ranges during the overlap

interface Vlan10
 description Users
 ip address 10.20.10.1 255.255.255.0
 ip address 192.168.1.1 255.255.255.0 secondary
 ip helper-address 10.20.20.5              DHCP relay, already on its new address

Devices on 192.168.1.x use gateway 192.168.1.1
Devices on 10.20.10.x use gateway 10.20.10.1
Both reach each other, and everything else, through the router

Firewall rules need the same treatment, and this is where a migration most often weakens security without anyone noticing. The tempting shortcut is a rule that permits the whole new range to reach the whole old one and back, "just for the migration," and that is the kind of rule that is still there three years later. The disciplined version adds the new address or range beside the old one in each existing rule, so that a rule allowing the accounting subnet to reach the database server now lists both accounting subnets and both database addresses. At the end of the project, cleanup is a matter of deleting the old entries, and the rules end up exactly as strict as they were before. Where a router or firewall cannot hold a secondary address, the same idea works with a second VLAN carrying the new subnet in parallel. The mechanism changes; the principle, that nothing is taken away until its replacement works, stays the same.

Move things in the order they depend on each other: infrastructure first, then servers, then clients, then the removal of the old range. Clients depend on servers, servers depend on the infrastructure beneath them, and anything that moves before the thing it depends on will break. Infrastructure means the DNS servers, the DHCP server, the NTP source, the directory service people log in to, and the routers and gateways themselves. Each of those gets its new address added as a second address so it answers in both places, and the DHCP scope options and the resolver settings on the servers are updated to hand out or use the new addresses. Nothing has stopped answering on the old range at this point; you have only taught the foundations to answer twice. Every phase ends with a checkpoint where you confirm that the things that worked yesterday still work today, and every phase has a rollback that undoes only that phase and nothing before it.

The phases, and the way back from each one

Phase  What moves                                Rollback
0      Plan, inventory, hardcoded-reference hunt  nothing has changed
1      Routers get secondary addresses            remove the secondary line
2      DNS, DHCP, NTP, directory answer on both   remove the new listener
3      Servers, one at a time                     restore old address and DNS record
4      Clients, one DHCP scope at a time          reactivate the old scope
5      Old range logged, then removed             re-add the secondary from saved config

Each phase waits for the previous one to be quiet before it starts

DNS needs its own timing, because DNS answers are cached. Every record carries a TTL (time to live), a number of seconds that tells whoever looks it up how long they may keep using the answer without asking again. A common default is 86,400 seconds, a full day, which means a laptop that looked up the file server this morning will keep sending traffic to the old address until tomorrow morning, however quickly you change the record. The remedy is to lower the TTL on the records for each phase about a week before that phase, down to 300 seconds, five minutes. The week matters: caches that already hold the old, day-long answer will keep it for up to a day, so you have to wait out the old TTL before the new short one is in force everywhere, and a week leaves a margin for the cache you forgot about. On the day of the move the record changes, and within five minutes every cache has expired and fetched the new answer. Once the phase has settled, raise the TTL back to its usual value, since short TTLs mean more lookups and a busier DNS server. If any public records point at addresses that will change, our DNS propagation checker shows when the new answer has reached resolvers around the world.

TTL choreography for one server

T minus 7 days   TTL on files.corp.example.com: 86400 → 300
                 old day-long answers age out of every cache over the next 24 hours
T minus 0        A record: 192.168.2.20 → 10.20.20.20
                 PTR record for 10.20.20.20 created, PTR for 192.168.2.20 removed
T plus 5 min     every cache has expired; all lookups return the new address
T plus 7 days    old address quiet; TTL 300 → 86400
                 remove 192.168.2.20 from the server

Servers move one at a time, and each one follows the same short script. Add the new address as a second address on the server, which every modern operating system allows. Update its forward DNS record and its PTR (pointer) record, the reverse entry that turns the address back into a name. Work through every row on the migration list that names this server and update each one, then leave the server answering on both addresses for a few days while you watch the old one. Most operating systems and firewalls can show which connections are still arriving at the old address, and each one that arrives is a reference you missed; fix it, wait again, and remove the old address only when it has been quiet for long enough to include whatever weekly or monthly job might still be pointing at it. Rollback at every point is the reverse of the step you just took: put the old address back, put the DNS record back, and nothing else has changed.

Clients are the easiest phase when DHCP is doing its job, and the hardest when it is not. On the DHCP server, build the new scope for each subnet with the new gateway and DNS options, and a week or two before the move shorten the lease time on the old scope so that devices check in often. On the day, deactivate the old scope. Each device asks to renew its lease, is refused, and requests a fresh one, and the only offer available comes from the new scope, so over the next hour the whole subnet moves itself. Reservations move with an edit on the server. Devices with a static address typed into them, which in most offices means printers, wireless access points, badge readers, and the occasional server someone forgot to list as a server, each need a visit or a remote session, and the inventory from phase zero is the list of visits. Rollback is reactivating the old scope. If a device you have never seen before turns up during this phase, or a forgotten static address collides with a freshly assigned one, our guide to IP address conflicts explains how to track it down by its hardware address.

The surprises in a renumbering almost always come from the seams, the places where your network touches one you do not control. Remote employees' VPN clients carry a list of the ranges that belong to the office; push the updated list that includes the new range before the servers move, or people at home lose the file server on the day it renumbers. Site-to-site VPN tunnels and cloud connections list the ranges permitted on each side, and both ends have to change; security groups and route tables inside a VPC (virtual private cloud, a private network inside a cloud provider) name your office ranges too. Partners who allow your traffic through their firewalls need the new range in writing, with lead time measured in weeks. Certificates occasionally list an IP address instead of a name and have to be reissued. Any service you reach through NAT (network address translation, which our NAT guide explains) may or may not change from the outside world's point of view, so check which public addresses depend on an internal one. Every one of these deserves a row on the list and a date, because none of them can be rolled back by a single command on your own router.

"Done" means the old range carries no traffic and nothing anywhere still refers to it, and both of those can be proved rather than assumed. Before removing the old secondary addresses from the routers, add an access rule that matches any traffic from or to the old range, permits it, and logs it. Leave the rule in place for a full business cycle, whatever that means for your organization: a month-end close, a weekend backup run, a quarterly report, because the device that only speaks once a month is the one everyone forgets. Every log entry is a device or a reference you missed, and the entries should dwindle to nothing. The router's ARP (Address Resolution Protocol) table, which lists every device the router has recently spoken to on each subnet, should show no entries in the old range. The old DHCP scope should hold no active leases. A search of your DNS zones for the old range should return nothing, and the reverse zone for it should be empty and then deleted. The exit checklist is short, and the point is to check every line rather than to trust that a quiet week means a finished migration.

Exit checklist for 192.168.1.0/24

[x] ACL "log-old-range" hit count: 0 over the last full business cycle
[x] Router ARP table, 192.168.1.0/24: 0 entries
[x] DHCP scope 192.168.1.0/24: 0 active leases, scope deleted
[x] Forward DNS zones: grep for 192.168.1. returns nothing
[x] Reverse zone 1.168.192.in-addr.arpa: empty, then deleted
[x] Firewall: old-range objects removed, test rules still pass
[x] VPN client config: old range removed from the tunnel list
[x] Config backups: grep for 192.168.1. finds only the change log
[x] Inventory: old subnet retired, every device shows its new address

Removal is the first phase run backward. Take the secondary addresses off the router interfaces, delete the old DHCP scopes, remove the old objects from the firewall rules and confirm the rules still pass the tests you ran before the project began, delete any parallel VLANs, and withdraw the old range from routing. Keep a copy of the pre-removal configs for a while, since the rollback for this phase is putting a secondary address back, and that takes one line if the line is saved somewhere. Then retire the old range in your records, so that nobody assigns from it again and nobody a year from now has to wonder whether the old subnets are still in use.

Through all of this the records have to hold two truths about every device at once, its old address and its new one, and a spreadsheet handles that badly, which is one of the reasons our guide to spreadsheet IP management suggests moving off one. In IPCraft, an IPAM (IP address management) tool, the new site block lives as a parent subnet with the new subnets inside it, and the planned addresses can be loaded ahead of time from a CSV (comma-separated values, the plain-text spreadsheet format) file with each one marked reserved and a note naming the device and the old address it replaces, as the CSV import guide describes. As each device moves, its new record becomes active and its old one is released, so the old subnets' utilization drifts toward zero and becomes the project's progress bar. Pasting a scan of an old subnet into the scan reconcile tool shows what is still answering there against what the records say should be, which is the check the exit checklist asks for, done in seconds. The activity log keeps a record of who changed what and when, which matters most on the day something breaks and the first question is what moved last week.

The whole playbook reduces to four habits. Add the new before removing the old, so that nothing loses its address until its replacement works. Move in dependency order, infrastructure and then servers and then clients, so that nothing moves before the thing it relies on. Keep a rollback at every step that undoes only that step. And hold off on declaring the project finished until the old range has been silent for a full cycle of everything your organization does on a schedule. A renumbering run this way is a long sequence of small, dull changes, most of them made during business hours, and dull is the highest compliment a network change can earn.