Juniper Session Smart SD-WAN Deep Dive Part 7: The MPLS Cutover Playbook

Part 6 covered cloud onramp. This post is the practical one this series has been building toward: how an organization actually gets from a legacy MPLS WAN to Session Smart Routing without the “bad weekend” this site’s Fortinet cutover playbook and the Cisco/Viptela equivalent both warned against.

The same staged principle, a different mechanism underneath

Every cutover playbook this site has published shares one non-negotiable principle: never cut a site over by removing its only working path first. That holds exactly as true for Session Smart Routing as it does for a tunnel-based overlay — but the mechanism of coexistence during the transition looks different, because SVR isn’t adding a tunnel alongside MPLS, it’s adding a session-aware routing layer that has to interoperate with whatever routing the MPLS circuit is already running.

Stage 1: SSR deployed alongside MPLS, not replacing it. An SSR is installed at each site with connectivity to both the existing MPLS circuit and a new internet or broadband transport, without touching the MPLS-based routing the site depends on for production traffic. This mirrors every other vendor’s “overlay first, cutover second” pattern — the difference is what “overlay” means here. Because SVR doesn’t require tunnel termination the way an IPsec-based overlay does, this stage is about getting SSR devices provisioned, ZTP’d against Conductor or Mist, and passing some real session traffic — deliberately low-risk traffic first — while the MPLS path remains fully authoritative for everything else.

Stage 2: tenant and service modelling, done before a single circuit changes. This is the stage that most distinguishes an SVR cutover from a tunnel-based one. Because Part 2 of this series established that tenant and service definitions are the policy — not a layer bolted onto an existing routing table — getting that data model right before cutover matters more here than it does for a tunnel-based platform where a misconfigured business-policy rule can often be patched live without disrupting reachability itself. A migration team should have every tenant (user/site/device groupings) and every service (application destinations plus SLA requirements) fully modelled and validated against non-production or pilot traffic before any site loses its MPLS fallback.

Stage 3: pilot sites, watched closely. A small number of representative sites — ideally covering the range of application mixes and SLA sensitivity in the estate — get cut over first, with MPLS kept live as fallback and monitored through WAN Assurance (if running Mist) for anything the tenant/service model didn’t anticipate. This is exactly the same pilot-first discipline the Cisco Catalyst cutover playbook and the Fortinet one both prescribe — the specific thing to watch for is different (session classification correctness rather than tunnel/route convergence behaviour) but the why is identical: find the gaps in a controlled blast radius before they show up at scale.

Stage 4: staged rollout by site cohort, MPLS decommissioned last. Sites move in waves, grouped by risk profile and business criticality, with MPLS retained at each site until its SSR-based path has been running cleanly for a defined burn-in period. Only once a cohort has demonstrated stable operation does that cohort’s MPLS circuit get formally decommissioned — never on the same change window as the cutover itself.

What SVR’s architecture specifically changes about the risk profile

Two things are worth calling out as genuinely different from a tunnel-based cutover, not just cosmetically different steps toward the same outcome.

No tunnel-convergence behaviour to characterize. A tunnel-based cutover has to account for how long it takes tunnels to build, how the platform behaves during tunnel flap, and what happens to in-flight sessions during a tunnel renegotiation — real engineering unknowns the IPsec deep dive series covers from the general case. SVR removes that specific category of unknown from the cutover risk assessment, because there’s no tunnel state to converge — a session either gets classified and forwarded correctly against the tenant/service model, or it doesn’t, and that’s a policy-correctness question rather than a protocol-convergence one.

More weight on pre-cutover policy validation, less on live troubleshooting. Because the tenant/service model is the routing decision (per Part 2 and Part 5’s zero-trust framing), errors in that model manifest as sessions simply not getting a path, rather than as a subtly misrouted flow that might silently work but violate intended policy. That’s arguably a safer failure mode for a cutover — a broken tenant/service mapping tends to fail loudly and immediately in testing rather than passing traffic incorrectly — but it puts real pressure on getting the modelling work in Stage 2 right before pilot sites go live, since that’s where most of the actual risk in an SVR cutover concentrates.

The closing lesson, same as every other vendor’s cutover playbook on this site

None of the mechanism differences change the underlying discipline: stage it, pilot it, watch it, and never remove the safety net until the new path has proven itself. Session Smart Routing changes what the migration team is validating in the run-up to cutover — tenant/service correctness rather than tunnel convergence — but not the fundamental shape of a responsible migration.

The final post in this series closes the whole Juniper arc: what actually happens when the Mist or Conductor control plane goes dark, where SSR’s scale limits sit, and a five-way comparison against Fortinet, Cisco/Viptela, Arista/VeloCloud, and Palo Alto/Prisma — the full set of SD-WAN philosophies now covered on this site.