Merging Two Networks After an Acquisition: A Survival Guide for Overlapping Subnets

The deal closes, the press release goes out, and the two IT teams meet for the first time to figure out how the networks will connect. Someone shares a diagram within the first ten minutes, and the room goes quiet: both companies built their entire network inside 10.0.0.0/8. This happens in almost every merger, and the reason is structural. Every device on a network needs an IP (Internet Protocol) address, and a standards document called RFC 1918 sets aside just three address ranges for private networks, ranges we covered in our tour of the 10 reserved IP ranges every engineer should know. Nearly everyone picks the biggest one, 10.0.0.0/8, and often starts numbering from the same low corners of it. Two teams made the same sensible choice years apart, and the acquisition just made those choices collide.

The collision matters because of how routing works. A router keeps a table that maps each destination network to a direction: to reach 10.1.20.0/24, send traffic that way. The table can hold exactly one answer per destination. If the acquired company's payroll server lives at 10.1.20.5 and one of your office printers also lives at 10.1.20.5, a packet addressed to that IP has no way to say which one it means, so the two networks cannot simply be plugged together. (The slash notation, called CIDR, for Classless Inter-Domain Routing, describes how big each network block is; our visual guide to CIDR notation walks through it from scratch.) It is the same ambiguity behind an ordinary IP address conflict, except instead of two devices fighting over one address, you have two entire companies fighting over millions of them.

Meanwhile the business is not waiting. Leadership wants shared email, file access, and integrated finance systems within weeks, and fully renumbering even a mid-size network takes months at best. Surviving this gap means thinking in three layers with three different time horizons: NAT to get the first connections working this month, a renumbering plan to end up with one coherent network eventually, and VRFs to keep both address plans running side by side, sanely, for the long stretch in between.

NAT (Network Address Translation) is the day-one move. A NAT device rewrites the addresses on traffic passing through it, and at the boundary between the two companies, usually a VPN (Virtual Private Network) tunnel or a dedicated circuit, it lets each side see the other through a borrowed range that overlaps with nothing. You might present the acquired company's 10.1.20.0/24 to your network as 100.64.20.0/24, so their payroll server appears to your users at 100.64.20.5 while your printer keeps its real address. The 100.64.0.0/10 block, set aside for carrier-grade NAT, is a popular choice for this neutral middle ground precisely because neither company is likely to be using it internally. Within a week or two, the finance team can reach the systems they need, and the merger integration stays on schedule.

Then the bill arrives, one papercut at a time. DNS (Domain Name System), the service that turns names like payroll.acme.internal into IP addresses, now has to give different answers depending on which side of the seam you are asking from, a setup called split-horizon DNS that is notoriously easy to get wrong. Applications with hardcoded IP addresses break, because the address in their config is the real one and the network only knows the translated one. Some protocols embed IP addresses inside the data they carry, and those embedded addresses sail through NAT untranslated and arrive wrong. Every new integration between the companies needs another row in the translation table, every troubleshooting session means mentally converting between real and translated addresses, and the whole arrangement quietly hardens into permanent infrastructure. Plenty of engineers have inherited a "temporary" merger NAT old enough to predate everyone still working there. Treat NAT as a tourniquet: exactly right for the emergency, and a sign of trouble if it is still on a year later.

The durable fix is renumbering: moving the acquired network, or occasionally both networks, into one address plan with no overlaps. The merger is actually a rare chance to do this well, because budget and executive attention are already pointed at integration. Resist the temptation to squeeze the acquired sites into whatever gaps your current plan happens to have. Carve them a clean, dedicated block with room to grow, following the same aggregation logic we used in our worked example of designing an IP plan from scratch. A structured target plan also gives every renumbering task an unambiguous destination, which matters when dozens of changes are in flight at once.

Execution starts with an inventory, and this step decides how painful the rest will be. You need to know every subnet and every address in use on the acquired network, and the documentation you inherit is usually a spreadsheet that stopped matching reality sometime around its third owner, the drift problem we dissected in why your team is still using a spreadsheet for IP management. Audit first, then sequence the moves by difficulty. Subnets full of laptops and phones renumber almost for free, because DHCP (Dynamic Host Configuration Protocol), the service that hands out addresses automatically, lets you point the whole subnet at a new range and devices simply follow; our guide to DHCP, static addresses, and reservations explains which devices fall into this easy category. Servers, printers, and infrastructure with hand-assigned addresses are the slow lane, since each one drags firewall rules, monitoring entries, and application configs along with it. Do the easy wins first, schedule the critical servers in maintenance windows, and watch each cutover carefully, because the window where old and new ranges are both live is prime season for the duplicate-address fights we covered in our guide to finding and fixing IP conflicts.

