The Cutover Playbook: Migrating from MPLS to SD-WAN Without a Bad Weekend

The migration nobody wants to do live

Every other post in this series has assumed the SD-WAN fabric already exists. This one is about the messier moment before that’s true: the branch that’s still running on MPLS, the contract that’s coming up for renewal, and the project plan that says “migrate to SD-WAN” as if that’s a single step rather than a sequence of moments where things can go wrong in front of users.

The VeloCloud “MPLS-only site” material covered the destination — what a well-onboarded MPLS-anchored SD-WAN edge looks like once it’s running. This post is the Fortinet-side counterpart to the journey: how you get an existing MPLS branch from “working fine on the old thing” to “working fine on the new thing” without a maintenance window that turns into an incident.

The short version of the philosophy: never let “the new path is ready” and “the old path is gone” happen in the same change window. Every step below exists to keep those two events separated by enough time and validation that a problem in the new path is just a problem, not an outage.

Phase 0: build the overlay alongside the circuit you’re replacing

Before any traffic moves, the SD-WAN fabric needs to exist in parallel with the MPLS circuit — same branch, same FortiGate, both transports up and passing health checks, neither one carrying production traffic that depends on it yet. This is the hub placement and resilience design work made concrete at one site: stand up the overlay, validate BFD convergence, confirm performance SLA measurements are reporting sane numbers, and — critically — do all of this while MPLS is still the only thing actually carrying user traffic.

The validation gate before moving to Phase 1: the new transport needs to have been up, stable, and reporting clean SLA metrics for long enough that you trust the numbers aren’t a fluke. A circuit that “looks fine” for an afternoon and a circuit that’s been quietly solid for a week tell you very different things about whether it’s ready to carry production load.

Phase 1: shadow traffic, real measurement, zero user impact

This is the step people are most tempted to skip, and the one that saves the most pain later. Before cutting any production application over, run a deliberate measurement period where the new path carries test traffic — synthetic probes, the performance-SLA health checks themselves, perhaps a low-priority non-critical application — while everything that matters still rides MPLS.

What you’re building here is a baseline you can defend later: when something looks wrong during the real cutover, “is this the new path’s fault or did it inherit a problem the old path was hiding?” is a question you want to have already answered. A week of clean shadow-traffic metrics is the difference between “the new circuit is degraded, roll back” and “wait, was it always this noisy at 9 AM, and MPLS just absorbed it differently?” — a debate you do not want to be having mid-cutover.

Phase 2: route-map-based preference — the heart of the dual-running period

This is the actual mechanism that makes a graceful migration possible, and it’s worth being precise about. During the transition, both paths are reachable and both are valid — what changes, incrementally, is preference. Using route-map and routing-preference constructs (the same toolkit covered in the VRF and route-leaking material), you adjust which path wins the route selection for specific traffic classes, not all-or-nothing.

The practical sequence:

1. Lowest-risk traffic first. Pick an application class where a problem would be an annoyance, not an incident — general web browsing, a non-critical SaaS app — and adjust preference so it prefers the new overlay path while MPLS remains available as the explicit fallback.
2. Watch it for real, not just for a moment. Let that traffic class run on the new preference through at least one full business cycle — the load pattern at 9 AM looks nothing like 2 PM or end-of-month processing, and a migration that “worked” during a quiet Tuesday afternoon has told you less than it feels like it has.
3. Step up the risk class deliberately. Move to the next tier — business applications, then the traffic you actually care about — repeating the same watch-and-confirm cycle. Each step is independently reversible: change the preference back, and the traffic returns to MPLS within normal convergence time, because MPLS never stopped being a valid, reachable path.
4. Voice and latency-sensitive traffic last, not first. It’s tempting to “prove the new path works” by moving the most demanding traffic over early. Resist it — that’s exactly the traffic where a subtle problem is most visible to users and least tolerable. Let it be the last thing you move, once everything else has demonstrated the new path is solid under real load.

The reason this works as a playbook rather than a one-off heroic effort is that every single step is a preference adjustment, not a circuit removal. Nothing is destroyed; nothing is unreachable; the blast radius of a bad step is “this traffic class reverts to the path it was already happily running on five minutes ago.”

Phase 3: the soak period — the part that’s easy to skip and shouldn’t be

Once every traffic class prefers the new overlay path, resist the urge to immediately decommission MPLS. Run the dual-path state — new path preferred, MPLS present and healthy as fallback — for a defined soak period. A billing cycle is a reasonable yardstick: long enough to see month-end processing, any periodic batch jobs, and the kind of traffic pattern that only shows up once every few weeks.

This is the period where “we migrated” quietly becomes “we migrated successfully,” and the distinction matters enormously for what happens if something goes wrong six weeks later — you want to be debugging a problem on a fabric you’ve watched run clean for a month, not discovering that the migration was never really validated under full load.

Phase 4: decommission — the one-way door, treated like one

Only once the soak period is complete and clean does MPLS circuit removal belong on the change calendar. By this point it should be the least eventful step in the whole project — you’re removing a path that hasn’t carried meaningful traffic in weeks, from a fabric that’s already proven itself under full load across a complete business cycle.

If decommissioning doesn’t feel like an anticlimax, that’s a signal worth listening to — it usually means one of the earlier validation gates was rushed.

Rollback triggers — decide them before you need them

Define, in writing, before Phase 2 begins, the specific conditions that trigger a preference rollback for a given traffic class: an SLA threshold breach sustained for a defined duration, a specific error-rate increase, a user-reported quality issue that correlates with the cutover window. Write these down before the migration starts, not while you’re staring at a dashboard during it — a threshold decided in the calm of a planning session is a judgment call; the same threshold improvised mid-incident is a guess dressed up as a decision.

Because every step in this playbook is a preference change rather than a circuit removal, every rollback is the same simple action: revert the route-map preference, confirm convergence, traffic returns to the path it was running on minutes ago. That symmetry — every forward step has a trivial reverse — is what makes the whole migration low-drama. It’s also exactly what Phase 4 throws away, which is the real reason it comes last.

What this playbook deliberately doesn’t cover

This is the cutover mechanics — the during. It assumes the before (an SD-WAN design that’s actually sound for the site in question — see hub placement and the resilience series) and sets up the after — which is exactly where FortiAnalyzer/FortiMonitor SLA observability comes in: once you’re running on the new fabric full-time, that’s the tooling that tells you, with data rather than vibes, whether it’s still doing what the migration promised six months on.