How It Works and When to Recommend It to Clients

~$9.3B Global SD-WAN marketin 2025 (Mordor Intelligence)

30%+ CAGR — fastest-growingnetwork segment

87% of enterprises deployedor deploying SD-WAN

77% prefer managed orco-managed over DIY

We’ve been in enough network conversations with MSPs to know that SD-WAN comes up a lot — and it gets talked about in two completely opposite ways. Either it’s the answer to everything, or someone had a bad implementation and now they’re skeptical of the whole category. Neither is quite right.

Here’s what is true: SD-WAN has genuinely become mainstream enterprise infrastructure. The global market is sitting at around $9.3 billion in 2025 and growing north of 30% annually. By 2024, 87% of enterprises had deployed or were actively deploying it. And the stat that should matter most to MSPs — 77% of companies would rather have a service provider handle it than go it alone. That’s not a niche anymore. That’s table stakes.

So this post is about the practical stuff. How SD-WAN actually works under the hood. What the comparison with MPLS actually looks like when you’re honest about it. When you should be recommending it to clients — and when you’d be doing them a disservice by pushing it. The vendor landscape as it stands today. And what managed SD-WAN delivery actually looks like when it’s done well versus when it falls apart.

1. What SD-WAN Actually Is (And Is Not)

The simplest way to explain SD-WAN: it separates the intelligence that decides where traffic goes from the pipes that actually carry it. Your routing policies, QoS rules, and application priorities live centrally in software. They get pushed automatically to edge devices at every site. The physical transport underneath — MPLS, broadband, 4G/5G, satellite, whatever you’re working with — is just the underlay. The SD-WAN layer sits on top and makes the smart decisions.

Worth getting out of the way early: SD-WAN is not a security product. It doesn’t replace your internal switching. And it genuinely cannot make bad internet good — we’ve seen clients assume otherwise and get burned. If the broadband at a remote office is unreliable, SD-WAN will squeeze the most out of unreliable broadband. That’s it. The underlay quality still matters.

Three Things That Actually Move the Needle

Application-Aware Routing. Traditional WAN treats a Zoom call and a nightly backup as identical — both just bytes on a wire. SD-WAN classifies traffic at layer 7 and routes based on what it actually is. Voice and video go over whichever link is performing best right now. Bulk transfers go over the secondary link. SaaS apps break out directly to the internet instead of hairpinning through your data center. That last one alone is often enough to close the conversation with a cloud-heavy client.

Multi-Link Failover. Old WAN: you had a primary circuit and a backup, failover took 30–60 seconds, and everyone in the office knew something went wrong. SD-WAN keeps every link active simultaneously. Failover happens mid-session, sub-second, and most users never notice. If your client has ever had a WAN outage kill their phones and remote desktops, this part of the pitch lands immediately.

Zero-Touch Provisioning. Spinning up a new site used to mean booking an engineer’s travel and waiting 60–90 days for the MPLS carrier to move. ZTP turns it into a box-and-ship operation — device arrives at the site, someone plugs it in, it phones home, config gets pushed. For clients running multi-site rollouts or absorbing acquired companies, this isn’t a feature, it’s a project economics transformation.

2. SD-WAN vs. MPLS: The Real Comparison

MPLS isn’t going away. But if you’re still presenting it as the default answer for every enterprise WAN situation, you’re doing clients a disservice. Here’s where the two actually sit:

Cost

High — dedicated private circuits billed by bandwidth

Low to moderate — commodity internet/broadband

SD-WAN wins

Deployment Speed

Weeks to months — carrier provisioning is slow

Hours to days — zero-touch provisioning

SD-WAN wins

Cloud Performance

Poor — traffic backhauls to DC before reaching cloud

Excellent — direct-to-cloud breakout, app-aware routing

SD-WAN wins decisively

Security

Inherently private — no internet exposure

Depends on design — needs SASE/FW/ZTNA layering

MPLS simpler; SD-WAN flexible with proper design

Scalability

Painful — new site = new circuit, months of lead time

Fast — new edge device ships, ZTP brings it online

SD-WAN wins

Visibility

Limited — carrier-managed, black-box telemetry

Rich — application-aware, deep per-flow analytics

SD-WAN wins

Table 1: SD-WAN vs. MPLS across key operational and commercial dimensions

For most clients, the transition answer is hybrid — keep MPLS where it genuinely earns its cost (high-stakes, latency-critical traffic in regulated environments) while shifting the majority of WAN bandwidth to SD-WAN over broadband. What’s harder to defend is a pure-MPLS environment where the primary use case is cloud apps. Routing traffic from a branch to an MPLS hub just to bounce it out to Azure or Salesforce is a design pattern built for a pre-cloud world. That’s the conversation worth starting.

