Why Migrate from MPLS
MPLS delivers predictable performance, but it is expensive, slow to provision, and rigid — adding bandwidth or a new site can take weeks. Prisma SD-WAN lets you treat commodity broadband and LTE/5G as first-class transport by measuring each path continuously and steering applications over whichever circuit currently meets their SLA. The goal of a migration is to capture that flexibility and cost saving without a risky flag-day cutover.
A Phased Migration Strategy
The safe pattern is to introduce SD-WAN alongside MPLS, prove it, then shift dependence gradually.
Phase 1: Overlay in Analytics Mode
Install ION devices at the branch and bring up broadband as a second path, but keep production traffic on MPLS. Run the fabric in a measurement posture so it builds a baseline of latency, jitter, and loss per application across both circuits. You learn how broadband actually behaves for your apps before a single user depends on it.
Phase 2: Active/Backup
Begin steering non-critical applications (general web, software updates, backups) onto broadband while keeping latency-sensitive traffic on MPLS. This validates real user experience with a safety net: if a path degrades, SD-WAN moves the affected app back automatically.
Phase 3: Broadband Primary
Once analytics confirm broadband meets SLAs, flip the priority so broadband carries the bulk of traffic and MPLS becomes the backup for the most sensitive flows. At this point most sites are running on commodity transport with MPLS held only as insurance.
Phase 4: Decommission MPLS
For sites that have run stably on broadband through a full business cycle, drop the MPLS circuit — or downgrade it to a small backup. Do this site by site, never fleet-wide, and only after the data supports it.
App-Defined Path Selection
The engine that makes this safe is application-aware routing. Instead of routing by destination prefix, Prisma SD-WAN classifies traffic by application and applies a per-app SLA policy:
- Real-time apps (voice, video, virtual desktop) get the path with the lowest jitter and loss.
- Bulk transfers get whatever path has spare capacity.
- If a circuit's measured SLA falls below the app's threshold, traffic moves mid-session to a better path.
Define policies around application classes and business intent, not individual IPs. That keeps the policy small, readable, and stable as applications change.
Resilience and Failover
- Provision two diverse circuits per site (for example broadband plus LTE) so a single ISP failure does not isolate the branch.
- For critical branches, deploy ION devices in an HA pair to remove the device itself as a single point of failure.
- Test failover deliberately: pull a circuit during a maintenance window and confirm sessions survive and recover.
Pitfalls to Avoid
- Skipping the analytics phase. Cutting straight to broadband-primary without a baseline is how you discover, in production, that an ISP path is unfit.
- Migrating the whole estate at once. Go site by site; the blast radius of a mistake should be one branch.
- Forgetting security. Broadband means the branch now touches the internet directly. Pair the migration with cloud inspection (Prisma Access) so you are not trading cost savings for exposure.
- Policy by IP address. It does not survive contact with changing applications; model intent instead.
Summary
Moving from MPLS to broadband is a confidence exercise. Overlay SD-WAN first, let it measure, shift non-critical apps, then critical ones, and decommission MPLS only where the data earns it. Application-defined path selection and diverse circuits give you MPLS-grade experience on commodity transport — and a per-site rollback at every step.
Attique Bhatti
Enterprise Cloud Security Consultant and certified instructor across Palo Alto Networks, Check Point, and F5.
For architecture reviews or implementation support, email info@thecyberadviser.com.