Two companies merge. Both use 10.0.0.0/16 for production and the networks must be connected. What are your options?

What is being tested

Whether you know that overlapping address space cannot be peered, and whether you can rank unattractive options honestly.

Why it is hard

Routing is based on destination address. If both networks contain 10.0.5.20, a router in either network cannot determine which one a packet is destined for. Peering and transit connections require non-overlapping ranges, and no configuration works around this.

The options, worst to best

1. Re-address one side. The clean end state and the most disruptive path. Every instance, every hardcoded address, every firewall rule, every DNS record, every partner allowlist. Realistically a multi-quarter programme with meaningful outage risk. Correct if the networks must be deeply integrated for the long term.

2. NAT between the networks. Present each side to the other through a translated range, so traffic crossing the boundary appears to come from a non-conflicting address. Works, and it is the standard tactical answer. Costs: no direct addressability (services must be reached through the translated address), broken protocols that embed addresses in payloads, painful troubleshooting, and a permanent piece of infrastructure that becomes load-bearing.

3. Connect only what must be connected, through gateways. Rather than joining the networks, expose specific services through API gateways, load balancers or private endpoints with public or dedicated addressing. Each integration is deliberate.

This is frequently the best answer and the least considered one. Most merger integration needs are a handful of service-to-service integrations, not full network reachability, and full reachability brings the other side's security posture into yours — which is a risk nobody usually prices.

4. Re-address incrementally, new workloads first. Allocate a fresh non-overlapping range, place everything new in it, and migrate the old ranges opportunistically. Combine with option 2 or 3 for the interim. Slower and far lower risk than a big-bang re-address.

The recommendation

Usually 3 plus 4: connect specific services now through gateways, allocate clean space for everything new, and migrate the legacy ranges over time without a flag-day. This delivers integration value in weeks rather than quarters and avoids a high-risk re-addressing project that may never be justified.

The lesson for the next design

Allocate address space from a registry, and size generously. Choose ranges from a documented plan that assumes future peering with networks you do not control — partners, acquisitions, providers. Address space costs nothing; overlapping ranges cost quarters.

And size for container density, not VM density. A subnet sized for 200 VMs is exhausted by a container platform where every pod consumes an address, which presents as pods stuck pending and gets diagnosed as a compute capacity problem.