SD-WAN and MPLS can work together. For a business comparing branch-network options, the first decision is which connections each location needs; the second is how traffic should use those connections. MPLS-based connectivity can be one of the transports underneath an SD-WAN service, alongside internet access.
Keep MPLS where its actual service commitments and measured performance justify it. Consider internet-based SD-WAN where available connections meet application and security requirements. Use a hybrid design when different sites or applications need different transport choices. The useful comparison is between complete network designs, including security and support.
What you are comparing: connectivity and traffic policy
In this discussion, MPLS means the provider-delivered IP VPN service businesses commonly use to connect locations. MPLS itself is a forwarding technology. RFC 4364 describes how a provider can keep customers' VPN routes separate while carrying their traffic across a shared backbone. A private VPN service does not mean every customer owns a physically separate network.
SD-WAN adds a policy-controlled layer over available connectivity. The MEF SD-WAN framework distinguishes the underlying network services from the SD-WAN edge that identifies application flows and applies forwarding policies. Those underlying services can include MPLS VPNs and internet access.
That distinction changes the buying question. Adding SD-WAN does not necessarily require canceling MPLS, and buying SD-WAN does not remove the need to buy and maintain usable connections. Ask which transport services a proposed design includes, which remain under your contracts, and who coordinates them.
Let application destinations shape the choice
Start with where people work and where their applications run. A branch accessing a private application at headquarters has a different traffic path from one using a public cloud application. MEF describes internet breakout as forwarding application flows directly to the internet instead of delivering them to another SD-WAN site.
For your own design, compare the intended paths rather than assuming every application should return to headquarters or every application should leave through the branch. A direct path may be useful, but its security controls, monitoring, and support must be part of the decision. A shorter diagram alone does not establish better application performance.
An existing MPLS service may remain appropriate for important private application paths if it meets the organization's requirements. An internet-based design may suit a branch whose applications and available connections support it. Neither choice should rest on a general claim that one technology is always faster.
Performance depends on the paths you can actually use
MEF 70.2 describes SD-WAN policies that consider delay, delay variation, and packet loss when evaluating paths. It also recognizes that underlying services have their own bandwidth limits and performance characteristics. An overlay can choose among paths; the quality of those paths still matters.
For a purchasing decision, ask for measurements from representative locations to the actual application destinations during busy periods. Define what acceptable service means for the work being performed: a voice conversation, an interactive business application, and a large background transfer have different needs. Have the application owner help set those criteria.
Read the proposed service commitments closely. Establish where measurements begin and end, what happens when a path degrades, and what support owns the investigation. Include both a complete outage and degraded performance in an agreed pilot. A design that works on its primary path still needs to demonstrate acceptable behavior on its remaining path.
Private connectivity and encryption answer different questions
A private MPLS VPN separates connectivity between customers, but the architecture does not itself encrypt the payload or prove that data was not altered in transit. RFC 4364 makes that boundary explicit: cryptographic protection requires additional measures.
For either network design, document which traffic needs encryption and where that protection starts and ends. Also identify the controls applied when users reach internet services. Transport selection, encryption, firewall policy, and threat inspection belong in the same design discussion, but one does not establish all the others.
Network Box USA's Managed Secure SD-WAN service combines policy-based connectivity with firewall, intrusion prevention, encrypted tunnels, traffic visibility, and operational support. Its published scope includes path selection, failover, branch visibility, and policy support. Exact circuit compatibility, coverage, responsibilities, and exclusions should be confirmed during solution design.
A hypothetical branch decision
Consider a hypothetical organization with headquarters and two branches. Its order-processing application runs at headquarters, while staff also use cloud collaboration tools. One branch has an MPLS connection that meets its private-application needs; the other is opening at a location with different connectivity options.
A reasonable proposal to evaluate could retain the first branch's MPLS connection, add a suitable alternate path, and use SD-WAN policies to govern the available routes. The new branch could evaluate internet connections against the same application requirements. Cloud traffic could use an approved internet path with the required security controls.
This is an illustration, not a customer result or a recommendation to mix transports everywhere. If the pilot shows that internet paths meet every requirement, retaining MPLS needs a clear business reason. If an important application cannot meet its requirements on those paths, a lower circuit quote alone does not settle the decision.
Compare the full operating commitment
Our recommendation is to compare proposals over the same period and scope. Include circuits, equipment, implementation, security services, monitoring, support, and any period when old and new services run together. Record contract constraints and the work your own team must still perform. SD-WAN does not establish a universal savings percentage.
Give fault ownership equal attention. When a branch reports a slow application, someone must distinguish a local issue from a transport, policy, security, or application problem and coordinate the next action. A technically sound design is easier to operate when those responsibilities are explicit.
If you are evaluating branch connectivity, contact our team to discuss how Managed Secure SD-WAN could fit your sites, application paths, and security requirements.