Published 18 March 2026, Adam Steadman
I've been involved in SD-WAN projects since before most vendors had settled on what to call the technology. Some of those projects went brilliantly. Quite a few didn't. And in almost every case where things went wrong, the problems were visible from week one, they just got ignored because someone had already signed a 36-month contract.
So here's what actually kills SD-WAN deployments, based on roughly 18 years of watching organisations get this right and get it expensively wrong.
You chose based on vendor slides
Every SD-WAN vendor's demo looks fantastic. The dashboards are clean, the failover animations are slick, the latency graphs do exactly what you want them to do. They all present beautifully in a boardroom.
The problem is that vendor slides show you what the technology can do in a controlled environment with perfect underlying connectivity. They don't show you what happens when your leased line at the warehouse drops to 8 Mbps every afternoon because it's on a congested backhaul, or when the 4G signal at your temporary site is barely enough to hold a voice call.
SD-WAN doesn't create bandwidth. It manages the bandwidth you give it. If the underlying connections are rubbish, the overlay will be rubbish too. Just rubbish with a nicer dashboard.
Nobody surveyed the actual connectivity
This is the one that makes me want to put my head through a wall. Organisations will spend six figures on SD-WAN hardware and licensing, then deploy it across 14 sites without ever checking what connectivity each site actually has, what's available to order, and what the building physics look like for cellular.
I worked on a project where a business had bought SD-WAN kit for 11 branch offices. Three of those offices could only get ADSL2+, about 12 Mbps down on a good day. The SD-WAN was faithfully bonding two terrible connections into one slightly-less-terrible connection. The whole deployment took weeks longer than planned because nobody had done a site survey first.
A proper SD-WAN deployment starts with a connectivity audit at every single site. What do you have today? What can you get? What does the cellular coverage look like from inside the building, not from a carrier's coverage checker website? That audit should happen before you even start talking to SD-WAN vendors.
You ignored 4G/5G as a WAN path
This is my biggest frustration with how most IT consultancies approach SD-WAN. They design solutions around fixed-line circuits, two broadband connections, or a leased line plus broadband, and treat cellular as "emergency backup" at best.
That's backwards.
A bonded 4G/5G connection using multi-network SIMs across multiple UK carriers can deliver 100+ Mbps aggregate throughput with sub-second failover. At some sites, particularly where leased line lead times are 90 days or more, cellular is the primary WAN path and the fixed line is the backup. We've deployed this model at construction sites, event venues, and permanent offices where the leased line quote was eye-watering or the lead time was three months.
If your SD-WAN design doesn't include bonded cellular as a first-class WAN path, you're leaving performance and resilience on the table. Full stop.
You treated it as a like-for-like MPLS replacement
This is the strategic mistake. MPLS gave you guaranteed bandwidth, guaranteed latency, and a single throat to choke when things went wrong. SD-WAN over internet circuits gives you none of those things automatically. It gives you the tools to manage multiple cheaper connections intelligently, but "cheaper" and "equivalent" are not the same word.
The organisations that get SD-WAN right treat it as a network architecture change, not a line-item swap. They rethink their traffic flows. They work out which applications actually need low latency and which are fine over a best-effort path. They deploy quality-of-service policies that reflect how their business actually works, not how it worked in 2015 when the MPLS contract was signed.
The organisations that get it wrong hand a Visio diagram to a reseller and say "replace MPLS with SD-WAN, same topology." Then they're surprised when Teams calls sound terrible and the ERP system crawls.
What to do instead
Start with the sites, not the technology. Audit every location's current connectivity. Check what else is available. Test cellular signal strength from inside the building with a proper RF survey, not a coverage map.
Then define what you actually need. Not "we need SD-WAN", that's a solution, not a requirement. What you need is probably something like: "reliable connectivity at 23 sites with sub-200ms latency for our cloud ERP and resilient failover that doesn't require manual intervention." Once you've got that written down, you can evaluate technologies against it honestly.
Build cellular into the design from day one. Use multi-network bonded 4G/5G and treat it as a genuine WAN transport, not an afterthought.
Run a proof of concept at your most difficult site first. Not your head office with the leased line and the fibre backup. Pick the site with the worst connectivity, the most complaints, the dodgiest building. If the solution works there, it'll work everywhere.
And please, for the love of everything, don't sign a 36-month contract before you've proved it works at more than one location.