Forty accounts are connected by a full mesh of VPC peerings - about 780 connections - and two business units both use 10.0.0.0/16 and reach each other through address translation. You must move to a transit hub with no downtime. What is the sequence, where can data or traffic diverge, where is the point of no return, and how long does it really take?

Why the mesh has to go, in one number

A full mesh of n networks needs n(n-1)/2 connections: 40 accounts is 780, and the 41^st account adds 40 more. Every one is a separate object with its own route-table entries on both sides, so the configuration surface grows quadratically while the capability stays flat. The limit is not a quota, it is that nobody can answer "what can reach the payments subnet" any more.

The sequence, each step reversible

1. Stand up the hub and attach spokes without changing a single route. An attachment carries no traffic until a route points at it. This step is pure addition and trivially reversible.
2. Build the hub's route tables to mirror today's reachability exactly, including the deliberate gaps. Reproducing the current graph first, rather than the intended one, keeps this migration separate from a segmentation redesign - which is the most common way these projects fail.
3. Cut over one pair at a time, in the route table of one side. Change the destination of a single prefix from the peering to the hub attachment, watch flow logs for that prefix for 5 minutes, then change the other side. Rollback is re-pointing one route.
4. Cut over in blast-radius order: lowest-value pairs first, then the long tail, then the pairs carrying production traffic, then anything on the payments or regulated path.
5. Leave the peerings in place, unused, for a quiet period evidenced by flow logs showing zero bytes on the peering for a full business cycle including month-end.
6. Then delete the peerings. This is the irreversible step, and it is cheap to delay.

Where traffic diverges, and how you would know

• Asymmetric routing. One side points at the hub, the other still at the peering. Return traffic takes a different path, and any stateful device on either path drops the flow. The symptom is connections that establish and then hang. Flow logs with accept and reject actions on both sides are the detection, and this is why steps 3's pauses exist.
• Transitive reachability appearing by accident. Peering is not transitive; a hub is. The moment two spokes are attached with permissive route tables, networks that could never reach each other can. This is a security change disguised as a connectivity migration, and it is why step 2 mirrors the existing gaps rather than opening the hub up.
• Overlapping CIDRs. This is the hard part. Two 10.0.0.0/16 estates cannot both be routed natively through one hub: the hub's route table has one entry for that prefix. Options are to re-address one estate, to keep the overlapping pair on a translation path indefinitely, or to isolate one of them behind private endpoints. Leave this to last and treat it as a separate project - it is where the schedule actually goes.

The point of no return

Deleting a peering. Everything before it is a route change. Postpone it until the quiet period has covered every periodic job - at least 30 days and through a month-end - because the quarterly batch that uses that path is not in last week's flow logs.

The decision rule: prefer the hub once the pair count makes reachability indescribable, which in practice is somewhere above 8 to 10 networks; below that a mesh is cheaper and fails pair by pair. Note the new costs honestly - at 2025 to 2026 list prices a managed transit hub charges per attachment-hour and per GB processed, where a peering is free after creation - so a petabyte-scale replication pair is often left peered deliberately alongside the hub.

How long it really takes

For 40 accounts with no overlaps: 6 to 10 weeks, dominated by scheduling the pair cutovers with 40 teams rather than by engineering. With the overlapping estate: add 4 to 9 months, because re-addressing a live /16 means touching hard-coded addresses, allowlists, partner firewall rules and certificates with IP SANs.

Common weak answers

• "Do it in one maintenance window." Forty teams, 780 objects and asymmetric-routing risk in one night, with rollback meaning re-creating peerings.
• "Redesign the segmentation while we are in there." Doubles the change and removes the ability to attribute any breakage to a cause.
• "Re-address the overlap first." Defensible, and it delays every other benefit by months. Migrate the 38 clean accounts first and let them stop paying the mesh cost.