Cisco Catalyst SD-WAN Deep Dive Part 9: The MPLS-to-SD-WAN Cutover Playbook

Parts 1–8 covered the steady-state architecture. Almost nobody gets to build that steady state on a greenfield network — most Catalyst SD-WAN deployments start with an existing MPLS estate that has to be migrated off without breaking production along the way. This post is the sequencing playbook for that migration.

The instinct to resist: a single big-bang cutover

The tempting plan is the simple one — pick a weekend, swap the CE router for a cEdge at every site, done. It’s also the plan most likely to produce an extended outage, because it collapses every risk (certificate enrollment failing, a TLOC not coming up over a circuit that’s never carried this kind of traffic before, a policy gap nobody noticed until traffic actually hit it) into one irreversible event across the entire estate simultaneously. The alternative this post argues for is coexistence: run the legacy MPLS path and the new SD-WAN fabric side by side, at the same sites, for a defined transition window, and migrate traffic deliberately rather than flipping a single switch.

Step 1: stand up cEdge alongside the existing CE router, not instead of it

At each site being migrated, the cEdge gets deployed as an additional device first — connected to a new transport (typically a fresh Internet circuit procured for the migration, or an existing secondary circuit if one already exists) while the legacy CE router keeps carrying production traffic over MPLS exactly as before. This gets the cEdge through certificate enrollment, vBond/vManage/vSmart bring-up (Part 1’s full sequence), and TLOC formation over the new circuit with zero production risk — if anything goes wrong at this stage, nothing the business depends on has moved yet.

Once the cEdge’s non-MPLS TLOC is healthy and the controllers see it as a normal fabric member, the MPLS circuit itself gets migrated onto the cEdge — physically re-terminated or handed off, with that TLOC’s color typically set to restrict per Part 3’s guidance, deliberately keeping this committed-bandwidth circuit reserved for known fabric members during a period when the topology is still in flux. The legacy CE router can stay racked and powered through this step, ready to take back the MPLS path if the cutover needs to reverse.

Step 2: sequence sites by risk, not convenience

The order sites get migrated in matters as much as the per-site mechanics. The pattern that holds up in practice: pilot on a small, non-critical spoke first — proves the design against real production traffic with a contained blast radius if something’s wrong. Once the pilot’s soak period (a week or two of normal business cycles, not just a clean morning) confirms the design, proceed in waves through the rest of the spoke estate, increasing in size and criticality as confidence builds. Hub sites migrate last, not first — a hub’s blast radius spans every spoke that depends on it, so it should only move once the migration process itself has been proven repeatedly elsewhere on lower-stakes sites.

This wave structure is the same underlying logic the Fortinet MPLS-to-SD-WAN cutover playbook already covers for FortiGate-based migrations — pilot, wave, hub-last, soak between waves — because the risk shape of “migrate a WAN transport without breaking production” doesn’t actually depend on which vendor’s controller is doing the OMP-equivalent route exchange underneath. The sequencing discipline is vendor-agnostic; only the bring-up mechanics (Part 1’s vBond/vManage/vSmart handshake here, versus FortiGate’s overlay/ADVPN bring-up there) differ.

Step 3: define rollback triggers before you start, not during an incident

Every wave needs an explicit, written-down rollback trigger — not “we’ll know it if we see it” but specific, pre-agreed criteria (sustained packet loss above X%, a critical application failing its SLA class for longer than Y minutes, a certificate or control-connection failure that doesn’t self-resolve within Z) that anyone running the cutover can act on without needing a judgment call mid-incident. Because the legacy CE router and MPLS path are still physically present through the coexistence window, rollback at any single site is just reverting that site’s default routing back to the CE router — which is the entire point of not decommissioning the legacy path on day one. MPLS decommissioning only happens after every site has soaked successfully and the rollback path is no longer needed anywhere in the estate.

A contrast worth naming: when there’s no DIA option to begin with

This whole playbook assumes the migrating site can eventually pick up a second, Internet-capable transport — that’s what makes coexistence (and later, DIA from Part 5) possible at all. The VeloCloud MPLS-only-site architecture covered elsewhere on this site is the scenario where that assumption doesn’t hold — a site with no Internet circuit, MPLS-only by design, migrating to an SD-WAN overlay that still has to ride entirely over the MPLS transport toward a partner gateway. The cutover mechanics there necessarily look different, because there’s no second transport to stand the new cEdge up on in parallel — coexistence in that scenario means coexistence on the same circuit, not across two.

Next

Part 10 closes the series: failure modes and scale limits worth knowing before you design around them, and a direct head-to-head comparison of OMP/TLOC against Fortinet’s ADVPN, Arista’s DMPO, and VeloCloud’s architecture — plus what’s coming next on this site.