Palo Alto Prisma SDWAN Deep Dive Part 7: The MPLS Cutover Playbook

The Cisco series ran this playbook against vManage templates and OMP convergence, and the Fortinet version ran it against ADVPN shortcut negotiation. The shape of a good cutover doesn’t actually change much between vendors — stage it, validate it, keep a way back — but Prisma SD-WAN has one structural advantage baked into Part 3’s Analytics/Control distinction that’s worth building the whole playbook around: the fabric exists and is fully instrumented before it’s trusted to make a single decision.

Phase 0: bootstrap

Zero-touch provisioning claims a new or replacement ION into a site in minutes rather than requiring a truck roll with a laptop: ship the appliance, connect it to WAN and LAN, and it phones home to Strata Cloud Manager using a claim ID or serial-based binding configured centrally beforehand, pulling its site configuration — circuit definitions, VLANs, initial policy — without a technician touching the device’s local config at all. For a multi-site MPLS-cutover project this matters more than it sounds like it should: the bottleneck in most cutover projects isn’t the network engineering, it’s coordinating truck rolls and site-local hands, and ZTP removes that constraint almost entirely for a straightforward branch.

Phase 1: Analytics mode — the baseline that isn’t a guess

Every new site comes up in Analytics mode first, non-negotiably, for a defined observation period — typically one to two full business cycles, long enough to see a real Monday-morning peak and a real end-of-month batch job, not just a quiet Tuesday afternoon. During this phase:

• Both transports are live and measured. The existing MPLS circuit and the new internet circuit(s) are both connected to the ION, both built into AppFabric, both under continuous bandwidth and link-quality monitoring from Part 4 — but neither is making path decisions yet. Production traffic keeps flowing exactly as it did before the ION was installed.
• App-ID builds a real inventory. What’s actually running at this site, not what the last network diagram said was running — the single most common surprise at this stage is discovering an application nobody remembered still depends on a specific circuit’s characteristics.
• App-Defined Policy gets authored against real numbers, not guesses — if a policy’s SLA thresholds for voice traffic would or wouldn’t have been met on the internet circuit during this window, that’s visible in Strata Cloud Manager’s Monitor views before it’s ever enforced.

This is the phase that answers “will this actually work here” with evidence rather than a vendor’s general assurance, and it’s the reason a Prisma SD-WAN cutover can be lower-drama than a cutover on an architecture where turning on the new path is the first time anyone finds out how it behaves.

Phase 2: flip to Control, per site

Once a site’s Analytics-mode baseline shows the new circuits genuinely meet the policy thresholds authored against them, that site — and only that site — flips to Control mode. This is where App-Defined Policy actually starts steering flows per Part 3’s per-flow mechanics, and where Adaptive QoS starts actively shaping against measured capacity rather than just recording it. MPLS stays connected and stays in the eligible-path set for anything that still needs it — this is a parallel-run cutover, not a flag day, and the same “MPLS as standby, overlay carrying production” pattern used on the Cisco and Fortinet playbooks applies here too. The difference is that on Prisma SD-WAN, “parallel run” doesn’t require any special dual-active configuration; it’s just Control mode with MPLS included in the eligible circuit set, exactly as if it were any other transport.

Per-site sequencing, not a single global cutover, is deliberate: a handful of pilot sites first — ideally a mix of site sizes and circuit qualities, not just the easiest one — followed by waves once the pilot sites have run clean for a defined validation window.

Phase 3: the validation window and the rollback boundary

Industry practice for this kind of migration — and it holds for Prisma SD-WAN specifically — is a full business-cycle validation period on the overlay before anything gets decommissioned, with a bounded rollback window per site (commonly around 30 days) during which MPLS stays physically connected and contractually live even though Control mode is now making the real decisions. If something genuinely goes wrong at a specific site during this window, the fix is a policy change or, worst case, flipping that one site back to Analytics mode — not an emergency truck roll to reconnect a decommissioned circuit that’s already been handed back to the carrier.

A representative mid-market project — the kind covering 5 to 25 sites — runs roughly three to six months from kickoff to final MPLS decommission across the whole estate, which is squarely in line with what the Cisco and Fortinet playbooks on this site describe for comparable scopes. The architecture doesn’t make the calendar dramatically shorter; what it changes is how much of that time is spent debugging surprises versus executing a plan that was already validated in Analytics mode before it had the authority to break anything.

Phase 4: decommission, per site

Once a site has run clean through its rollback window, decommissioning is mechanical: remove the MPLS circuit from the site’s eligible-path configuration (or delete the circuit object entirely if the physical circuit is being handed back to the carrier), confirm via Monitor → Paths that no flows are still attempting to place onto it, and close out the carrier contract for that site. Because App-Defined Policy was already evaluating eligible paths by circuit category and label rather than by a hardcoded preference for “the MPLS one,” removing MPLS from a site’s circuit set doesn’t require touching the policy itself — the same platinum-tier voice policy that was choosing between MPLS and internet during the parallel run simply has one fewer eligible option afterward, and continues enforcing the same SLA thresholds against whatever’s left.

The playbook, summarised

Phase	Duration (typical)	What’s live	What’s deciding
0. Bootstrap	Hours	ZTP claims the ION, pulls site config	Nobody — config only
1. Analytics	2–4 weeks per site	MPLS + new circuits, both measured	Existing routing/default path — fabric observes only
2. Control (parallel run)	4–8 weeks per wave	MPLS + new circuits, both eligible	App-Defined Policy, per flow
3. Validation / rollback window	~30 days per site	Same as Phase 2	Same — MPLS stays connected as a safety net
4. Decommission	Per site, after validation	New circuits only	App-Defined Policy, unchanged, fewer eligible paths

What’s next

Part 8 closes the series with the vendor-comparison capstone this whole series has been building toward: what happens when Strata Cloud Manager goes dark, where Prisma SD-WAN’s scale limits actually sit, and a direct, honest checklist against Fortinet’s collapsed model and Cisco’s fully decoupled one — the same rigor the Cisco series applied to its own failure modes and scale limits, turned on this fourth architecture instead.