How do you migrate from MPLS to SD-WAN without an outage?

Migrate from MPLS to SD-WAN in phases: inventory sites and applications, deploy SD-WAN edges over the existing MPLS plus broadband, pilot a few low-risk sites, add security at each local internet exit, then retire circuits only after measured performance holds. Treat the controller and branch security as part of the project, not a follow-up.

Why are teams leaving MPLS at all?

NIST SP 800-215 lists two limits of MPLS for enterprise wide area networks, in addition to cost. First, because MPLS is a separate network, it reaches the internet only through designated access points, which adds latency for time-sensitive applications. Second, it uses different appliances and configuration procedures, which makes management complex.

Those limits bite when most of your applications live in SaaS and cloud. Backhauling a branch's cloud traffic to a data center to reach the internet is a detour.

The same publication describes SD-WAN as removing the tight coupling between control plane and data plane, so policies for access control, routing and application priority can be specified centrally. It also notes that SD-WAN can use any transport, including MPLS, broadband, 4G/LTE and 5G.

That last point shapes the plan: you do not have to cut MPLS to begin.

What does a phased plan look like?

A constructed example: a company with 25 branches, a head office and two data centers.

Phase 1, discovery. List every site, circuit, bandwidth, contract end date and the applications that cross each link. Flag anything that depends on private addressing or MPLS quality of service, such as voice or legacy payment terminals.

Phase 2, design. Decide where each class of traffic exits: cloud services locally, data center applications over the overlay, guest traffic straight to the internet. Define segments and write one policy template per site type, not one for all.

Phase 3, pilot. Pick three branches: one small, one typical, one awkward. Install edges alongside the routers, add a broadband link, and send only non-critical applications over the new path at first.

Phase 4, waves. Move sites in groups of five to ten, with a rollback plan for each. Keep MPLS live as a second path during each wave.

Phase 5, retire. Cancel circuits only when contract dates allow and you have weeks of measured data, including a bad-weather week.

What do people forget?

Security is the usual miss. When branches break out locally, the inspection point moves from the data center to every site. SP 800-215 describes secure web gateway functions, firewall features and cloud access controls as components that may sit in the SD-WAN edge or in a cloud service. Decide which before the first site goes live.

Other common gaps:

• Controller access without multi-factor authentication.
• Edge devices provisioned with a shared default credential.
• Voice and video quality tested on a quiet Tuesday, not at peak.
• No monitoring of the underlay, so a broadband fault looks like an application fault.
• Contract termination fees and notice periods discovered after the cutover.

How do you handle contracts and cutover timing?

Circuit contracts often run for multiple years and can carry early termination fees, so the commercial calendar can drive the schedule more than the technology does. Build a table of renewal dates early. Where a contract ends soon, move that site first. Where it runs long, keep MPLS as the second path and ask the carrier about shorter terms or lower tiers. Also schedule cutovers outside peak business periods, tell site staff in advance, and keep an engineer on call for the first business day after each wave.

How to check or apply this

1. Build the site and application inventory, with owner and contract end date for every circuit.
2. Choose exit points per traffic class and write them down.
3. Define success measures before the pilot: latency, loss, jitter and user tickets per site.
4. Pilot three sites with MPLS still carrying critical traffic.
5. Confirm security controls at each exit, controller access and logging before wave one.
6. Move in waves with a rollback plan, then cancel circuits only after measured stability.

Quick check

Sources

• NIST SP 800-215, Guide to a Secure Enterprise Network Landscape

Last reviewed: 18 October 2026.