The "MPLS to SD-WAN migration" project is one of the most common WAN modernizations underway in 2026. Most enterprises with MPLS contracts signed before 2022 have at least asked the question. Many have started the work. A meaningful fraction have abandoned the migration partway through and ended up running both, which is the worst of both worlds. This post is a decision framework, not a sales pitch: when to migrate, when to keep MPLS, and the seven-step transition that actually works.
For the SD-WAN architecture details, see the SD-WAN complete guide. For the MPLS L3VPN fundamentals, see the MPLS pillar.
The migration is not a 1-to-1 swap
The most common mistake is treating SD-WAN as a drop-in replacement for MPLS. They solve overlapping but not identical problems.
| What it does | MPLS L3VPN | SD-WAN |
|---|---|---|
| Transport | Dedicated carrier circuit | Overlay across any IP transport |
| Per-site bandwidth | What you ordered. Fixed. | Sum of all transports. Variable. |
| QoS | Carrier-enforced, end-to-end | Edge-enforced. Carrier sees IPsec tunnels. |
| SLA | Carrier-backed (loss, latency, jitter) | Per-transport SLA only. Overlay SLA is your problem. |
| Application visibility | None at the carrier; some at the edge | Deep app-level telemetry from controller |
| Path selection | Once per destination, by IGP | Per-application, per-flow, dynamically |
| Cost per Mbps | $30 to $100+ per Mbps/month | $1 to $10 per Mbps/month (broadband) |
| Install time per site | 30 to 90 days | Days, once edge device ships |
Read that QoS row twice. MPLS gives you carrier-backed CoS across the entire WAN, end-to-end, including the bits of the path you do not own. SD-WAN does not. SD-WAN's edge-enforced QoS works inside your IPsec tunnels but the underlying internet carrier has no idea you marked the packets, so once the packet leaves your edge it competes for capacity with whatever else is on that link.
When to migrate
The honest answer is: when SD-WAN's strengths outweigh MPLS's strengths for your specific traffic mix. The decision matrix:
| Your situation | Migration verdict |
|---|---|
| Most application traffic is SaaS (Microsoft 365, Salesforce, Google) | Migrate. SD-WAN with local internet break-out is the right pattern. |
| You have 50+ branches and an MPLS bill that is half your WAN cost | Migrate. Cost savings alone justify the project. |
| Greenfield expansion into geographies where MPLS provisioning is slow or expensive | Migrate the new sites only. Hybrid for existing. |
| Traffic is mostly client-server to a primary data center, latency-sensitive (real-time financial trading, VDI for low-tolerance users) | Keep MPLS for that traffic. Carrier-backed SLA matters here. |
| Regulated environment that requires circuit isolation auditable down to the provider's network | Stay on MPLS unless you can satisfy compliance with private SD-WAN overlays. |
| Branches in markets where broadband is unreliable or unavailable | Keep MPLS or 5G for those sites; migrate where transport options are healthy. |
The seven-step transition
The migrations that work follow roughly this shape. The migrations that fail skip step 3, step 5, or both.
Step 1: Inventory and classify
Catalogue every application traversing the WAN. Group them into: real-time (voice, video), interactive (SaaS, ERP), bulk (backups, file sync), and management (telemetry, monitoring). The classification drives the policy in step 5. Skip this and you will end up with a flat priority queue, which performs worse than the MPLS you replaced.
Step 2: Pilot, do not big-bang
Pick 3 to 5 representative branches. Different sizes, different geographies, different transport availability. Run them on SD-WAN for 90 days alongside the existing MPLS. Measure user experience, not just link metrics. SaaS application performance from each branch is the only metric that matters.
Step 3: Run hybrid for at least 6 months
Most failed migrations cut MPLS too fast. The right pattern is to spend 6 to 12 months in hybrid mode: SD-WAN overlay handling the policy and path selection, with MPLS still available as one of the transports under it. This gives you a fallback while you find the application-specific edge cases your inventory missed.
Step 4: Decide the data center pattern
How traffic enters and leaves the data center fundamentally changes the design. The two patterns:
- Aggregation hub: All SD-WAN edges terminate to a hub at the data center. Closer to a hub-and-spoke topology. Easier to migrate from MPLS where this was already the implicit shape.
- Mesh with cloud on-ramps: Edges peer with each other directly and with cloud provider PoPs. Better for SaaS-heavy traffic. Harder to make compliant.
Step 5: Build and test the policies before you cut over
This is where most migrations slip. SD-WAN policy is more powerful than MPLS QoS, which means more rope to hang yourself with. Spend time defining per-application path preferences, failover behavior, brownout detection thresholds, and per-tenant segmentation rules. Test them in the pilot environment under degraded-link conditions (use tc-netem to inject loss and latency on a test link). Watch how the overlay reacts.
Step 6: Cut MPLS in tranches
When you cut MPLS, do it 10-20% of sites per month. Each tranche should be similarly sized and geographically diverse so a regional broadband issue does not take down a whole tranche at once. Keep MPLS contracts on month-to-month for the final 3 to 6 months in case you need to roll back at a specific branch.
Step 7: Keep MPLS for the few sites that genuinely need it
Almost every "we migrated everything to SD-WAN" story ends with a footnote: "except the 5% of sites where MPLS made sense." That is the right outcome. Treat it as success, not failure.
Costs you will not see in the SD-WAN business case
Vendor business cases for SD-WAN are aggressive on circuit savings and quiet on the costs that are real but harder to model.
- Edge appliance and license costs. Vendor licensing per-edge can total 40 to 60% of the savings vs MPLS for small branches.
- Controller infrastructure. vManage, VCO, Prisma SD-WAN Cloud all have licensing and hosting costs.
- Operations retooling. Your NOC needs new dashboards, runbooks, and skill sets. Budget 6 months of dual-running.
- Multi-vendor friction. SD-WAN does not integrate with legacy WAN-side monitoring as cleanly as MPLS did. Expect to replace or extend monitoring tools.
- Internet circuit churn. Cheaper broadband ISPs have shorter SLA windows and rougher support. Plan for diverse ISPs per site even if it costs more per-Mbps.
When the answer is "do not migrate"
The conversation does not always end with "migrate." Genuine reasons to keep MPLS:
- You have 1 to 10 branches. The fixed costs of SD-WAN (controllers, licensing, retooling) do not amortize.
- Your applications are all on-premise and latency-sensitive. SD-WAN does not make a fiber circuit faster.
- Your existing MPLS contract has 3+ years remaining with high early-termination fees.
- Your compliance regime requires carrier-attested circuit isolation that broadband-based overlays cannot satisfy.
- Your team does not have bandwidth for a 12-18 month transition project right now.
Any one of these is sufficient to defer the migration. Two or more is a strong signal to keep MPLS for at least another contract cycle.
Key takeaways
SD-WAN replaces most of what MPLS used to do, but not all of it. The migration works when you treat it as a 12 to 18 month project with a long hybrid phase, not a circuit-swap. Inventory applications first. Pilot before committing. Keep MPLS where its carrier-backed SLA still earns its cost. Most enterprises end up with mostly-SD-WAN plus a handful of MPLS sites, and that is the right outcome, not a failure.
For the SD-WAN technology and config details, see the SD-WAN pillar.
