The traditional branch WAN was built around a private circuit, a router configured by hand, and a topology that carried everything back to a data centre because that was where the internet breakout and the security stack lived.
That design made sense when applications lived in the data centre. When most of what a branch user touches is a cloud service, hauling their traffic across the country and back to reach it is a tax on every packet.
What SD-WAN actually does
Uses more than one path. Broadband, private circuit, mobile, in combination, with traffic steered across them by policy rather than by routing protocol alone.
Measures the paths continuously and moves traffic when one degrades, on a timescale routing protocols do not operate on. A circuit that is up but losing packets is a case traditional routing handles badly and this handles well.
Steers by application. Video conferencing on the path with the best jitter, bulk backup on the cheap one, the critical application on the private circuit.
Centralises configuration. A branch device gets its policy from a controller. This, more than the circuit economics, is what changes the operating model: a change is made once rather than at every site.
Allows local internet breakout so cloud traffic leaves the branch directly instead of touring your backbone.
What the cost saving really is
The pitch is usually “replace expensive private circuits with cheap broadband”. Sometimes true, especially with many small sites.
Frequently what happens is different: you keep a smaller private circuit and add broadband alongside, and the saving comes from not upgrading the private circuit as demand grows. Less dramatic and more durable.
The larger saving is operational — configuration at hundreds of sites from one place, and branch devices that provision themselves — and it is the one that does not appear in the circuit comparison.
The part that deserves more scrutiny
The controller is now critical. Your entire WAN policy lives in it. Ask what happens when it is unreachable: well-designed systems keep forwarding on last known policy, but the answer varies and you want it in writing.
It is usually a cloud service. Which means your network management plane is a dependency on a vendor’s availability, in a region you may not have chosen.
Lock-in is significant. Devices, controller and licences come from one vendor and are not interchangeable. The migration cost out is real. This is a heavier commitment than replacing routers.
Security moved rather than disappeared. Local internet breakout means branch traffic no longer passes your central security stack. Something has to inspect it — on the device, or in a cloud security service. That is a second purchase and it is where the money actually goes in most of these projects. Whether the combined bill is cheaper than what you had is a question worth answering explicitly rather than assuming.
How I would evaluate it
Count your sites. Below a handful, the controller overhead is not obviously worth it. At dozens or hundreds, the central management case is strong on its own.
Look at where your applications are. If everything is still in your data centre, a large part of the value does not apply to you yet.
Price the security component in the same exercise, because the two decisions are not separable and vendors will happily let you make them separately.
Then ask the exit question: if this vendor relationship goes wrong in year four, what does it cost to change? Not because it will, but because knowing the number is what keeps the relationship healthy.