SD-WAN deployment models matter because the choice affects cost, complexity, user experience, and operational risk for years. The vendor sales pitch typically defaults to a single option ("internet-only with our SD-WAN", "hybrid with two MPLS legs") that aligns with what they want to sell. The right deployment model for your enterprise depends on which applications you run, where they live, what compliance regulations apply, and how mature your operations team is.
This article walks through the four main deployment models, the trade-offs each makes, the migration path from MPLS-only to a modern SD-WAN, and the patterns for HQ and data center sites. If you are designing a deployment or evaluating an existing one, this is the framework.
The Four Branch Deployment Models
| Model | Transport mix | Best for | Trade-off |
|---|---|---|---|
| Hybrid (MPLS + broadband) | 1 MPLS + 1-2 broadband + optional LTE | Established enterprises with hard-QoS apps; migration end-state | Higher cost than internet-only; better QoS for legacy real-time |
| Internet-only (dual broadband) | 2 broadband + LTE for tertiary backup | SaaS-heavy organizations; new branches; greenfield | No carrier-managed QoS; relies on SD-WAN path conditioning |
| Cloud on-ramp | Direct edge-to-cloud SD-WAN tunnels | Cloud-native applications; multi-cloud reach | Adds a new control point; cloud egress costs |
| Multi-cloud direct | Multiple cloud on-ramps in parallel | Multi-cloud workloads; cross-cloud latency-sensitive flows | Highest complexity; per-cloud agreements |
Hybrid: MPLS + Broadband
The hybrid model is the most common deployment in established enterprises in 2026. The pattern:
- One MPLS leg for hard-QoS-required traffic (voice, regulated workflows). Bandwidth right-sized down from MPLS-only days; often 50-100 Mbps where it used to be 200 Mbps.
- One broadband leg from a primary ISP. Higher bandwidth than MPLS, lower cost.
- One broadband leg from a secondary ISP for path diversity. Different physical infrastructure (different carrier, different last-mile).
- Optional LTE for tertiary failover when both wired transports fail.
SD-WAN policy steers per-application:
- Voice: prefer MPLS, fall back to lowest-jitter broadband
- Real-time business apps: prefer MPLS
- SaaS (Office 365, Salesforce, Zoom): direct internet break-out via broadband
- Internal apps: balanced load across all transports
- Default: best-available with SLA-based steering
This model is the typical end-state of a multi-year migration from MPLS-only. It preserves the operational guarantees of MPLS where they matter (which is fewer flows than people think) and uses broadband for everything else. Cost reduction vs MPLS-only is typically 25-40 percent over five years.
Internet-Only: Dual Broadband + LTE
Internet-only deployments skip MPLS entirely:
- Two broadband legs from different ISPs (carrier diversity matters; redundancy from one ISP is not redundancy).
- LTE for tertiary backup. Modern 5G branch routers make this practical.
- SD-WAN's path conditioning (FEC, packet ordering, jitter buffer) handles voice and real-time over best-effort links.
This model works well for:
- SaaS-heavy organizations with little on-prem real-time
- New branches where there is no MPLS contract to migrate from
- Retail, healthcare clinics, small offices where the cost of MPLS would be disproportionate
- International branches where MPLS is poorly supported
The risk: if both broadband links fail simultaneously (rare but happens during major regional outages), the branch is offline until LTE picks up or the ISPs recover. Most organizations decide that risk is acceptable given the cost savings.
One operational nuance: voice over best-effort internet works well 99 percent of the time and noticeably worse during the 1 percent of time when one transport is congested. Path conditioning helps but is not a complete substitute for carrier-managed QoS. If your business is sensitive to voice quality during peak hours, internet-only is not the right answer.
Cloud On-Ramp
The cloud on-ramp model adds direct connectivity from the SD-WAN edge to a cloud provider's network, bypassing both legacy WAN and the public internet for cloud-bound traffic.
| Cloud | On-ramp service | How it works |
|---|---|---|
| AWS | AWS Cloud WAN, Direct Connect, Transit Gateway | SD-WAN edge peers with AWS via dedicated circuit or VPN |
| Azure | Azure Virtual WAN | SD-WAN edge connects to Azure VWAN hub via VPN or ExpressRoute |
| Google Cloud | Network Connectivity Center (NCC) | SD-WAN edge peers with NCC; optional Cloud Interconnect for high bandwidth |
Most SD-WAN vendors have native integrations with the major cloud providers - vManage can provision an AWS Cloud WAN edge in a few clicks. The benefit: traffic destined for cloud workloads takes a direct path, not a backhaul-to-HQ-then-out path. Latency drops; user experience improves.
The cost: you pay the cloud provider for the on-ramp service (typically per-Mbps egress) on top of the SD-WAN platform license. For low-volume sites the math may not work; for high-volume sites it usually does.
Multi-Cloud Direct
Multi-cloud direct extends the on-ramp pattern: one SD-WAN edge, multiple cloud on-ramps in parallel. Policy decides which cloud serves which application.
This is the highest-complexity model and only makes sense for organizations that:
- Run workloads on multiple cloud providers (AWS for one product, Azure for another, GCP for a third)
- Have applications with cross-cloud dependencies (latency-sensitive flows that need to traverse cloud-to-cloud)
- Have the ops capacity to manage per-cloud on-ramp lifecycles
Most enterprises overestimate their need for multi-cloud direct. If 80 percent of cloud traffic goes to one provider, single-cloud on-ramp plus cross-cloud routing through that provider is simpler. Multi-cloud direct is for organizations that genuinely run substantial workloads on three or more clouds.
HQ and Data Center Patterns
Branch deployment models are about cost-optimized redundancy. HQ and data center sites have different concerns: aggregation, security inspection, redundancy, and inter-DC traffic.
Common HQ/DC patterns:
| Pattern | Use for |
|---|---|
| Active-active redundant edge pair | Default for any site with non-trivial traffic |
| Active-standby pair | Less traffic; simpler operations; failover under 30s |
| Geographically separated pair (different DCs) | Disaster recovery; protects against site-level failures |
| Hub-and-spoke with central security inspection | Compliance environments; legacy security architecture |
| Full mesh | Inter-branch heavy; modern collaborative organizations |
The hub-and-spoke pattern persists in compliance-driven environments where every flow must traverse a central inspection stack. Full mesh is more efficient for branch-to-branch traffic and is becoming dominant in modern deployments. Many enterprises run hybrid: full mesh between branches plus a hub-and-spoke leg back to HQ for centralized services.
Migration: From MPLS-Only to Hybrid (and Beyond)
The typical migration path from MPLS-everywhere to a modern hybrid SD-WAN:
- Audit and pilot (months 0-2). Identify hard-QoS-required traffic. Pilot SD-WAN at 5-10 branches across the geographies and traffic types you have. Validate that path steering does what you expect.
- Tune policies (months 2-4). Develop the per-application steering policy. Settle on transport SLAs (latency, jitter, loss thresholds for fall-over). Test failure modes.
- Roll out remaining branches (months 4-12). Add SD-WAN edges and broadband at every branch. SD-WAN runs over both MPLS and broadband initially. Train operators on the centralized control plane.
- Right-size MPLS (months 12-18). At each branch's MPLS contract renewal, downsize to the minimum needed for hard-QoS traffic only. Many branches drop from 200 Mbps MPLS to 50 Mbps.
- Phase out MPLS at suitable branches (months 18-30). Branches with no hard-QoS requirements eventually go internet-only. Keep MPLS at HQ and large hub sites where it still has a role.
The whole migration takes 18-30 months for a 100-branch enterprise, with most of the calendar time absorbed by waiting for MPLS contract renewals rather than the technical work. Doing it faster usually means paying early-termination penalties on MPLS contracts that often exceed the SD-WAN savings.
Anti-Patterns to Avoid
- Deploying SD-WAN over a single transport. If you only have MPLS or only broadband, SD-WAN buys you orchestration and policy but not the path-diversity story. The SD-WAN platform license might not pay for itself.
- Assuming broadband redundancy from the same ISP is real redundancy. It is not. Same last-mile, same regional fiber routes, same data centers. Get carrier diversity.
- Skipping the LTE backup. Modern LTE/5G branch routers cost a few hundred dollars per month and prevent the "both broadband links failed simultaneously" outage scenario. Worth it for any branch that affects revenue.
- Building hub-and-spoke when you should be full mesh. Forcing branch-to-branch traffic through HQ adds latency and load to the HQ inspection stack. Modern SASE-style cloud security inspection lets you full-mesh branches and inspect traffic at the edge.
- Migrating policy 1:1 from MPLS to SD-WAN. The legacy policy reflected legacy constraints. Re-think it with the new capabilities; don't just port the old QoS classes.
Summary
SD-WAN deployment models break into four patterns at the branch: hybrid (MPLS + broadband, the dominant pattern in 2026), internet-only (SaaS-heavy or greenfield), cloud on-ramp (cloud-native applications), and multi-cloud direct (multi-cloud workloads). HQ and data center sites use redundant edge pairs, with full mesh becoming the default branch-to-branch topology and hub-and-spoke persisting in compliance-driven environments.
The migration from MPLS-only to a modern hybrid SD-WAN is an 18-30 month project for most enterprises, paced more by MPLS contract renewals than technical work. Pick the deployment model based on your applications and compliance, not on the vendor's preferred sales motion. Bookmark the SD-WAN cluster pillar for the broader picture and the SD-WAN vs MPLS comparison for the cost analysis underlying these models.