SD-WAN has been sold into every mid-market business for the better part of a decade. The pitch is consistent: you replace a static, expensive, MPLS-flavoured network with software-defined intelligence that routes traffic based on application, fails over without anyone noticing, and tucks security policy into the same fabric. For some hospitality groups it really is transformative. For others it is an expensive feature set they will never meaningfully use, dressed up in a three-year licence agreement.
This post is for ops directors and IT leads at multi-site restaurant and hotel groups who are being quoted SD-WAN, or who suspect they should be looking at it, and want a fair read on whether it earns its keep. We are not going to pick a vendor. We are going to be honest about where it pays back and where the simpler option is better.
What SD-WAN actually is, in plain English
Strip away the marketing and SD-WAN is a way of treating the wide-area network across all your sites as a single managed policy layer rather than a collection of independent routers. Three things tend to define it.
The first is application-aware routing. Instead of sending all traffic out of whichever circuit happens to be primary, an SD-WAN appliance can recognise that the traffic is, say, your cloud EPOS back-office, and decide which circuit to use based on policy: lowest latency, lowest jitter, cheapest, most secure. If that circuit degrades mid-service, the appliance moves the session without dropping it.
The second is automatic, transport-agnostic failover. Most sites today have at least two paths to the internet - a primary fibre line and a 4G or 5G backup, sometimes a second wired circuit. SD-WAN treats those circuits - whether fibre, leased line or 4G/5G - as a pool. If one goes down, traffic shifts to the other in seconds, often without the application ever noticing. That is meaningfully different from the old model where failover meant a router reboot and a hard cut.
The third is centralised policy and, increasingly, integrated security. You manage the entire estate from one console: routing, QoS, firewall rules, segmentation, often web filtering and remote-access VPN. The same policy applies whether you have eight sites or eighty, and a change pushes everywhere at once.
That is the genuine product. Whether you need it is a different question.
When it is worth it
SD-WAN earns its keep in a few specific circumstances. If two or three of these are true for your group, the conversation is worth having seriously.
You have ten or more sites with significant central application traffic. This is the threshold where managing routers individually starts to break down operationally, and where the volume of traffic between sites and a central hub - head office reporting, cloud EPOS back-office, central reservations, a hosted PMS - is large enough that intelligent routing makes a measurable difference. Below that scale, the management overhead of SD-WAN is hard to recover.
You need application-level resilience that the till never feels. In hospitality, the cost of EPOS downtime is not theoretical. We have written about this in the real cost of EPOS downtime. If a fibre line wobbles for thirty seconds during a Friday service, a basic failover setup will reboot a router and your card terminals will reconnect a minute or two later. SD-WAN, properly configured, will hold the session up and you will not lose a transaction. For a group running busy services across multiple sites, that difference adds up quickly.
You want one security policy applied everywhere. If your compliance posture, cyber insurance position or simple sanity demands that every venue has the same firewall rules, the same web filtering, the same segmentation between guest Wi-Fi and back-office, then a centrally managed fabric is enormously easier to live with than per-site appliances configured by whoever was on site that day. This is the same logic we apply when scoping managed network engagements, and it sits alongside the broader cyber security controls a hospitality group should have in place.
You are heading toward SASE or cloud-delivered security. SD-WAN is the on-ramp for Secure Access Service Edge architectures, and it works hand in hand with franchise connectivity across multi-site estates, where security inspection happens in the cloud rather than on a box at each site. If your three-year plan involves moving toward that model - and for groups with a meaningful remote workforce or heavy SaaS dependency, it often should - then putting SD-WAN in now means you are buying the first half of an architecture you are committed to anyway.
When it is not worth it
Equally, there are honest reasons to walk away from an SD-WAN proposal and feel good about the decision.
You have fewer than five to ten sites. At small scale, a well-configured estate of centrally managed routers with sensible failover gives you most of the benefit at a fraction of the cost and complexity. You will not recoup the licence, the professional services or the ongoing management overhead.
Each site largely operates independently. If your venues do not share much application traffic - they each have a local EPOS, a local PMS, a local reservation tool, and the only thing crossing the WAN is some emailed reporting and the occasional Teams call - there is very little for SD-WAN’s clever routing to optimise. It is solving a problem you do not have.
Your applications are mostly local or pure SaaS with no central hub. SaaS-only estates, where everything important lives at Microsoft, Google, your EPOS vendor and your PMS vendor, do not benefit much from a fabric optimised for hub-and-spoke traffic. A good local circuit and a sensible secure web gateway gets you most of the way there.
Your operational maturity does not support it. SD-WAN is not fit-and-forget. It needs someone who understands the policy model, who can read the telemetry, who can act on what it tells them. If your in-house team is one person who also looks after EPOS and email, or your incumbent provider is a break-fix shop, the platform will quietly underperform and you will pay a premium for features no one is using. The honest answer in that situation is to fix the operating model first.
The vendors worth looking at
We are deliberately not picking favourites here, because the right answer depends on your existing estate, your security posture and how you want to manage it. The names that should appear on any serious shortlist are Fortinet Secure SD-WAN, Cisco Meraki, VMware VeloCloud (now under Broadcom), Cato Networks, Versa Networks and Palo Alto Prisma SD-WAN. Each has genuine strengths.
Fortinet folds SD-WAN into the same appliance as its next-generation firewall, which is attractive if you want one box per site doing both jobs. Meraki is the easiest to operate at scale and the most forgiving of mixed-skill teams, at the cost of some flexibility. VeloCloud has the strongest pedigree in pure SD-WAN performance. Cato is a cloud-native SASE platform that effectively bundles SD-WAN, security and a private backbone, which suits groups that want to outsource the whole network and security stack. Versa is feature-rich and often the choice of larger enterprises. Prisma sits naturally in estates already standardised on Palo Alto for security.
The right pick is the one that fits your estate, your team and the direction you are heading. It is rarely the one with the best slide deck.
The hidden costs
Every SD-WAN business case we review under-counts the same things. Be ready for the hardware refresh, because existing routers usually cannot be reused. Be ready for the licences, which are normally three-year subscriptions and are often layered - base SD-WAN, advanced routing, security add-ons, reporting. Be ready for the professional services to design and deploy, which can run into five figures even for a modest estate. Be ready for the training cost on your own team, or the management premium your provider will charge. And be ready for the ongoing tuning. A network that is not actively managed will slowly drift away from the policy you originally agreed.
The headline appliance and licence price is rarely more than half the real number.
The simpler alternative most groups should consider first
For a lot of the hospitality groups we work with, the right answer is not SD-WAN. It is a properly designed, centrally managed router estate with sensible failover, sensible segmentation and a single management plane. Meraki MX without the SD-WAN add-ons is a common shape. So is a Fortinet estate run as straight firewalls with cloud management. Both give you the centralised visibility, the consistent policy and the failover that genuinely matters, without paying for application-aware routing you are not going to use.
That is a much shorter conversation, a much smaller bill and, for groups under about ten sites with mostly SaaS applications, a much better fit.
How we help customers decide
When a client asks us whether they should be looking at SD-WAN, we run through the same short diagnostic. How many sites today, and how many in the next two years. What proportion of their critical traffic is hub-and-spoke versus pure SaaS. What the real cost of an hour of EPOS or PMS downtime is at their busiest site. What their current security posture looks like and where it needs to get to. Whether they have, or are willing to pay for, the operational maturity to run an SD-WAN platform properly.
If the answers point to SD-WAN, we say so and we help them scope it. If they do not, we say so equally clearly and we recommend the simpler estate. The objective is not to sell the most exciting technology. It is to put the right network under the business so that nobody at site level ever has to think about it. That is the lens we apply across all of our hospitality IT support work.
If you are weighing up an SD-WAN proposal, or you suspect your current network is the weakest link in an otherwise capable estate, our managed network team is happy to look at what you have and give you a straight answer. No slide deck, no scare tactics, just the honest view of whether SD-WAN earns its keep for your group.