MPLS to SD-WAN Migration Guide

Migrate MPLS to SD-WAN in phases: pilot 2-3 sites first, then expand region by region. Keep MPLS as a transport during migration — do not rip and replace. Expect 40-60% WAN cost reduction by replacing MPLS with broadband + LTE/5G. The biggest risk is underestimating last-mile broadband variability at branch sites. Budget 6-12 months for a 50-site migration.

MPLS (Multiprotocol Label Switching) to SD-WAN migration replaces dedicated, carrier-managed private WAN circuits with software-defined overlay networks running across commodity internet and broadband connections. The migration delivers 40-70% WAN cost reduction by replacing expensive MPLS circuits ($500-2,000 per site per month for 10-50 Mbps) with broadband internet ($100-300 per site per month for 100-1,000 Mbps), while simultaneously improving application performance through direct internet breakout, path selection intelligence, and WAN optimization. Every major enterprise WAN refresh in 2026 involves SD-WAN, and MPLS contract expiration is the most common trigger for SASE adoption because SD-WAN is the networking half of the SASE framework.

Cost comparison: MPLS vs SD-WAN

Phase 1: Assessment and planning (Months 1-2)

Start by inventorying your entire MPLS network: every site, every circuit, every contract term, every monthly cost, and every application that traverses the WAN. Map traffic flows between sites to understand which sites communicate with which data centers and cloud services. Identify your hub sites (data centers, regional offices with centralized services) versus spoke sites (branches that primarily access hub resources). Document the MPLS SLA for each circuit — you need to match or exceed this with your SD-WAN design.

Check MPLS contract expiration dates across all sites. Most MPLS contracts have 12 to 36 month terms with early termination fees that can be 50-100% of remaining contract value. Your migration timeline must align with contract expirations to avoid termination penalties. Group sites by contract expiration date and plan migration waves accordingly. Sites with contracts expiring in the next 6 months go first. Sites with 24+ months remaining go last, unless the early termination fee is less than the MPLS cost savings — do the math for each site.

Order broadband internet circuits for your first wave of migration sites immediately. Broadband provisioning takes 2 to 6 weeks depending on the ISP and whether the site has existing fiber or cable infrastructure. Order two circuits from different ISPs per site for redundancy. If the site is in a rural area where only one broadband provider is available, consider LTE/5G as the second transport — every major SD-WAN vendor supports cellular failover.

Phase 2: Hub site deployment (Months 2-3)

Deploy SD-WAN appliances at your hub sites (data centers, regional offices) first. These are the destinations that branch sites connect to, so they must be operational before you migrate any spokes. Configure the SD-WAN overlay network with your chosen topology: hub-and-spoke is simplest and works for most organizations, regional hub is better for geographically distributed organizations with regional data centers, and full mesh is appropriate when branch-to-branch communication is frequent. Most organizations start with hub-and-spoke and add mesh links selectively for sites with high inter-branch traffic.

Establish IPsec tunnels from hub site SD-WAN appliances to your SSE provider's nearest PoP. This is the integration point between SD-WAN (networking) and SSE (security) in the SASE architecture. All internet-bound traffic from branch sites will traverse the SD-WAN overlay to the hub, then egress through the SSE inspection stack. For SaaS applications (Microsoft 365, Salesforce, Google Workspace), configure direct internet breakout at the branch SD-WAN appliance to avoid the latency penalty of backhauling to the hub — this is one of the primary performance benefits of SD-WAN over MPLS.

Phase 3: Branch migration waves (Months 3-9)

Migrate branch sites in waves of 10 to 20 sites, grouped by geography, contract expiration, and risk tolerance. Each wave follows the same process: ship zero-touch provisioned SD-WAN appliance to the site, have local IT or a field technician rack and cable the appliance (WAN ports to broadband circuits, LAN ports to the local switch), the appliance phones home to the SD-WAN orchestrator and downloads its configuration automatically, verify connectivity to hub sites and internet, run MPLS and SD-WAN in parallel for 2 to 4 weeks to validate performance, then disconnect the MPLS circuit.

The parallel run period is critical. Do not cut MPLS on the day you deploy SD-WAN. Run both for at least two weeks and compare application performance, jitter, latency, and packet loss. Use your SD-WAN vendor's analytics to measure path quality across the broadband circuits and compare against your MPLS baseline. If broadband performance at a specific site is not meeting SLA requirements, you have the MPLS circuit as fallback while you troubleshoot — this might mean upgrading the broadband circuit, switching ISPs, or adding a third transport (LTE/5G).