That leaves the awkward middle, which can stretch a year or more: two networks, increasingly intertwined, still using overlapping addresses. This is the moment for VRFs (Virtual Routing and Forwarding instances), the technology we explored in depth in VLANs vs VRFs: when you need overlapping address space. A VRF gives a router a second, completely independent routing table, so the same physical equipment can carry both companies' traffic with each 10.0.0.0/8 living in its own routing universe. Instead of maintaining two parallel sets of hardware or forcing all cross-company traffic through a fragile pile of NAT rules, you run a VRF for the legacy acquired network alongside your main one, and translation happens only at the single controlled seam where the two VRFs exchange traffic.

The transition state: both address plans on shared infrastructure

VRF "corp"  (your network, the target plan)
  10.1.20.0/24   Office printers
  10.8.0.0/16    Reserved for acquired sites  ← renumbering destination

VRF "acme-legacy"  (acquired network, untouched)
  10.1.20.0/24   Payroll servers              ← same CIDR, zero conflict
  10.1.30.0/24   Warehouse devices

         NAT seam between the two VRFs
  10.1.20.5 (acme-legacy) appears as 100.64.20.5 (corp)

Each renumbered subnet leaves "acme-legacy" and joins "corp".
When the legacy VRF is empty, delete it. The merger is done.

The VRF approach also gives the renumbering project a satisfying shape. Each migration window moves one subnet out of the legacy VRF and into the target plan, the NAT table loses a few rows, and the legacy VRF shrinks. Progress is measurable, the blast radius of any single change stays small, and the finish line is concrete: the day the legacy VRF holds nothing and gets deleted. Compare that with the all-NAT alternative, where the translation layer grows more tangled the longer integration continues, and there is never a clear moment when the merge is finished.

All of this depends on documentation that can hold two contradictory truths at once. For months, 10.1.20.0/24 legitimately means two different things, and your records have to capture both without confusion. A spreadsheet shows duplicate rows that look like mistakes, and most IPAM (IP Address Management) tools are little better, because they treat each subnet as globally unique and flatly reject the second 10.1.20.0/24, forcing you to track the acquired network somewhere else entirely, which recreates the original two-sources-of-truth problem. IPCraft was built with the VRF as part of the subnet's identity: uniqueness is enforced on the combination of network and VRF, so both companies' full address plans live side by side in one system. You create a VRF for the acquired network, import their subnets (the CSV import will happily swallow that inherited spreadsheet), and from then on you can filter the whole view by VRF, watch utilization in the target ranges as devices migrate in, and tag each legacy subnet with a custom field like migration: scheduled or migration: done.

Documenting the acquired network alongside your own

# Create a VRF to hold the acquired company's address plan
curl -X POST https://api.ipcraft.io/api/v1/vrfs \
  -H "Authorization: Bearer ipc_your_key" \
  -H "Content-Type: application/json" \
  -d '{ "name": "acme-legacy", "description": "Acme Corp network, pre-merger" }'

# Register their 10.1.20.0/24, even though yours already exists.
# The VRF makes it unique, so this succeeds instead of erroring.
curl -X POST https://api.ipcraft.io/api/v1/subnets \
  -H "Authorization: Bearer ipc_your_key" \
  -H "Content-Type: application/json" \
  -d '{
    "network": "10.1.20.0/24",
    "name": "Acme payroll servers",
    "vrf_id": "acme-legacy-vrf-uuid"
  }'

The same model pays off during the cutovers themselves. Migration scripts can ask the IPCraft API for the next free address inside the target subnet, scoped to the right VRF, so every renumbered server draws from the same authoritative well instead of someone's best guess, and the records update at the moment of the change rather than in a cleanup pass nobody gets around to. When an address looks suspicious at 2 a.m. mid-migration, the answer to "which network does this belong to" is a filter click instead of an archaeology project.

The survival recipe, then, runs in layers. Use NAT at a single controlled seam to give the business its connections in week one, and set an expiration date for it in writing. Stand up a VRF for the acquired network so both address plans coexist cleanly for as long as the transition takes. Renumber on the business's schedule, easy subnets first, with an inventory you trust and a target plan with room to spare. And keep one system of record that understands overlapping space natively, because the next acquisition is a matter of when. There is also a longer-term escape hatch worth planting now: in IPv6, whose enormous address space we explored in our guide to IPv6 address planning, organizations derive their internal prefixes from a 40-bit random number, which makes two merging companies overlapping about as likely as two strangers guessing the same lottery numbers. The companies that dual-stack today are quietly buying themselves a future where this entire article is unnecessary.