MPLS (Multiprotocol Label Switching) dominated enterprise WAN design from the early 2000s. Its guarantees — dedicated bandwidth, deterministic latency, QoS-marked traffic classes, no internet exposure — made it the default choice for voice, video, and ERP traffic between branch offices. SD-WAN (Software-Defined Wide Area Network) challenges this model by abstracting the transport from the control plane, allowing commodity internet circuits to be orchestrated with intelligent per-application routing policies.

How MPLS Works (and Why It Worked)

MPLS labels packets at ingress to the carrier's network and switches them through a predetermined label-switched path (LSP) to the egress point. Unlike IP routing (which makes a per-hop forwarding decision based on destination IP), MPLS forwarding is predetermined — the path through the network is established when the LSP is signalled. This produces:

  • Predictable, low jitter latency — traffic doesn't compete with public internet congestion
  • Class of Service (CoS) — voice traffic (EF DSCP marking) is prioritised over best-effort bulk data across the carrier network
  • Privacy — traffic is never on the public internet; no encryption required (though recommended regardless)
  • Guaranteed bandwidth — committed information rate (CIR) is provisioned per site

The downsides: MPLS is expensive (3–10× the cost of equivalent internet bandwidth), has long provisioning lead times (weeks to months for new sites), and doesn't integrate natively with cloud-first architectures where traffic destined for SaaS applications or AWS must hairpin through the MPLS hub before breaking out to the internet.

SD-WAN Architecture

SD-WAN decouples the WAN control plane (routing decisions, policy) from the data plane (physical transport). Each branch runs an SD-WAN appliance (physical or virtual — Cisco Viptela vEdge, Fortinet FortiGate, Palo Alto Prisma SD-WAN, VeloCloud, Meraki MX). The appliances form encrypted overlay tunnels across whatever transport is available — MPLS, broadband, LTE, 5G.

The controller (cloud-hosted or on-premises) pushes routing policies to all edges. Application-aware routing identifies traffic flows and steers them: Teams/Zoom gets the lowest-latency path, backup traffic uses the cheapest path, SAP ERP is MPLS-preferred with internet failover.

Key SD-WAN capabilities:

  • Application-aware routing: Deep packet inspection identifies 1,500+ applications by signature. Routing decisions are made per-application, not per-destination-IP.
  • Dynamic path selection: Continuously monitors link quality (latency, jitter, packet loss) and shifts traffic when a link degrades below threshold — typically sub-second for active flows.
  • Zero-touch provisioning: Branch appliances call home to the controller on first boot, download their configuration, and are production-ready in minutes. No engineer on-site required.
  • Direct internet breakout: Branch sites can send cloud-bound traffic directly to the internet (with local firewalling) instead of backhauling through the data centre. This dramatically improves Teams, Salesforce, and O365 performance at branch sites.

The Migration Decision Framework

SD-WAN is not always the right choice. Evaluate based on:

  • Traffic profile: If your WAN primarily carries real-time voice and video between branches (not internet-bound), MPLS still wins on determinism. SD-WAN can deliver equivalent performance but requires careful link quality monitoring and per-application policy.
  • Number of sites: MPLS scales poorly operationally — each new site requires provider provisioning. SD-WAN scales nearly instantly. For organisations adding sites frequently, SD-WAN operational overhead is significantly lower.
  • Cloud adoption: If 60%+ of your WAN traffic is destined for SaaS or public cloud, routing it through an MPLS hub is actively harmful to performance and wastes expensive MPLS bandwidth.
  • Cost pressure: MPLS cost savings alone rarely justify migration (factoring in SD-WAN licensing, internet circuit upgrades, and project costs). Frame it as unlocking capabilities (cloud-first, direct breakout, ZTP) rather than purely a cost play.

Hybrid: Running MPLS and SD-WAN Together

The most common enterprise pattern: MPLS underlay for latency-sensitive and compliance-bound traffic, internet underlay (SD-WAN orchestrated) for cloud and SaaS. The SD-WAN overlay spans both transports. This provides MPLS reliability for critical workloads while gaining SD-WAN's cloud-optimisation and ZTP benefits.

Transition path: deploy SD-WAN alongside MPLS, prove performance parity on internet paths, then progressively reduce MPLS committed bandwidth or terminate sites as contracts expire. Full MPLS exit typically takes 18–36 months aligned with contract renewal cycles.

Sripadatech designs and migrates enterprise WAN infrastructure. Contact us to assess your WAN architecture.