Transit Gateway was the right answer when enterprises first needed to connect dozens of VPCs. It is often the wrong answer once they are connecting hundreds — across regions, business units, and an IT/OT boundary. AWS Cloud WAN exists for that second phase. The migration between the two is entirely achievable without downtime, but only if it is sequenced as a routing project, not a provisioning project. This is the playbook we run.
Why enterprises outgrow the Transit Gateway mesh
A single-region Transit Gateway is clean. The trouble compounds with scale, and it compounds in three specific ways.
- Route table sprawl. Segmentation on TGW is expressed as route table associations and propagations, managed per gateway. At hundreds of attachments, the intended policy exists only in the accumulated state of many tables — and in the heads of the two engineers who built them. Reviewing what can reach what becomes archaeology.
- Cross-region complexity. Multi-region topologies require peering TGWs and maintaining static routes across the peerings. Every new region multiplies the mesh, and every route change must be replayed consistently in several places.
- No global policy. There is no single object that declares the intended segmentation of the global network. Policy is emergent from configuration, which means drift is invisible until something either connects that should not, or fails to connect that should.
Cloud WAN inverts this. A core network policy — one versioned JSON document — declares segments, attachment rules, and routing behavior for the entire global network. Segments (production, non-production, shared services, OT) replace hand-maintained route table sets, and attachments join them by policy or tag rather than by manual association. Global routing across regions is handled by the core network itself: no TGW peering mesh, no static route replay. The operational difference is categorical — the network becomes something you can read, diff, and review before you apply it.
Sequencing the migration
Five phases, in order, with a gate at the end of each. The order matters more than the pace.
| Phase | What happens — and the gate that ends it |
|---|---|
| 1. Inventory and route audit | Enumerate every attachment, route table, propagation, static route, and blackhole across all TGWs and regions. Gate: a reconciled map of intended vs. actual reachability, including the flows nobody documented. |
| 2. Segment design | Translate the audit into a core network policy: segments, sharing rules, isolation requirements. Gate: the policy document reviewed and signed off by network, security, and application owners. |
| 3. Parallel core network | Deploy Cloud WAN alongside the existing TGWs, connected but carrying no production traffic. Gate: test VPCs on the core network validate segment behavior end to end. |
| 4. Attachment-by-attachment cutover | Move workloads in waves — lowest blast radius first, one segment at a time, with per-wave rollback. Gate per wave: reachability and latency validation before the next wave begins. |
| 5. Validation and decommission | Prove no traffic remains on the old path, then remove TGW routes, peerings, and gateways. Gate: a quiet observation window before anything is deleted. |
Zero-downtime migration is not a technique. It is the discipline of never being in a state you cannot immediately reverse.
The pitfalls that cause the outages
Nearly every failed cutover we have been called into traces to one of four routing errors. Blackhole routes: stale blackholes copied forward from the TGW audit, or created transiently during cutover, silently drop traffic for one CIDR while everything else works — which is why per-wave validation must test specific flows, not just ping a bastion. Asymmetric paths: during coexistence, traffic can egress via Cloud WAN and return via TGW; stateful middleboxes and inspection appliances drop the return leg. Cut over both directions of a flow in the same wave. DNS: resolver rules and private hosted zone associations often assume the old topology; a workload that moves cleanly at layer 3 still fails if its names resolve to endpoints on the wrong side. Overlapping CIDRs: long-lived estates accumulate them, and the migration is the moment they surface. Find them in phase one — discovering an overlap mid-cutover converts a routine wave into an incident.
A fifth failure class is organizational rather than technical: cutting over an attachment whose application owner never confirmed its dependencies. The route audit in phase one is where undocumented flows surface — the batch job that talks to a VPC nobody associates with it, the monitoring path that only exists at month-end. Waves should be scheduled against the application calendar, not just the network team's, and every wave needs a named owner on the application side who signs the validation gate.
Principles that keep it boring
Run both networks in parallel for as long as validation requires; the cost of coexistence is small against the cost of an outage. Make every wave independently reversible, and rehearse the rollback, not just the cutover. Express everything — core network policy and attachments alike — as infrastructure-as-code, so every change is reviewed as a diff (a discipline we argue for generally in Remediation as Code). And treat validation gates as hard stops: a wave that fails its gate rolls back and gets diagnosed, it does not get patched forward under pressure.
What good looks like at the end
The end state is not just a migrated network. It is a network whose segmentation is declared in one reviewable policy, whose changes ship as diffs, and whose reachability questions have authoritative answers. Enterprises that arrive there stop treating the core network as fragile institutional knowledge and start treating it as an engineered system — which is what makes the next decade of growth, acquisitions, and OT integration tractable.
CAELION's AWS professional services team designs and executes Cloud WAN migrations end to end — audit, segment design, cutover, and validation, delivered as parameterized infrastructure-as-code. Talk through your topology in a private briefing.