MPLS and SD-WAN: Separate the Transport From the Overlay
An MPLS circuit is a transport; SD-WAN is policy above it. Separate underlay reachability, overlay tunnels and the contract before comparing prices.
MPLS and SD-WAN are not alternatives on the same list, which is why the comparison keeps going in circles. One is a forwarding technique sold as a private WAN service; the other is a control and policy layer that can run over that service, over broadband, over cellular or over any mix. Whether MPLS stays depends on what the business is buying, not on which logo appears on the diagram. Separate the layers first, and the decision becomes a set of concrete questions.
What MPLS means in a purchasing conversation
A provider MPLS VPN delivers a private service in which the carrier moves traffic between customer attachments and owns part of the routing responsibility. MPLS as a technology also appears inside enterprise networks, so the same word can describe something the company operates itself. That distinction decides who configures the labels and who answers the phone at three in the morning. Ask which attachment model applies, and write the answer down before discussing products.
Nothing about that service prevents an overlay from being built above it. The two live at different layers, which is exactly why replacing one does not automatically replace the other.
Draw the underlay before the overlay
The underlay is whatever actually moves packets between edge devices: provider handoffs, advertised prefixes, access circuits and the routing that makes them reachable. The overlay is the set of tunnels and site relationships built on top, together with encryption and topology choices. Policy sits higher still, deciding which application takes which path under which conditions. Read any proposed design by naming those three separately, because a label like SD-WAN names none of them.
Two sites can keep the provider WAN and add tunnels over it, swap selected circuits for broadband, or run several transports side by side. Each of those is a different project with a different cost profile and a different failure surface.
Turn the sales comparison into acceptance criteria
A comparison becomes useful when it turns into acceptance criteria. Build a table with one row per layer and fill it from the contract rather than from the brochure.
| Layer | Question to answer | Owner |
|---|---|---|
| Underlay | Which paths exist, which prefixes are advertised, what service level is committed | Carrier and network team |
| Overlay | Which sites and prefixes are reachable through tunnels, and how traffic is encrypted | Enterprise |
| Policy | Which application uses which path, and what evidence triggers a change | Enterprise |
| Operations | Who diagnoses a brownout, and what the escalation path is | Both, in writing |
Record what happens when the preferred path returns, because asymmetric or flapping selection is a common surprise after cutover. Include local internet breakout and central inspection in the same table, since they determine whether policy can actually be enforced. Compare total cost across circuits, edge devices, software, operations and recovery rather than the price of a single access line. A cheaper circuit does not by itself produce a cheaper service.
Failure independence belongs in the design
Two logical paths can share a last-mile conduit, a power feed or an upstream provider, and an overlay cannot route around a dependency it never had. Ask for the physical and provider diversity behind each circuit, then match it against the failures you actually care about. When both paths die together, steering logic has nothing left to steer. Put that limit in the design document instead of discovering it during an outage.
The finished drawing should show transport, overlay and policy as three separate bands, with contract terms attached to the lowest one. Then keeping, shrinking or removing MPLS becomes a decision someone can defend.