A buyer’s guide · Operating since 2002
Most branch traffic is now cloud traffic. On a classic MPLS design every packet bound for a cloud application still travels to your data centre and back out again — paying latency twice and consuming expensive private circuit for traffic that never needed the data centre at all.
SD-WAN fixes that by steering each application across whichever links you have, by policy, on continuously measured quality. The saving is real. So is the consequence that rarely appears in the business case.
The argument
Why backhaul stopped making sense
The same branch, the same cloud application, two traffic paths. This is the whole business case in one picture.
What actually changes
Cloud-bound traffic leaves the branch directly. The private circuit carries only what genuinely needs the data centre, so it can be smaller, cheaper, or in some cases removed.
Users see lower latency to the applications they use most, because the traffic stops crossing the country twice to reach a service that was always going to be reached over the internet anyway.
What that creates
Fifty branches with direct internet access are fifty internet edges. Each needs inspection, patching, policy and monitoring — the things a single data-centre perimeter used to handle in one place.
That is not an argument against breakout. It is an argument for deciding how it will be secured before enabling it, because retrofitting branch security to a live estate is considerably more expensive than designing it in.
The comparison
MPLS vs internet VPN vs SD-WAN vs SASE
Four things routinely quoted against each other that are not the same category. Two are circuits, one is an overlay, one is a security service — and the honest limitation column is where each stops.
Scroll the table sideways →
| Option | What it is | What it does well | The honest limitation |
|---|---|---|---|
| MPLS | A carrier-managed private network between your sites. | Predictable latency and jitter with a contractual SLA. Still the best answer for latency-sensitive internal traffic. | Expensive per megabit, slow to provision, and it backhauls cloud traffic through your data centre for no benefit. |
| Internet + IPSec VPN | Site-to-site tunnels across ordinary broadband. | Cheap bandwidth, quick to turn up, available almost anywhere. | No SLA on the underlay, and failover is per-tunnel rather than per-application. A degraded-but-alive circuit is the worst case and it is common. |
| SD-WANthis page | An overlay that steers each application across whichever links you have, by policy. | Uses every circuit at once, fails over sub-second on measured quality, and breaks cloud traffic out locally. Central policy instead of per-router config. | Cannot create bandwidth or fix a bad underlay. And breakout gives every branch its own internet edge to secure — a cost rarely in the business case. |
| SASEthe adjacent layer | Security delivered from the cloud — secure web gateway, CASB, firewall and zero-trust access — usually with SD-WAN alongside. | Answers exactly the problem breakout creates, without a security stack in every branch. Follows the user rather than the site. | A different purchase and a different discipline. Covered separately on our SASE and ZTNA page rather than here. |
The distinction worth keeping: SD-WAN is transport and SASE is security. They are commonly sold together because breakout creates the problem SASE solves — but they are separate purchases with separate lifecycles, and conflating them is how organisations end up paying twice for overlapping inspection.
Straight answers
What buyers get wrong about SD-WAN
The saving is real; the security cost is rarely quoted
Local breakout is where most of the SD-WAN business case comes from, and it turns every branch into its own internet edge. That security — whether on the branch device or from a cloud edge — is a genuine line item, and business cases that count only the circuit saving are comparing an incomplete number.
“SD-WAN replaces MPLS”
Sometimes, eventually. More often the right answer for a while is hybrid: MPLS for the latency-sensitive internal traffic that genuinely benefits from it, broadband for everything else. Starting from the assumption of full replacement makes the decision before the data does.
SD-WAN cannot create bandwidth
It uses what you have far more intelligently — multiple links at once, per-application steering, sub-second failover on measured quality. It cannot fix a saturated circuit or a carrier with a bad local loop. If the underlay is the problem, the overlay will only tell you so more clearly.
“Is this SD-WAN or SASE?”
SD-WAN is transport: how traffic gets from A to B across the links you have. SASE is security delivered from the cloud for that traffic. They are commonly sold together and are separate decisions with separate lifecycles, and conflating them is how organisations end up paying twice for overlapping inspection.
A degraded circuit can hide for months
SD-WAN steers around problems so effectively that a link losing packets simply stops being used, silently, while you keep paying for it. This is a genuine operational trap and the reason continuous underlay monitoring belongs in the design rather than being discovered at renewal.
“What does a policy change take?”
The central-policy promise is most of why SD-WAN is worth buying. If a routine application-steering change is a five-day ticket in a managed service, you have swapped one operational constraint for another and kept the bill.
Deployment
How these projects actually run
Six steps, in an order that matters. Step five is the one most commonly done last and most expensive to retrofit.
Measure what you have
Application inventory and real traffic mix per site. Most organisations discover a large share of their MPLS spend is carrying cloud traffic that never needed to touch the data centre.
Design the policy, not the boxes
Which applications are business critical, which tolerate loss, which must never leave a private path. This is the whole design; the hardware follows from it.
Pilot on real sites
Two or three branches that differ from each other — a good circuit, a poor one, and one that matters. A pilot on three easy sites teaches you nothing.
Run hybrid deliberately
Keep MPLS for what genuinely needs it while broadband carries the rest. Full replacement is a decision to take later with data, not an assumption to start with.
Solve branch security before breakout
Local breakout without a plan is the moment your branch offices become internet-facing. Decide between on-box inspection and a cloud security edge before enabling it, not after.
Monitor the underlay continuously
SD-WAN steers around problems so well that a failing circuit can go unnoticed for months while you pay for it. Someone has to watch the links themselves.
Circuit provisioning is the long pole and it is outside everyone’s control, so it starts first. Design and policy work take longer than the rollout, which is the correct proportion — the policy is the product.
Before you sign
Ten questions for any SD-WAN provider
Use these on us and on everyone else. Question one is the one basic VPN handles worst, and question two is the one most proposals never answer.
What happens when a circuit is up but degraded?
This is the case that matters and the one basic VPN handles worst. Ask how quality is measured, how often, and what the failover threshold is in milliseconds of loss and jitter.
If we break out locally, what inspects that traffic?
The honest options are a security stack on the branch device or a cloud security edge. “The SD-WAN handles it” is not an answer — ask which inspection actually runs and where.
Can we see the application policy, not the topology diagram?
The topology is the easy part. The policy — which application takes which path under which conditions — is the product, and it is what you will live with.
What is licensed, per what, and for how long?
Appliance, throughput tier, security subscriptions and management platform are frequently separate lines with different terms. Ask for the three-year total.
What happens at renewal, and what is portable?
SD-WAN policy does not port between vendors. Understand what a change of platform in year four actually costs before signing a three-year deal.
Who owns the relationship with the carriers?
Multi-circuit branches mean multi-carrier faults. Establish who chases whom at 2 a.m., because the SD-WAN vendor will correctly say the overlay is fine.
How is configuration managed across all sites?
Central policy is most of the value proposition. If routine changes still need per-site work, you have bought expensive routers.
What do we see per application, per site, over time?
Without that, you cannot tell whether the policy is working or whether a circuit has been quietly degrading for a quarter.
How does a site migrate, and what is the rollback?
Ask for the per-site runbook and the rollback trigger. Branch cutovers go wrong on the mundane things — a static route, a printer, a payment terminal nobody mentioned.
If this is managed, what may you change without asking us?
A managed SD-WAN where every policy change is a ticket with a five-day turnaround is worse than the MPLS it replaced.
Working with us
How we run this
We have built enterprise branch networks since 2002 and we run the operations centre that watches them afterwards. That second part is why underlay monitoring is in our design rather than discovered at renewal.
Modelled against your circuits
The saving is calculated against your actual circuit inventory and traffic mix, including the branch security cost. Not a headline appliance price.
Branch security decided first
On-box or cloud edge, chosen before breakout is enabled. Retrofitting it to a live estate costs considerably more.
Hybrid by default
Keep MPLS where it earns its cost, move the rest. Full replacement is a decision to take later with a quarter of real data.
Fortinet and Cisco
Fortinet Secure SD-WAN most often, particularly where a branch firewall refresh means the security stack and the overlay can be one device. See technology partners.
Underlay watched continuously
A degraded circuit that SD-WAN quietly stops using is still on your invoice. We monitor the links, not just the overlay — see NOC as a Service.
You keep policy control
If we manage it, we agree before go-live what you may change without a ticket. Central policy you cannot reach is not central policy.
Questions we get asked
SD-WAN, answered
What is SD-WAN?
SD-WAN is an overlay that decides, per application, which of your available connections to use — broadband, MPLS, fibre, a mobile circuit — based on policy and on continuously measured link quality. Instead of static routes per router, you define intent centrally: this application is critical and needs the best path, this one tolerates loss, this one may go direct to the internet. The overlay then makes that happen at every site.
What is the difference between SD-WAN and MPLS?
MPLS is a carrier-managed private network with a contractual SLA on latency and jitter, priced per megabit and slow to provision. SD-WAN is not a circuit at all — it is software that steers traffic across whatever circuits you have, including MPLS. They are not alternatives in the way the marketing suggests: the real comparison is between an MPLS-only design and a hybrid one where SD-WAN uses cheaper broadband alongside a reduced MPLS footprint.
Does SD-WAN replace MPLS?
It can, and often the better first step is hybrid. Keep MPLS where latency-sensitive internal traffic genuinely benefits, move everything else to broadband, and let the overlay decide per application. Once you have a quarter of real measurement you will know whether the remaining MPLS is earning its cost — which is a much better basis for the decision than making it up front.
What is the difference between SD-WAN and SASE?
SD-WAN is transport — getting traffic from site to destination across available links. SASE is security delivered from the cloud for that traffic: secure web gateway, CASB, firewalling and zero-trust access, applied to users wherever they are. They are frequently sold together because breakout creates the problem SASE solves, but they are separate purchases with separate lifecycles. Ours is covered on the SASE and ZTNA page.
What is local breakout and why does it matter?
Local breakout means cloud-bound traffic leaves the branch directly instead of being backhauled to a data centre first. It matters because most branch traffic is now cloud traffic, and backhauling it pays latency twice and consumes expensive circuit capacity for traffic that was never destined for the data centre. It is where most of the SD-WAN business case comes from — and it is also what turns each branch into an internet edge that now needs securing.
What security do we need if we break out locally?
Something must inspect that traffic, and there are two honest answers. Either the branch device runs the security stack — firewall, web filtering, intrusion prevention — which works well when the device is capable and you are content managing policy across every site. Or a cloud security edge inspects it, which scales better and follows remote users too. What does not work is enabling breakout and deciding later; that gap is the most common real risk introduced by an SD-WAN project.
How much does SD-WAN cost in India?
It depends on site count, the throughput tier at each site, which security subscriptions you take, and whether the service is managed. The saving comes from replacing or reducing MPLS with commodity broadband, so the honest calculation is the delta against your current circuit spend rather than a headline appliance price — and it must include the branch security cost that breakout introduces. We will model it against your actual circuit inventory.
A note on “SD-WAN cost” in FortiGate configuration
Worth clarifying because it causes real confusion: in FortiGate SD-WAN rules, “cost” and “priority” are configuration metrics used to rank member interfaces when selecting a path. They have nothing to do with pricing. If you are searching for how link cost and priority interact in rule selection, that is a configuration question and we are happy to answer it — it is simply a different question from what the service costs.
Which vendor do you deploy?
We are a Fortinet partner and deploy Fortinet Secure SD-WAN most often, particularly where a branch firewall is being refreshed anyway and the security stack and the SD-WAN can be the same device. We also work in Cisco environments. The right answer depends more on what you already run, what your team can operate, and whether branch security is folded in or delivered separately.
How long does deployment take?
Design and policy work usually take longer than the rollout, and that is the correct order. Pilot two or three deliberately different sites — a good circuit, a poor one, and one that matters — then roll out in waves. Per-site cutover is typically short; what extends timelines is circuit provisioning, which is outside everyone’s control and should be started first.
Can you manage it after deployment?
Yes, and the question to ask any managed provider is what you may change without raising a ticket. Central policy is most of why SD-WAN is worth buying, so a managed service where routine application-steering changes take five days has quietly returned you to the constraint you were escaping. We agree that boundary before go-live.
How do we know a circuit is degrading?
You need monitoring of the underlay itself, not just of the overlay. SD-WAN steers around a failing link so effectively that it can stop being used entirely without anyone noticing, while the invoice continues. We fold circuit quality into the same 24×7 monitoring as the rest of the estate — see NOC as a Service.
Does SD-WAN help with remote workers?
Only indirectly. It is a site technology — it steers traffic between locations. Remote users need identity-based access to applications rather than a tunnel to an office, which is the zero-trust problem rather than the WAN problem. Organisations that try to solve remote access by extending the WAN generally end up with a flat network and a wide blast radius.
What is in scope for a first conversation?
Your site list with the circuits at each, roughly what applications matter, where they are hosted, and what you pay now. From that we can model the hybrid case honestly, including the branch security cost, and tell you whether the saving justifies the project at your size.
Next step
Send us the site list and the circuit bill
Your sites with the circuits at each, roughly which applications matter and where they are hosted, and what you pay now. We will model the hybrid case against those numbers — including the branch security cost breakout introduces — and tell you plainly if the saving does not justify the project at your size.