When a company runs ten or more branch offices, the question of mpls vs sd-wan for multi-site businesses comes up almost every time our team sits down with a network group to plan the next year. Across the migrations we have supervised, SD-WAN tends to win on cost and flexibility once the site count climbs, while MPLS stays the better fit where a contractual SLA and very stable latency cannot be negotiated away. Most mid-sized estates we review end up with a hybrid design. The sections below explain how we get there without overpaying for capacity you do not need.
Which model fits your branch footprint?
We usually describe MPLS as a private highway that a carrier builds and maintains for you. Your traffic moves across infrastructure you never own, but the carrier stands behind how that traffic behaves. SD-WAN works from a different angle. It acts like a traffic controller positioned above several roads at once, such as ordinary broadband, fibre from a second provider, and sometimes a 4G or 5G backup. The controller decides, per application and per moment, which path each flow should take.
That single difference drives nearly every trade-off in the comparison. SD-WAN generally costs less per Mbps and brings a new branch online faster, provided the local transport is ready on arrival. MPLS offers contractual limits on uptime, latency and packet loss that consumer internet cannot match. We have watched teams keep MPLS only for the few sites or applications that cannot tolerate jitter, then move everything else onto an SD-WAN overlay. That split is often the cheapest route to stability.
Two technologies solving different problems
MPLS, specified in RFC 3031, forwards packets using labels instead of performing a full destination lookup at every hop. The carrier reserves capacity and manages service levels across its own backbone. You buy the circuit, and the carrier owns the path from end to end. That ownership is why the service feels predictable from the branch office.
SD-WAN is an overlay. It builds encrypted tunnels across whatever transports you already have and steers application traffic according to central policy. Vendor architectures differ in the details. When our engineers evaluate a product, they read the datasheet for the exact software release they plan to buy rather than trusting a general brochure. Feature support can shift noticeably between releases, and that shift has caught more than one project off guard.
How the two models compare on the criteria that matter
Cost, SLA, latency, failover, deployment speed, operational load and default security are the lines that usually reach the board. Read the comparison below as directional only, since real numbers depend on carrier contracts and on the region each site sits in.
| Criterion | MPLS | SD-WAN |
|---|---|---|
| Cost per Mbps | High, locked into long-term contracts | Lower, especially on broadband |
| SLA | Contractual on the private path | Depends on each underlying link, assembled by you |
| Latency and jitter | Stable and carrier-managed | Varies, improved by path selection |
| Failover | Routing protocol convergence | Probe-driven and per application |
| Time to deploy a new site | Weeks, sometimes months | Days, if the transport is ready |
| Operational complexity | Lower, the carrier handles the core | Higher, because controller and policy are yours to run |
| Default security | Private path, not encrypted by default | Encrypted overlay tunnels |
The trade-off is easy to state even if it is hard to live with. MPLS hands you predictability and asks you to pay for it. SD-WAN hands you flexibility and asks your engineers to run the controller well. The question worth settling is which of those costs your organisation can absorb more comfortably.
What the cost model really looks like
The line item on the carrier invoice tells only part of the story. On MPLS you pay a circuit fee per site and bandwidth tier, often on a three-year term, and the price rarely moves in your favour during that period. On SD-WAN you pay for edge appliances or licences, for two or more internet links at each site, and for the controller itself. Each link is inexpensive on its own, but the bill grows quickly once you insist on redundancy at every branch.
To compare fairly, calculate a three-year total cost of ownership for a realistic case. Take ten branches and include migration labour, the expense of running both networks during cutover, and training for the operations team. On one project we worked through, SD-WAN looked clearly cheaper on the spreadsheet. The advantage almost vanished once the internal team had to learn the controller from scratch. Budget that learning time honestly, or the savings will not show up where you expected them.
Reading the SLA fine print
An MPLS SLA normally covers uptime, latency, jitter and packet loss, measured between defined endpoints. The details that decide whether the promise means anything are where the carrier measures, how it reports results, and what credit you receive when it misses. In one contract our reviewers examined, the measurement point sat inside the carrier’s own network. That arrangement hid the last-mile problems the business was feeling every day.
A 99.9 percent uptime figure sounds strong until you do the arithmetic. It permits roughly 43 minutes of downtime in a month. Consumer broadband rarely carries a binding SLA at all, and even business broadband terms tend to be weaker. When you build SD-WAN on those links, resilience comes from owning several diverse links rather than from any single guarantee a provider signs for you.
How failover actually behaves
On a primary MPLS circuit with a backup, failover depends on the routing protocol running between your CE router and the carrier PE, typically BGP or OSPF. Convergence time is governed by timers and configuration, which makes the vendor defaults a poor thing to trust. We test them under load before any customer relies on them.
SD-WAN relies on continuous probes, often BFD or a vendor heartbeat, running between edge devices. When a path degrades, the controller moves affected applications to a healthier path. Switchover time varies by vendor and software release, so the figure on a sales slide is no replacement for your own lab measurement. Our rule is straightforward: measure failover on the exact hardware and software version you intend to deploy, using your real traffic mix rather than synthetic traffic that flatters the result.
A configuration sketch for the CE router
The fragment below illustrates how BFD can pair with a BGP neighbour on a Cisco IOS-XE style CE router. Syntax and feature support differ across vendors and releases, so check every line against the official documentation before it touches production.
! Enable BFD on the interface toward the carrier PE
interface GigabitEthernet0/0/1
bfd interval 300 min_rx 300 multiplier 3
!
! BGP neighbour with fast failover tied to BFD
router bgp 65001
neighbor 203.0.113.1 remote-as 65000
neighbor 203.0.113.1 fall-over bfd
neighbor 203.0.113.1 description MPLS-PRIMARY
!Read it as a map of the mechanism. BFD notices a dead link within a few hundred milliseconds. The fall-over bfd line then tells BGP to drop the session at once instead of waiting out the hold timer. That is the heart of fast MPLS failover, and the same principle reappears in many SD-WAN designs under different names. Whichever vendor you choose, ask how the controller detects loss and how quickly it acts on that signal.
Moving from MPLS to SD-WAN without an outage
We run migrations in three phases. First, we inventory traffic and classify each site by criticality. Second, we bring up the overlay alongside the existing MPLS and test failover by pulling cables inside a controlled maintenance window. Third, we shift policy gradually and keep MPLS as a fallback for the sites that matter most to revenue.
Every cutover step needs a rollback plan. The mistake we see most often is moving every site over a single weekend, then discovering a routing asymmetry on Monday morning when staff arrive. A staged rollout takes longer, but it spares everyone a very long day and a difficult post-incident review.
When keeping an MPLS core still makes sense
Some workloads belong on a private path. Voice conferencing, centralised ERP and financial transaction traffic react to jitter in ways a congested internet link cannot always absorb. Certain contracts and compliance regimes also demand a dedicated circuit, which settles the matter before any cost argument begins.
The hybrid design we recommend most often keeps an MPLS core for the data centre and high-criticality sites, and uses SD-WAN for the smaller branches. If you are deciding how much resilience the backbone needs beneath that design, our piece on hosting and infrastructure reliability covers the physical and hosting layers that support it. Teams that also need to validate their overlay under load can find useful background on network testing methods at Vietkey, which covers adjacent technical topics. For broader infrastructure reference, the wider network from e-pro.vn is another place to look.
Checklist before you decide
Before anyone signs a contract, work through these questions with the team. How many branches do you run, and what are the average and peak bandwidth requirements at each? Which applications are mission-critical, and what latency and jitter do they tolerate? What SLA do you genuinely need, and what does the three-year budget look like once migration is included? Does your team have the skills to operate a controller, or will you need an external partner for the first year? Finally, what is the fallback if the new design misbehaves during cutover?
Frequently asked questions
Can SD-WAN fully replace MPLS?
Sometimes. For many branches running ordinary business applications, SD-WAN across two or more diverse links is enough. Where a site needs a contractual private path, a full replacement may fail to meet the SLA, and a hybrid design is the safer route.
Is SD-WAN more secure than MPLS?
Not automatically. MPLS is a private path but is usually not encrypted by default. SD-WAN encrypts its overlay tunnels, yet its real security depends on key management, policy design and how well the controller itself is hardened. Each model needs its own set of controls.
Can I run SD-WAN over ordinary fibre internet?
Yes, and plenty of organisations do. Good fibre helps considerably, but measure latency and packet loss on the actual link before you commit, and keep a second link from a different provider wherever possible.
How long does a migration usually take?
It depends on the number of sites and the depth of testing. For a ten-branch company we typically plan several months, including a parallel run. Rushing the cutover is the surest way to stretch the timeline further.
Does a small business need MPLS?
Usually not. A business with one or two sites rarely recovers the cost of a private circuit. Good broadband, a backup link and a simple SD-WAN or VPN arrangement will serve most small teams well.