Define clear go/no-go criteria for each wave before you start. Minimum criteria should include: all critical applications reachable from every migrated site, broadband circuit latency within 20% of MPLS baseline, packet loss below 0.1% on both circuits, and no more than 2 user-reported performance complaints per site during the parallel run. If a site fails these criteria, it stays on MPLS until the issue is resolved — do not force the migration.

Phase 4: Application-aware routing optimization (Months 6-12)

Once your branch sites are migrated, tune application-aware routing policies. This is where SD-WAN delivers performance that MPLS cannot match. Configure per-application SLA policies: voice and video traffic (Microsoft Teams, Zoom, WebEx) should use the lowest-latency path with jitter below 30ms and packet loss below 0.5%. Business-critical SaaS (Salesforce, SAP, ServiceNow) should use the path with lowest packet loss. Bulk data transfer and backup traffic should use the highest-bandwidth path regardless of latency. Recreational browsing and software updates should use whatever capacity is available without priority.

Enable direct internet breakout for SaaS applications. This is the single biggest performance improvement in an MPLS-to-SD-WAN migration. Under MPLS, traffic to Microsoft 365 from a branch in Denver routes through the MPLS network to a data center in Dallas, exits to the internet, and traverses the public internet to Microsoft's nearest point of presence — adding 80 to 150ms of unnecessary latency. With SD-WAN direct internet breakout, the same traffic exits the branch directly to the internet and reaches Microsoft's Denver edge in 5 to 15ms. Users notice this immediately in email responsiveness, Teams call quality, and SharePoint load times.

Common failure modes

Failure 1: Underestimating broadband variability

MPLS provides consistent, guaranteed bandwidth with contractual SLAs. Broadband does not. A 500 Mbps broadband circuit can deliver 480 Mbps at 2 AM and 200 Mbps at 2 PM when the neighborhood is streaming video. Cable broadband is particularly susceptible to contention ratios in residential areas where many branches are located. Mitigate this by ordering business-grade broadband with SLA guarantees, using dual ISPs on different infrastructure (one fiber, one cable), and configuring SD-WAN quality monitoring to detect degradation and fail over proactively.

Failure 2: Forgetting about non-IP protocols

SD-WAN operates at Layer 3 and above. If your MPLS network carries non-IP protocols — legacy mainframe traffic (SNA), industrial control protocols, or multicast-heavy applications (video surveillance, manufacturing systems) — these may not work over SD-WAN without additional configuration. Inventory non-IP traffic during Phase 1. Options include protocol conversion gateways, maintaining MPLS for the specific sites with non-IP requirements, or upgrading the applications to IP-based alternatives.

Failure 3: No rollback plan

Every site migration must have a documented rollback plan: if SD-WAN fails, how do you restore MPLS connectivity within 15 minutes? During the parallel run period, this is trivial — reconnect the MPLS router. After MPLS decommission, rollback requires re-provisioning the MPLS circuit, which takes 60 to 90 days. For the 6 to 12 months after MPLS decommission, maintain emergency LTE/5G connectivity at critical sites as a third transport that can sustain basic operations if both broadband circuits fail simultaneously.

Failure 4: Ignoring change management

Branch users and local IT teams are accustomed to MPLS reliability. When broadband has a brief interruption — even one that SD-WAN handles transparently through failover — users notice the momentary application pause and file tickets. Set expectations before migration: explain that SD-WAN uses multiple internet connections for redundancy, that brief failovers are normal and handled automatically, and that the performance benefits (more bandwidth, faster SaaS access) outweigh the occasional sub-second failover event. Without this communication, ticket volume spikes after migration and erodes confidence in the project.

Sources & further reading

• Gartner, "Magic Quadrant for SD-WAN" — gartner.com/reviews/market/wan-edge-infrastructure
• Cisco, "Catalyst SD-WAN Migration Guide" — cisco.com/c/en/us/solutions/enterprise-networks/sd-wan
• Fortinet, "SD-WAN Architecture and Deployment Guide" — fortinet.com/solutions/enterprise-midsize-business/sd-wan
• Cloudflare, "What is SD-WAN?" — cloudflare.com/learning/network-layer/what-is-sd-wan
• IETF RFC 4364 — BGP/MPLS IP Virtual Private Networks (VPNs) — rfc-editor.org/rfc/rfc4364

Related on sase.cloud

One email per publish. Unsubscribe anytime.