SD-WAN vs. MPLS: When Each Still Makes Sense

The debate is framed wrong

The question is usually posed as "should we rip out MPLS and move to SD-WAN?" — as if one technology simply replaced the other. It did not. MPLS is a transport service you buy from a carrier. SD-WAN is an overlay that runs on top of transport — any transport, including MPLS. Treating them as competitors makes you miss the real decision, which is about which underlying circuits carry your traffic and how intelligently you steer packets across them.

Most mid-market and enterprise networks we take over are not purely one or the other. They are MPLS at a few anchor sites, broadband and LTE at branches, and a patchwork of policies nobody has revisited since the last carrier contract. The useful exercise is not picking a winner. It is understanding what each layer actually contributes so you keep what earns its cost and drop what does not.

What MPLS actually bought you

MPLS is expensive and slow to provision for a reason: it delivers a level of determinism that the public internet does not promise.

• Predictable latency and jitter. Traffic rides a private carrier backbone with an engineered path, not a best-effort route that can change mid-session. For real-time workloads — voice, video, trading, industrial control — bounded jitter is the whole point.
• Enforceable QoS end to end. With MPLS you can mark traffic and have the carrier honor those classes across their network. On the raw internet, your marking stops mattering the moment the packet leaves your edge.
• A private, any-to-any fabric. Sites reach each other over the carrier's Layer 3 VPN without the public internet in the path, which simplifies some compliance and trust arguments.
• A single accountable provider. One carrier owns the SLA end to end. When latency degrades, there is one throat to choke — and a contractual credit attached to it.

Those properties are real, and for a narrow set of workloads they still justify the premium. The problem is what they cost.

What MPLS cost you

• Price per megabit. MPLS bandwidth routinely runs many times the cost of commodity broadband or fiber for the same throughput. As application traffic moved to the cloud, paying premium rates to backhaul it became hard to defend.
• Provisioning time. A new MPLS circuit is measured in weeks to months, not days. Opening a branch, a pop-up site, or a temporary location on MPLS is painful; the network becomes the long pole in every expansion.
• Rigidity. Changes are carrier tickets. Adding capacity, re-pointing a site, or adjusting QoS classes is a change-management exercise, not a config push.
• The trombone problem. Classic hub-and-spoke MPLS backhauls internet-bound and cloud-bound traffic to a central data center for inspection, then back out. When your applications live in the cloud, that hairpin adds latency to exactly the traffic that grew the most.

How SD-WAN changes the equation

SD-WAN decouples the intelligence from the transport. Instead of one premium circuit per site, you give each location two or more paths — fiber, business broadband, LTE or 5G — and let an overlay decide, per application and in real time, which path each flow takes.

• App-aware routing. The edge identifies applications and applies policy: send voice over the lowest-jitter path, bulk backups over the cheapest, and send cloud SaaS straight out the local internet breakout instead of backhauling it.
• Sub-second failover with brownout detection. SD-WAN watches loss, latency, and jitter continuously. When a path degrades — not just when it dies — it steers active sessions to a healthier link, often without dropping the call.
• Path remediation. Techniques like forwarding error correction and per-packet load balancing let SD-WAN make two mediocre broadband circuits behave like one reliable link, recovering from loss that would wreck voice on a single path.
• Central policy, fast change. Policy is defined once and pushed to every edge. Standing up a new site is a matter of shipping an appliance and activating a broadband circuit, not waiting a quarter for a private line.
• Direct cloud on-ramp. Local internet breakout sends SaaS and cloud traffic to the nearest provider edge instead of tromboning it through a central hub. Our managed SD-WAN practice is usually deployed precisely to kill that hairpin.

The result is typically far more usable bandwidth per dollar, faster site turn-up, and routing that adapts to conditions instead of waiting for a human.

Where MPLS still fits

SD-WAN does not make MPLS obsolete. It makes MPLS a deliberate choice for specific traffic rather than the default for all of it.

1. Ultra latency-sensitive, jitter-intolerant traffic. Real-time control systems, certain financial workloads, and large voice or video estates that cannot tolerate even brief brownouts still benefit from an engineered private path with a hard SLA.
2. Single-region, site-to-site heavy topologies. If most traffic flows between a handful of campuses in one geography and very little goes to the cloud, MPLS any-to-any can still be clean and cost-competitive.
3. Contractual or compliance requirements that specifically call for a private circuit rather than encrypted transport over the public internet.
4. Broadband deserts. Where the only alternative to MPLS is thin, unreliable last-mile internet, the premium circuit may simply be the pragmatic option.

Even in these cases, the modern pattern is not "MPLS everywhere." It is MPLS where it is earned, SD-WAN managing everything on top.

The hybrid transport model most people should run

The strongest design for the majority of distributed organizations is hybrid transport: keep MPLS where determinism genuinely matters, add internet and cellular everywhere, and let SD-WAN treat them all as a pool of paths governed by one policy.

• Anchor sites — data centers, large campuses — keep MPLS plus internet.
• Branches run dual internet, or internet plus LTE, with no MPLS at all.
• Policy, not geography, decides paths. Critical real-time flows can prefer MPLS while everything else rides cheaper transport, and every site fails over automatically.

This lets you retire MPLS gradually, circuit by circuit, as broadband and SD-WAN prove themselves for each traffic class — rather than betting the network on a single cutover. For organizations operating across regions, tying this into a resilient global network backbone matters as much as the branch edge, because inter-region paths are where jitter and loss quietly accumulate.

The real convergence: security folds into the WAN

The most important shift is not SD-WAN versus MPLS at all. Once branches break out to the internet directly, you cannot rely on backhauling every packet to a central firewall for inspection. Security has to move to the edge with the traffic.

That is the logic behind SASE — Secure Access Service Edge — which merges SD-WAN with cloud-delivered security controls: secure web gateway, cloud access security, zero-trust network access, and firewall-as-a-service, enforced close to the user. The network decision and the security decision have become one decision. Choosing SD-WAN without a plan for edge inspection just relocates your exposure. A SASE architecture closes that gap by making policy follow the user and the application, wherever they connect from.

Making the call

Do not frame this as MPLS or SD-WAN. Frame it as: which traffic genuinely needs an engineered private path, and how do we run everything else more cheaply and flexibly on top of an intelligent overlay — with security enforced at the edge, not backhauled.

If you are staring at a renewing carrier contract or a network that hairpins cloud traffic through a data center it no longer belongs in, that is the moment to model the alternative. intSignal designs, migrates, and operates hybrid transport and SASE networks for organizations nationwide. Contact our team to map your sites, traffic classes, and circuits to a design that keeps determinism where you need it and stops paying for it where you do not.