Visibility
See branches, circuits, applications, and policy from a more coherent operational view.
Multi-site connectivity
Managed SD-WAN services for multi-site control without DIY overhead.
Compare managed SD-WAN services, SD WAN as a service, and SD-WAN versus MPLS around your sites, applications, underlays, resilience, and support expectations. The non-hyphenated search phrase “managed SD WAN services” refers to this same managed service family.
What managed SD-WAN services bring together
Application-aware routing
Use diverse underlays and steer critical traffic according to the design rather than one fixed path.
Operational ownership
Define who monitors, changes policy, manages equipment, and owns escalations when something fails.
Managed SD-WAN and SD WAN as a service
Managed SD-WAN can simplify a network made up of different carriers, branch types, cloud applications, and failover requirements. SD WAN as a service typically combines platform licensing, edge equipment, monitoring, policy management, and support, often a better fit than DIY licensing when operations and escalation ownership matter as much as software features.
SD-WAN vs MPLS
SD-WAN vs MPLS is not a universal winner-take-all decision. Traditional MPLS delivers a private, carrier-managed network with consistent performance across sites, which is why some organizations retain it for latency-sensitive or regulated traffic even after adopting SD-WAN elsewhere. SD-WAN instead uses a mix of underlay connections (often standard internet alongside MPLS or DIA) layered with centralized policy and control, which is also what enables application-aware path selection rather than one fixed circuit carrying everything.
SD-WAN's practical advantage tends to be flexibility: adding a site or adjusting policy generally doesn't require the lead time an added MPLS circuit can involve, though that flexibility means more underlays and policy to maintain rather than a network left alone once configured. Neither architecture is universally cheaper, faster, more reliable, or more secure; the right fit depends on the sites, applications, and existing contracts involved. Many organizations don't choose one outright: keeping MPLS where its private-network characteristics still matter while running SD-WAN elsewhere, or layering SD-WAN over an existing MPLS circuit as one of several underlays, is a common hybrid path.
Application-aware routing and path selection
Managed SD-WAN services connect multiple WAN links (broadband, dedicated internet access, fiber, and wireless or 5G) into a single logical network, then apply policy to decide which traffic uses which path. Instead of routing everything down one default connection, the platform can steer traffic according to business requirements:
Voice and video calls
Voice and video calls can be pointed at the lowest-latency path available.
Cloud applications
Cloud applications can be routed for consistent performance.
Bulk transfers or backups
Bulk transfers or backups can be pushed onto a less time-sensitive link so they don't compete with real-time traffic.
When a path becomes unavailable or degrades below what policy calls acceptable, traffic can shift to another available underlay automatically, which is the practical form of SD-WAN failover in most deployments.
Exactly how granular this gets, what it can detect, how quickly it reacts, and which applications it can recognize and prioritize, depends on the specific SD-WAN platform and how it's configured, not on SD-WAN as a category. Two managed SD-WAN services can both offer "application-aware routing" and still behave differently once measured against a business's actual application mix and underlay combination.
Managed vs. self-managed SD-WAN
Neither approach is universally better. Organizations with an internal network team that wants direct control over policy and configuration, or that already has the staffing to handle multi-vendor carrier issues, may prefer to keep SD-WAN self-managed. Organizations without dedicated network staff, or that would rather have one accountable party for monitoring, changes, and outage response across every site, tend to be better served by a managed model. The right choice depends on what internal IT ownership actually looks like today, not on which option sounds more sophisticated.
Security and SD-WAN
SD-WAN platforms commonly support encrypted tunnels between sites and the ability to segment traffic by policy, so applications, guest networks, and internal systems don't all share the same flat access. Some platforms extend further into integrated security capabilities (inspection, threat filtering, or SASE-style integration) bundled with the WAN function itself. Which of these a given platform actually includes, and how well it performs each one, varies significantly by product and provider; not every SD-WAN deployment carries the same security feature set, and it's worth confirming what's actually built in versus what's marketed as compatible.
SD-WAN's encryption and segmentation are not a substitute for a broader security program. Firewalls, SASE, endpoint security, and identity controls generally still have a role even in a well-designed SD-WAN deployment; SD-WAN changes how traffic gets from one site to another and can enforce some policy along the way, but it doesn't automatically replace the security layers that protect what happens once traffic arrives.
Implementing a multi-site SD-WAN rollout
A multi-site rollout typically starts with an inventory of existing sites, circuits, and contracts, then identifying which applications actually need policy: voice, critical SaaS, and bulk data don't all need the same treatment. Routing and security policy get defined before any site goes live, edge devices are prepared, and sites are sequenced into the rollout rather than cut over all at once. Testing each site against its actual traffic, coordinating cutover so old and new paths don't conflict mid-transition, and monitoring after go-live catch problems while they're still isolated to one location. Phasing deployment (a handful of sites first, then the rest) is common and lets issues surface on a smaller footprint before they touch the whole network; there's no universal timeline, since it depends on site count and complexity.
What changes a managed SD-WAN quote
Site count is usually the starting point, but a managed SD-WAN quote is shaped by more than that. Site-specific requirements, the underlay circuits feeding each location, edge hardware, licensing or platform fees, and how much security is bundled versus priced separately all factor in. Monitoring and support scope, implementation work, and contract length round out the picture. Providers don't package or price these the same way; one may bundle security and support into a single tier while another prices them separately, so an accurate comparison depends on knowing what each quote actually includes.
Quote factors at a glance
- Site count
- Site-specific requirements
- Underlay circuits per location
- Edge hardware
- Licensing or platform fees
- Security bundling
- Monitoring and support scope
- Implementation work
- Contract length
Underlays, voice, and multi-site design
Illustrative example. Consider a hypothetical business with three kinds of locations: a headquarters, a call-heavy operations branch, and several small offices. It is not a SourceNet customer, and the choices below are questions to work through, not a recommended design. The central lesson is that standardizing policy across sites does not require buying the same circuit everywhere. Each location needs its own answer for its primary path, whether a backup is justified, and whether that backup is independent enough to protect against the failure it is meant to cover.
Headquarters
Primary path: heavier cloud use, voice, and more users on one site could justify evaluating dedicated internet access where committed capacity and service commitments matter, or business fiber where shared service meets the requirement.
Backup path: the impact of an outage might justify a second wired circuit, a wireless path, or both.
Diversity check: if the primary fails, what path remains? Does the second circuit use the same building entrance or share upstream facilities? Do the router, firewall, and SD-WAN edge still have power?
Call-heavy branch
Primary path: whatever serves busy-hour calling and cloud applications at this address, which may differ from headquarters depending on what is available.
Backup path: because disruption stops day-to-day work, a second path is worth evaluating, and it has to carry voice acceptably, not just stay connected.
Degradation check: if the preferred path degrades rather than fails outright, what should policy do with calls and key applications?
Small offices
Primary path: business broadband or fiber may meet lighter requirements where available; the headquarters circuit may not be justified here.
Backup path: is a second wired circuit worth it, would a tested wireless backup better match the site's business impact, or is a short outage acceptable?
Diversity check: wireless uses a different access medium but still shares the site's power and local equipment, and may share upstream dependencies.
Those circuits are the underlay. Managed SD-WAN is the policy and operations layer on top of them: it can apply one set of policies across sites with different connections, identify applications, choose among available paths based on policy and measured path conditions, break SaaS traffic out locally rather than backhauling it, and give operations a common view of every site and circuit. It cannot create physical diversity the circuits do not have, and it does not make a weak connection better on its own. A different provider name or access medium is not proof of independence either.
An illustrative application policy
- Voice: higher priority, with path selection based on measured latency, jitter, loss, or path health.
- SaaS and cloud applications: the site's preferred path normally, with another available path used according to policy when the preferred one fails or degrades.
- Bulk transfers and backups: lower priority, possibly kept on a less critical path so they don't compete with real-time traffic.
Actual thresholds and behavior depend on the platform and its configuration.
Voice across the sites
Note where calling is hosted, in a cloud phone system or through SIP trunks to an on-site PBX, which sites depend most on calling, and how policy treats voice. Calls in progress may drop and need to reconnect after a path change, so test each backup with live calls rather than assuming calling carries over.
Questions to resolve before comparing proposals
- Which sites need committed bandwidth, and which can use shared business connectivity?
- Which sites justify a second path, and what failure is it meant to protect against?
- Are the paths actually independent, including building entry, upstream facilities, equipment, and power?
- Which applications need different routing treatment, and what should happen when a path degrades rather than disappears?
- Who writes and changes the policy: an internal team or the managed provider?
- How will each site's design be tested, including failover with live calls?
CISA's communications resiliency guidance recommends identifying shared links and evaluating alternate paths. Apply it site by site, and match the depth of the review to what losing each location would cost the business.
Build the network around the sites you have
How to compare managed SD-WAN providers
Managed SD-WAN providers are not interchangeable, and the labels on their marketing pages are close to identical. Most describe a platform, an overlay, some form of central policy, and a monitoring portal, and stop there. The differences that decide whether a rollout goes well sit underneath those labels, in how each provider handles underlays, escalation, and the operational handoff after go-live.
A fully managed SD-WAN service is the version where the provider owns the platform, the edge devices, the policy changes, and the day-to-day monitoring, usually as one contract and one escalation path. That is a different thing from a provider who supplies the license while someone else configures and runs it. The second arrangement is often sold as managed but works out closer to self-managed.
What the provider actually owns
For each item below, establish who owns it. Platform licensing, edge hardware, circuit procurement, policy authoring and changes, monitoring, troubleshooting, escalation to carriers. A managed service that leaves policy changes and carrier escalations on your side is a smaller service than the name suggests.
Underlay relationships
A provider that resells one carrier can only build one shape of network. A provider that already works across several carriers and access types can match the circuit to the site instead of matching the site to the circuit. The design options you get offered depend on which one you are talking to.
Support and escalation path
Multi-carrier networks fail in multi-carrier ways: a circuit drops, the underlay provider points at the overlay, the overlay provider points back. The question is whether one party owns that end to end, what the response commitments are, and who you actually call at 7am on a Monday. The time to establish this is before signing, not during the first outage.
What to resolve before comparing managed SD-WAN solutions
Two providers quoting the same site count can be quoting very different amounts of work, so the requirement gets fixed first. Once it is, the quotes line up and what is left is a real difference between providers rather than a difference in assumptions.
Fix the requirement first
- Site count, site types, and what each site actually does
- Which circuits already exist, and when those contracts end
- Applications that need different treatment from the default
- Whether each site justifies a second path, and against which failure
- Who writes and changes policy after go-live
- Who you will call when something breaks at a site
Then read each quote against the same list
- Is licensing bundled, per-site, or passed through at cost
- Is edge hardware owned, leased, or purchased outright
- Is security inspection included or priced as a separate layer
- What monitoring and support scope is written into the contract
- What implementation work is included versus billed as a project
- What contract length the pricing assumes
Providers package these differently on purpose. A headline monthly figure tells you very little until you know what is inside it.
Where a quote includes circuits, the comparison is not complete until equivalent addresses are priced. Committed bandwidth, access type, and service commitments move a circuit price more than the overlay sitting on top of it, so a cheap SD-WAN layer over an over-priced circuit is still an over-priced network. The same discipline applies to dedicated internet access at critical sites and business broadband or fiber where shared service fits.
Managed SD-WAN FAQ
What is managed SD-WAN?
A provider runs the software-defined overlay that connects your sites: it pulls two or more underlay connections per site into one logical network, applies policy to decide which traffic takes which path, and gives operations a single view across locations. A cloud managed SD-WAN service hosts that control layer in the provider's cloud rather than on an appliance you own. Managed means the provider owns the platform, the edge devices, policy changes, and monitoring, instead of supplying software for your team to run.
What does fully managed SD-WAN include?
Platform and licensing, edge equipment at each site, circuit coordination with the underlay providers, policy authoring and ongoing changes, monitoring, troubleshooting, and carrier escalation through one point of contact. The word fully does work the contract may not back up: some services described that way leave policy changes or carrier escalation with the customer, which makes them partly managed in practice.
How does managed SD-WAN differ from SD-WAN as a service?
Different providers use the two terms for different things. SD-WAN as a service usually describes the subscription shape: platform licensing, edge equipment, monitoring, and support bundled into a recurring fee. Managed SD-WAN describes who carries the operational load. The task list is what actually separates them.
What is the difference between managed SD-WAN and MPLS?
MPLS is a private, carrier-managed network with consistent performance across sites, still a reasonable choice for latency-sensitive or regulated traffic. SD-WAN uses a mix of underlays, often standard internet alongside MPLS or dedicated access, with centralized policy deciding which traffic takes which path. SD-WAN is more flexible to extend. MPLS is more predictable on one private network. Many organizations run both.
Is managed SD-WAN always cheaper than MPLS?
No. It can reduce cost where standard internet underlays replace expensive private circuits, and it can cost more where MPLS is retained alongside them, where security is priced separately, or where support scope grows. Compare circuits, licensing, hardware, security, support, and implementation rather than the overlay fee on its own.
Do we need SD-WAN if we only have a few sites?
SD-WAN earns its place when there is something to steer: multiple connections per site, applications that need different treatment, or several locations that should follow one policy. A small site count on its own does not create that. A business with two offices and one good circuit each may get more from improving those circuits than from adding an overlay.
Can managed SD-WAN replace our firewalls?
No. SD-WAN provides encrypted tunnels between sites and can segment traffic by policy, and some platforms bundle inspection or threat filtering. That is not a security program. Firewalls, endpoint security, and identity controls still have a role, and built in gets listed alongside compatible often enough that it pays to check which one a platform means.
Does SD-WAN work with our cloud phone system?
Generally yes, and voice is one of the clearer reasons to adopt it: call traffic can be pointed at the lowest-latency path and moved when that path degrades. Calls in progress may drop and reconnect after a path change, so test each backup with live calls rather than assuming voice carries over. Coordinate it with where calling is hosted, whether that is a cloud phone system or SIP trunking to an on-site PBX.
Ready to compare managed WAN paths?
Share your sites, applications, current circuits, and support model. We’ll frame the viable options.