Many multi-site networks were built around a time when most business applications ran in the organisation’s own data centre. MPLS circuits connected branches to headquarters, where traffic could reach the systems employees needed.
That hub-and-spoke model made sense at the time. But with more work now taking place in SaaS platforms, public cloud services and video calls, routing branch traffic through head office can add unnecessary delay and cost. Changes can also take time to arrange, particularly when they depend on a carrier.
Software-defined wide area networking (SD-WAN) offers another way to manage those connections. It can steer traffic across different types of link, prioritise important applications and let branches connect directly to cloud services.
This guide explains how SD-WAN works, where MPLS and WAN optimisation still have a role, and how to choose between managed, co-managed and self-managed options. It also covers what to ask a provider before committing.
What SD-WAN replaces, and where MPLS still fits
Traditional enterprise wide area networks (WANs) often rely on carrier-provided multiprotocol label switching (MPLS). These services can offer predictable performance, defined classes of service and a clear point of accountability.
The trade-offs can include higher costs per site, longer provisioning times and changes that depend on carrier support. A hub-and-spoke design can also send cloud traffic through a central location before routing it back out to the internet.
SD-WAN doesn’t require you to replace MPLS altogether. Instead, it manages traffic across the available connections, treating each circuit as a potential route. An organisation might retain MPLS at its data centre or at sites with demanding real-time applications, while using business broadband or full fibre at branches, backed up by 4G or 5G.
MPLS may still make sense where predictable end-to-end performance is important, most traffic travels between private sites rather than to cloud services, or existing contracts make an early exit expensive.
The business case should weigh those factors against the benefits of changing the network. Replacing every circuit isn’t necessarily the right answer.
How SD-WAN works
SD-WAN combines centralised policy management with network devices that monitor available connections and steer traffic according to rules set by the organisation.
There are three main elements:
- Central policy management. A controller or orchestrator holds the rules for different applications. Voice traffic might use the link with the lowest jitter, for example, while backups use a lower-cost connection when one is available. Policies can then be applied across sites from a central interface.
- Edge devices. Physical or virtual appliances at each site establish encrypted tunnels across available links, which might include broadband, full fibre, leased lines and mobile connections. They monitor conditions such as latency, jitter and packet loss.
- Application-aware traffic steering. The edge identifies traffic and selects a route based on the relevant policy and current link conditions. Trusted SaaS traffic can break out locally to the internet rather than travelling through headquarters. If a connection degrades or fails, traffic can move to another link.
Failover performance varies by product, configuration and application. A network may switch links quickly without every application recovering seamlessly. Test the behaviour with your own services, particularly voice and video calls, rather than relying on a general claim of automatic failover.
SD-WAN also changes how the network is managed. Instead of configuring routers individually at every site, the team can monitor application performance and apply policy changes centrally.
Product terminology varies, so it helps to compare services against a shared set of definitions. Industry body Mplify, formerly MEF, publishes MEF 70.2, which defines SD-WAN service attributes and provides a common framework for comparing offerings.
WAN optimisation: where it helps and where it adds little
WAN optimisation predates SD-WAN, and the two solve different problems. SD-WAN selects a route for traffic. WAN optimisation aims to improve how efficiently that traffic travels over the connection.
Some SD-WAN products include optimisation features, while others offer them as additional licences or provide only selected capabilities, such as forward error correction.
| Technique | What it does |
| Compression | Reduces the volume of data sent across the link |
| Deduplication | Replaces repeated data patterns with short references held at each end |
| TCP optimisation | Reduces the effect of round-trip delay on throughput, for example by handling acknowledgements locally |
| Caching and protocol acceleration | Serves repeated content locally and reduces round trips for “chatty” protocols such as older file-sharing traffic |
| Forward error correction and packet duplication | Sends redundant data, or copies of packets across two links, so lost packets can be recovered without retransmission |
Where WAN optimisation can help
It can be useful on high-latency international links, where distance limits TCP throughput even when bandwidth is available. Legacy client-server applications and file shares can also benefit if they rely on many small exchanges between locations.
For voice and video over lossy connections, such as congested broadband or mobile links, forward error correction and packet duplication can help mask packet loss. These techniques use additional bandwidth, however, so the benefit needs to justify the cost.
Where it may add little
Much SaaS and web traffic is encrypted with TLS. Traditional compression and deduplication techniques generally can’t inspect the encrypted content, limiting what they can achieve unless the solution operates at a point where the data is available in an appropriate form.
Traditional optimisation may also depend on devices at both ends of a connection. That can be difficult when a branch connects directly to a SaaS provider, unless the provider offers optimisation through its own cloud infrastructure.
Where bandwidth is inexpensive and congestion is the main problem, adding capacity may be simpler than introducing another layer of technology.
Start by identifying which applications are slow and why. If latency or packet loss is the problem, optimisation may help. If the connection is simply overloaded, better traffic policies or additional bandwidth may be more effective.
Managed vs self-managed SD-WAN: a spectrum, not a binary choice
SD-WAN can be purchased as hardware, software or a service from a carrier, managed service provider or reseller. How much responsibility your team retains varies, with three common operating models.
Self-managed
Your team designs, deploys and operates the platform. This gives you direct control over configuration and policy changes, but you’ll need the right networking skills, monitoring processes and out-of-hours cover.
Co-managed
The provider handles agreed parts of the service, such as the platform, monitoring or circuits, while your team retains portal access and can make specified changes. This can suit organisations with networking expertise that don’t want to run a 24/7 operation.
Fully managed
The provider takes responsibility for most or all of the service, potentially including design, deployment, connectivity, monitoring and configuration changes. Your team raises requests rather than managing the platform day to day.
This reduces the internal workload, but the provider’s service levels and change processes become a bigger part of the experience.
The right model depends on the number of sites, how often policies change, the skills available internally and how much control the business wants to retain.
Whichever option you choose, agree the following in writing:
- Who can change policies, and how quickly? A two-day turnaround for a routing or firewall change might be acceptable for some organisations and too slow for others.
- Who monitors the network and handles incidents? Clarify where the provider’s responsibility ends, particularly when connectivity comes from third-party carriers.
- Which service levels and performance measures apply? Platform availability, circuit availability, incident response, time to restore and application performance are different commitments. Make sure the contract distinguishes between them.
- Who owns the devices and configuration? Leased hardware or configuration held by the provider can complicate a move to another service.
- What happens when the contract ends? Check configuration export, circuit contracts held in the provider’s name, notice periods, early-termination charges and handover arrangements.
What SD-WAN does and doesn’t secure
SD-WAN can encrypt traffic between sites and segment network traffic, but it shouldn’t be treated as a complete security solution.
Local internet breakout means branch offices can connect directly to the internet rather than routing everything through a central data centre. That can improve performance, but it also means security controls need to protect those connections wherever they originate.
There are two broad approaches. One is to use firewall capabilities built into the SD-WAN edge. The other is to combine SD-WAN with cloud-delivered security, such as secure web gateways and zero trust network access (ZTNA), to inspect traffic and control access to applications. ZTNA applies the zero trust principle of “never trust, always verify”, checking each request to reach an application rather than trusting traffic simply because it comes from inside the network.
Combining networking and cloud-delivered security is central to secure access service edge (SASE). SD-WAN is often one component of a SASE architecture, rather than an alternative to it.
Planning the migration
A phased migration allows you to test the new network while keeping the existing service available as a fallback.
- Discover. Inventory applications, traffic flows, current circuits and contract end dates. Identify which services are most sensitive to latency, jitter or packet loss.
- Design. Agree application policies, the security architecture and the mix of connections required for each type of site.
- Pilot. Deploy SD-WAN at one or two representative sites. Test normal operation, link degradation and failover using real applications.
- Run in parallel. Keep the existing WAN available while sites move across, with a clear rollback plan if problems arise.
- Roll out and decommission. Migrate sites in manageable waves, then retire legacy circuits when it is safe and commercially sensible to do so.
Circuit provisioning can be the longest lead item, particularly for leased lines, so start early.
Voice services need attention during the same planning process. Openreach has set 31 January 2027 as the date for the withdrawal of the traditional analogue phone network, and many organisations are reviewing their WAN alongside a move to cloud telephony.
Call quality depends partly on how the network handles voice traffic, so plan the two projects together.
What to evaluate in an SD-WAN provider
Use the same criteria for each shortlisted provider, whether you’re buying a platform or a managed service.
| Criterion | What to ask |
| Carrier-agnostic underlay | Can we use circuits from any carrier, including ones we already hold? |
| Application visibility and policy | How granular is application identification, and can we see per-application performance by site? |
| Tested failover | Can you demonstrate failover with our applications, including a live call? |
| WAN optimisation | Which optimisation features are included, which are licensed separately, and do they work on local breakout traffic? |
| Security integration | Is firewalling built in, and what is the path to cloud-delivered security or SASE? |
| Management portal and APIs | What can our team see and change, and can we integrate with our monitoring and service management tools? |
| Managed-service KPIs | What are the committed turnaround times for policy changes, incident response and service restoration? |
| UK support | Where are support and field engineering based, and what hours are covered? |
| Three-year total cost | What is the full cost, including circuits, hardware, licences, installation and management fees? |
| Exit terms | Who owns devices and configuration at the end of the contract, and how is handover managed? |
Compare the full service rather than the headline monthly price. A low-cost platform may require more internal engineering time, while a managed service may bundle connectivity and support but offer less flexibility over changes.
Ask providers to demonstrate the features that matter most to your environment, particularly application steering, failover and the visibility your team will have when something goes wrong.
Frequently asked questions
Does SD-WAN replace MPLS completely?
Not necessarily. Many organisations retain MPLS at data centres or sites with strict performance requirements, while using SD-WAN to manage it alongside broadband and mobile connections. Whether to retire MPLS altogether depends on traffic patterns, performance needs and contract terms.
What’s the difference between SD-WAN and SASE?
SD-WAN manages how traffic travels between sites and cloud services. SASE combines networking with cloud-delivered security services in a broader architecture. SD-WAN is often one component of SASE.
Do we need a managed SD-WAN service?
Not always. Managed SD-WAN can suit teams without the capacity to run network operations around the clock. Self-managed or co-managed services may work better for teams that have networking expertise and want direct control over frequent changes. Compare the service levels, internal workload and exit terms as well as the monthly cost.
Is WAN optimisation still needed with SD-WAN?
Sometimes. It can help with high-latency international links, legacy applications and real-time traffic over lossy connections. For encrypted SaaS traffic using local internet breakout, traditional optimisation techniques may offer limited benefit.
Testing your shortlist in person
Comparing SD-WAN providers is easier when you can put your own requirements to them directly. The Elevate.Tech Summit takes place on 10 November 2026 at Hilton London Canary Wharf. It combines seminars with pre-arranged 30-minute one-to-one meetings, scheduled around the product areas qualifying buyers select when they apply. Network infrastructure, network security and SASE are among the event’s listed solution areas.
Attendance is funded for qualifying senior IT decision-makers who commit to the full day and their arranged itinerary. Check whether you qualify as a buyer.
Image credit: https://unsplash.com/photos/woman-sitting-on-chair-8S6BkMGaLyQ