3. How an SD-WAN Deployment Actually Works

The architecture is worth understanding — both for explaining it to clients and for not getting caught out when a vendor rep oversimplifies it. There are three layers that matter.

The controller is the brain. It’s cloud-hosted or on-prem, and everything flows through it: policy definitions, configuration, telemetry. Your team manages one dashboard regardless of whether you’re running 5 sites or 500. Policy changes propagate out to all edge devices automatically — usually in seconds.

The edge devices are at each site, doing the actual forwarding. They maintain encrypted tunnels to other edges and to cloud gateways, measure every link in real time (latency, jitter, packet loss), and make local decisions based on what the controller has told them. A well-designed deployment usually runs dual diverse-provider broadband as primary, with 4G/LTE sitting cold as failover — at a fraction of what an equivalent MPLS setup would run.

Then there are the cloud gateways and PoPs. Most enterprise SD-WAN platforms have PoP infrastructure globally. That’s how direct cloud breakout actually works — instead of sending O365 traffic from a branch office in Mumbai all the way to a data center in New York and back out to Microsoft, the edge device hands it off at the nearest SD-WAN PoP with direct Microsoft peering. The latency difference is immediate and measurable. Users notice.

Architecture in Plain English Branch site: Edge device with 2× broadband connections (different ISPs) + 4G backup Edge device: Classifies all traffic, picks the best path per application, encrypts everything Controller (cloud): Pushes policy, monitors all sites, provides a single management dashboard Cloud gateway: Intercepts SaaS/cloud traffic and routes it directly — no DC hairpin Remote users: Connect via ZTNA or VPN into the SD-WAN fabric — same policies apply

4. When to Recommend SD-WAN — and When to Hold Off

This is the part that separates advisors from salespeople. SD-WAN is genuinely the right answer for a lot of clients. It’s not the right answer for all of them — and pushing it where it doesn’t fit is one of the fastest ways to erode trust. Here’s how to read the signals:

MPLS costs eating 20%+ of networking budget

Classic cost-compression candidate; easy business case

Strong

Multi-site rollout planned (3+ new locations)

ZTP and centralized management pay off fast at scale

Strong

SaaS/cloud is primary app platform (O365, Salesforce)

Direct cloud breakout eliminates the backhaul tax

Strong

Active M&A integrating acquired networks

Rapid site onboarding without carrier lead times

Strong

Frequent WAN outages at branch sites

Multi-link failover and path health monitoring solve this

Strong

Client wants SASE or ZTNA

SD-WAN is the on-ramp; they go together naturally

Strong

Single site, no cloud workloads, stable simple LAN

Cost and complexity overhead not justified

Weak — don’t force it

Client IT team is very small or non-technical

Managed SD-WAN model fits perfectly

Strong (managed model)

The Single-Site Rule If a client has one location, think carefully before recommending SD-WAN. The management overhead and licensing cost rarely justify the benefit for a single site. The sweet spot starts at 3+ sites — that’s where the economics actually work. Exception: A single site heavily dependent on cloud apps that’s currently paying for MPLS as an internet pipe might benefit from direct cloud breakout — but that’s fixing a specific problem, not a full SD-WAN architecture play.

5. The Managed SD-WAN Opportunity

The stat here is worth sitting with: 75–80% of companies prefer managed or co-managed SD-WAN over handling it internally. The reason most of them give isn’t cost — it’s that they want 24×7 monitoring and proper SLAs without having to build the internal capability to back them up. That’s an MSP’s value proposition described almost word for word.

On the ground, managed SD-WAN is primarily a NOC discipline. You’re watching link health across every site, tracking application performance, getting ahead of capacity issues before they become user complaints, and responding when a branch tunnel degrades or a site drops its primary ISP. The quality of your delivery comes down almost entirely to the work you do before anything breaks — how alerting is configured, what triggers a ticket vs. an auto-remediation vs. a direct engineer page. Get that scaffolding right and the work is largely proactive. Get it wrong and you’re permanently reactive.

The co-managed model is worth building out explicitly as an offering. Let clients own Day 1 configuration approvals and major change management — give them control over what they care about — while your team handles the monitoring, incident response, and routine policy updates. In our experience, co-managed relationships tend to hold up better over time than fully managed ones. Clients stay more engaged, feel more ownership, and are much less likely to start treating the relationship as a commodity.

6. The Vendor Landscape — What You Actually Need to Know

The market has consolidated a fair bit. Here’s a practical read on the major platforms — not the marketing version:

Cisco Catalyst SD-WAN (Viptela)

Large enterprise, complex multi-cloud

Deep Cisco ecosystem, ThousandEyes observability

Licensing complexity, steep learning curve

VMware VeloCloud (now Broadcom)

Mid-market, VMware shops

