When SD-WAN beats MPLS

The choice between MPLS and SD-WAN is usually presented as old versus new. It is more useful to treat it as a question about where your traffic goes and how many sites you have, because those two variables decide it more than anything else.

What each actually gives you

MPLS is a private network service from a carrier. Its value is a contractual guarantee: committed bandwidth, a defined maximum latency and packet loss, and a support relationship where the carrier owns the problem. Traffic does not traverse the public internet.

SD-WAN is an overlay you run across whatever underlying connectivity you buy: broadband, fibre, mobile, and MPLS too. The intelligence sits in devices at each site that measure the available paths continuously and steer traffic across them based on policy.

The important distinction: MPLS is a service with a guarantee. SD-WAN is a technology that makes cheaper, less predictable connections behave better, and it can use several of them at once.

Where the numbers turn

Three variables decide it.

How many sites

MPLS pricing has a significant fixed component per site, and provisioning takes months. At three or four sites the total is manageable and the operational overhead is small.

At fifteen or twenty sites, particularly if some are small, the arithmetic changes sharply. The cost of an MPLS tail to a five-person branch is difficult to justify when broadband at the same site costs a fraction of it. This is where most organisations reach for SD-WAN, and the more sites there are, the stronger the case.

Where the traffic actually goes

This is the variable that changes fastest and is most often assessed on out-of-date assumptions.

MPLS was designed for an era when applications lived in a data centre and branches needed reliable access to it. Traffic patterns were predictable and mostly internal.

If most of your traffic now goes to cloud services (collaboration platforms, hosted business applications, cloud infrastructure), then backhauling it across MPLS to a central internet breakout adds latency and cost for no benefit. The traffic leaves your private network at the end anyway.

Measure this rather than assuming. The proportion of traffic that is internal versus internet-bound is usually the single most informative number in the decision, and in most organisations it has shifted substantially over the last few years.

How much you value a contractual guarantee

Some applications genuinely need predictable latency and low jitter: real-time voice and video, certain trading and industrial systems, and some legacy applications that behave badly on variable connections.

MPLS gives you a number in a contract and someone to call. SD-WAN across broadband gives you resilience through multiple paths and intelligent steering, which usually works well and comes with no equivalent guarantee.

If a specific application genuinely requires the guarantee, that is a strong argument for keeping MPLS at least for the sites that run it.

The honest hybrid

Most organisations do not choose one. They end up with SD-WAN as the overlay, using MPLS where the guarantee matters and broadband where it does not.

That is not indecision. It uses each for its strength: MPLS at the sites where predictable performance is worth the price, cheaper connectivity everywhere else, and the SD-WAN layer providing a single policy model, unified visibility and automatic failover across both.

It also makes the transition manageable. Deploying SD-WAN over existing MPLS gives you the management improvements immediately, and you can then replace individual MPLS tails as their contracts expire rather than all at once.

Costs people miss on the SD-WAN side

Licensing. Usually a subscription per site, sometimes tiered by throughput. Over a three to five year comparison this is material and it is often omitted from the initial calculation.

Hardware refresh. Appliances at each site, on their own replacement cycle.

Multiple circuits. SD-WAN resilience depends on having more than one path. Two broadband circuits per site are cheap relative to MPLS, but they are not free, and genuine diversity requires checking that the two providers do not share infrastructure.

Internet breakout security. This is the big one. Once branches connect directly to the internet, each becomes a point requiring security inspection. Traffic that used to be inspected centrally now needs a distributed answer, and that is a separate cost and project.

Operational skill. SD-WAN moves work from the carrier to you. Policy, troubleshooting and vendor management become internal responsibilities. Where MPLS meant raising a ticket, you now own the diagnosis.

A decision path

1. Measure your traffic split. Internal versus internet-bound, per site. If most traffic is internet-bound, MPLS is carrying it the wrong way.
2. Count your sites and their sizes. Many small sites favour SD-WAN heavily. Few large sites favour MPLS.
3. Identify applications with genuine latency requirements. If none, the guarantee is worth less than it costs. If some, note which sites they run at.
4. Cost both properly over three to five years, including SD-WAN licensing, hardware, circuits and the branch security answer.
5. Check contract expiry dates. These often dictate sequencing regardless of the preferred design.

The question to settle first

If branches will connect directly to the internet, decide how that traffic will be inspected before you deploy anything. Retrofitting security to a live direct-breakout deployment is considerably harder than designing it in, and an SD-WAN rollout that quietly removes centralised inspection is a step backwards even if the network performs better.