Mature platform, broad MSP partner network

Broadcom acquisition uncertainty; watch roadmap

Palo Alto Prisma SD-WAN

Security-led, SASE-first orgs

Tightest SASE integration on the market

Premium price; overkill for smaller clients

Fortinet Secure SD-WAN

SME and MSP, budget-conscious

NGFW built in, excellent price/performance, FortiOS familiarity

Less feature-rich than enterprise peers at top end

Versa Networks

MSP/MSSP white-label, multi-tenant

Purpose-built for service providers, strong multi-tenancy

Less name recognition; longer client education cycle

Table 3: SD-WAN vendor landscape — practitioner’s guide

• VeloCloud/Broadcom — watch closely. Arista’s reported interest in acquiring VeloCloud from Broadcom (May 2025) is worth monitoring. Some partners have already started proactive client migrations. If you’re building on VeloCloud, have a contingency view.
• Fortinet is winning the MSP mid-market quietly. If your client base skews SME and they already have FortiGate gear in the environment, Fortinet Secure SD-WAN is hard to beat on price/performance. The integrated NGFW is a genuine advantage, not just a checkbox.
• Versa was built for MSPs, not adapted for them. Multi-tenancy is native, not bolted on. If you’re building a white-label managed SD-WAN practice at scale, the platform economics here work differently than with most competitors.

7. SD-WAN and SASE: You Can’t Separate These Anymore

SASE — Secure Access Service Edge — comes up in every serious SD-WAN conversation now, and it should. The idea is straightforward: instead of separating your WAN modernization from your security modernization, you do them together. SD-WAN handles the network transport and traffic intelligence. SASE layers in cloud-delivered security — secure web gateway, CASB, ZTNA, firewall-as-a-service — so every user, whether they’re at a branch, at home, or in a hotel in Singapore, gets the same policy enforcement through the nearest cloud PoP. No VPN hairpin. No security gap for remote workers.

The market is real — SASE sits at around $9.3 billion in 2025 and growing fast. And 70% of enterprise networking professionals in Futuriom’s 2024 survey said they see clear benefit in combining SD-WAN and SASE rather than treating them as separate projects. The clients who try to move to SASE without first addressing their WAN architecture tend to end up with a sophisticated security model sitting on a shaky network foundation. SD-WAN first, then layer SASE on top — that’s the sequence that works.

The Practical Takeaway If a client is already asking about zero-trust or wants to replace their VPN, SASE is the right framing — and SD-WAN is the on-ramp. Vendors with native SASE integration (Palo Alto Prisma, Fortinet, Versa) offer tighter policy consistency than bolt-on approaches. SASE is an 18–36 month journey for most clients. Don’t sell it as a single deployment. SD-WAN is typically Phase 1.

8. The Things That Will Bite You if You’re Not Ready

Vendor decks don’t talk about these. Every one of them has burned someone.

Rural broadband is still rural broadband. Before you propose tearing out MPLS at a remote office and replacing it with SD-WAN over broadband, actually check what broadband looks like there. Some locations have two options: mediocre and worse. In those cases, 5G fixed wireless or keeping MPLS is the honest answer.

QoS policy design is real work, not a wizard. Application-aware routing is only as good as the policies behind it. Enterprise environments commonly have hundreds of applications. Getting the classification and priority hierarchy right takes engineering time — and keeping it current as the application stack changes requires ongoing attention. Nobody’s going to tell you this in a sales demo.

Asymmetric routing breaks things. Active-active multi-link creates asymmetric routing scenarios that can break stateful inspection on firewalls not designed for it. If the SD-WAN edge isn’t also your firewall, design the integration carefully before you go live.

MPLS cancellation has teeth. Contracts typically carry 30–90 day cancellation notice requirements and minimum term penalties. We’ve seen projects where the client thought they were saving money immediately, then got hit with several months of dual-bill. Sequence the transition before you sign the client.

Multi-vendor environments are a long-term headache. EMA research found 43% of enterprises running multiple SD-WAN vendors — usually from M&A or accumulated decisions over time. These environments consistently show lower team satisfaction and more operational friction. Where you can standardize early, do it.

Final Thoughts

Most clients who are still running full-MPLS WANs with no cloud breakout strategy aren’t making a deliberate architectural choice — they just haven’t had the right conversation yet. The networks they’re running were designed before cloud was the primary application delivery model. They work, but they’re expensive, they’re slow to change, and they’re becoming harder to defend as SaaS and IaaS adoption deepens.

The MSPs who get traction with SD-WAN aren’t the ones who lead with the technology. They’re the ones who show up with the client’s MPLS bill, their outage history, and a concrete set of numbers around what cloud breakout would look like for their specific application mix. That’s a different conversation than a product demo, and it’s the one that actually closes.