The SD-WAN market has consolidated significantly since the land-grab years of 2017–2020, but the vendor evaluation process hasn't gotten any easier. If anything, it's harder now. The remaining platforms are more capable, which means there's more overlap in feature sets, more marketing claims to untangle, and more ways for a vendor to steer you toward a decision that serves their pipeline targets rather than your network architecture.
You're about to run an SD-WAN evaluation. You've got vendors on the shortlist. Each of them is going to send you a pre-sales engineer with a polished demo running on dedicated hardware in a lab environment with symmetric, clean, low-latency links. Everything will work beautifully. That demo has nothing to do with your network, and the vendors know it. The demo exists to generate emotional buy-in so that the technical evaluation becomes a rubber stamp.
Here's what an honest evaluation looks like, from someone who has sat through hundreds of these presentations and watched the gap between demo and production widen every single time.
Why vendor evaluation is harder than it looks
The fundamental problem with SD-WAN evaluations is that the technology itself is a moving target. When SD-WAN first emerged, the value proposition was simple: replace expensive MPLS with cheaper internet circuits, use an overlay to maintain connectivity, and manage everything from a central console. That was a clear, testable claim. You could compare vendors on tunnel establishment time, failover speed, and management interface usability.
Today, every major vendor has bolted on security (or been acquired by a security company), added SASE capabilities, integrated with cloud providers, built in WAN optimization, and started marketing AI-powered analytics. The evaluation surface area has expanded enormously, and most organizations don't have the internal expertise to evaluate all of it rigorously. Vendors know this. They exploit it by steering the conversation toward whichever feature set they're strongest in, hoping you won't notice the gaps.
The other problem is that SD-WAN is an overlay technology, and overlay performance is fundamentally bounded by underlay quality. No amount of intelligent routing can fix a circuit that's dropping packets at the ISP's peering point. But the demo will never show you that, because the demo runs on clean underlays. This disconnect between lab conditions and production reality is where most evaluation processes fall apart.
The major platforms, honestly compared
Let's talk about the actual vendors. Not in a Gartner-style ranking with carefully neutral language designed to avoid vendor lawsuits, but honestly, based on what these platforms actually do well and where they fall short.
Cisco: Viptela and Meraki
Cisco owns two SD-WAN platforms, which tells you something about their internal product strategy. Viptela (now Cisco SD-WAN, managed via vManage) is the enterprise-grade offering. It has genuine depth in routing policy, strong integration with IOS-XE, and a control plane architecture (vSmart controllers, vBond orchestrators) that's well-understood by networking teams who already live in Cisco's ecosystem. The templating system for large-scale deployments is mature. TLOC extensions, OMP route manipulation, and centralized data policy give you granular traffic engineering capabilities that most competitors can't match.
The downsides are real though. VManage has historically been unstable at scale. Clusters above 10,000 edges have had documented issues with database synchronization and API responsiveness. The upgrade path between major firmware versions has been painful, with some releases requiring a full overlay rebuild. And the licensing model has been restructured multiple times, making cost forecasting difficult.
Meraki is a completely different animal. It's cloud-managed, simple to deploy, and targeted at organizations that want zero-touch provisioning without deep networking expertise. If your sites are small branch offices with basic connectivity requirements and you want a single dashboard that a junior network admin can manage, Meraki works. But it gives you very little control over the overlay behavior. You can't write granular traffic policies. You can't manipulate the routing table at the edge in any meaningful way. And the analytics, while visually appealing, lack the depth to troubleshoot complex WAN issues. Meraki is fine for what it is, but evaluating it alongside Viptela or Fortinet is comparing a consumer sedan to a commercial truck.
Fortinet SD-WAN
Fortinet's approach is to make SD-WAN a feature of their FortiGate firewall platform, and this is simultaneously their greatest strength and their biggest limitation. If you're already a Fortinet shop running FortiGate appliances at your perimeter, the SD-WAN functionality comes essentially free with the existing hardware. The integration between SD-WAN steering and FortiGate's security inspection is tight. Traffic classification, application identification, SSL inspection, and SD-WAN policy all happen in a single pass through the same ASIC pipeline. This means your "throughput with security enabled" number is close to the raw forwarding number, which is not true of most competitors.
The limitation is that Fortinet's SD-WAN is firewall-first, overlay-second. The overlay capabilities are less sophisticated than dedicated SD-WAN platforms. The tunneling options are more limited. The traffic engineering granularity doesn't match what you get from Viptela or Versa. And if you're not already a FortiGate shop, you're being asked to rip out your existing firewall infrastructure and replace it with Fortinet to get the SD-WAN benefits. That's a much bigger project than deploying an overlay.
FortiManager handles centralized policy management, and it's competent but not elegant. Large-scale template management with ADOM-level segmentation works, but the workflow is clunky compared to what you get from purpose-built SD-WAN orchestrators. The API is functional but poorly documented compared to Cisco's or VMware's.
VMware VeloCloud (now Broadcom)
VeloCloud was the early leader in cloud-first SD-WAN design. Their gateway architecture (where traffic from branch edges can exit through VMware-operated gateway nodes at strategic internet exchange points) was genuinely innovative. It meant branch traffic to SaaS applications could take a shorter path through the internet by entering the VMware backbone at a nearby gateway rather than backhauling to a data center.
Then Broadcom acquired VMware, and everything changed. The product roadmap became uncertain. Key engineering talent left. Existing customers started receiving license restructuring notices that dramatically increased per-edge costs. Support response times degraded. The partner ecosystem got nervous, and several large managed service providers started qualifying alternative platforms.
The technology itself remains solid. The Dynamic Multipath Optimization engine handles link quality measurement and traffic steering well. The cloud gateway infrastructure provides genuine value for organizations with heavy SaaS traffic. But the Broadcom acquisition introduced business risk that cannot be ignored in a five-year evaluation. If you're looking at VeloCloud today, you need contractual protections around pricing stability and product continuity that would have been unnecessary two years ago.
HPE Aruba EdgeConnect
Silver Peak was a strong independent SD-WAN platform before HPE acquired it and rebranded it as Aruba EdgeConnect. The core technology (particularly the WAN optimization capabilities inherited from Silver Peak's pre-SD-WAN heritage) remains genuinely useful. The TCP acceleration, data deduplication, and application-level compression are not just marketing features; they deliver measurable throughput improvements on high-latency or congested links where other SD-WAN platforms simply steer traffic and hope for the best.
The Boost WAN optimization license is one of the few SD-WAN add-ons that consistently justifies its cost in production deployments. For organizations with traffic patterns that benefit from deduplication (think VDI, backup, or any workload with repetitive data patterns), EdgeConnect can squeeze meaningfully more effective throughput out of a circuit than competitors running the same underlay.
The downside is HPE's sales and support organization. The platform is excellent; the experience of buying and supporting it through HPE's enterprise sales motion can be frustrating. License quoting is slow. Support escalation paths are opaque. And the integration with HPE's broader networking portfolio (Aruba switches, Aruba Central management) is a work in progress that sometimes feels forced rather than organic.
Versa Networks
Versa is the platform that networking engineers tend to respect and procurement teams tend to overlook. The architecture is built on a single-stack model where routing, SD-WAN, security, and analytics all run on the same software instance. This isn't feature bundling. It's a genuinely unified code base with a common policy engine. The result is that Versa can do things that multi-product stacks cannot: apply a single policy that simultaneously governs routing behavior, security inspection, and application steering without traffic having to traverse multiple processing engines.
Versa's multi-tenancy model is the most mature in the market, which is why it's the platform of choice for many managed service providers. If you're evaluating managed SD-WAN services, there's a reasonable chance the provider is running Versa underneath regardless of their branding.
The challenge with Versa is market visibility and ecosystem. They don't have Cisco's brand recognition or Fortinet's installed base. Finding engineers with Versa experience is harder than finding Cisco or Fortinet people. And while the platform is technically capable, the management interface has historically been less intuitive than competitors, requiring more training to operate effectively.
Cato Networks
Cato takes a fundamentally different approach. Rather than deploying SD-WAN appliances at each site and running an overlay across the public internet, Cato operates its own global private backbone. Branch edges connect to the nearest Cato point of presence via IPsec or their thin edge device, and all inter-site traffic traverses the Cato backbone rather than the public internet. Security inspection happens in the Cato cloud, not at the edge.
This architecture has real advantages. You get predictable inter-site performance because you're not dependent on internet routing between sites. You get consistent security policy enforcement because everything goes through the same cloud inspection stack. And you get dramatically simpler edge hardware because the intelligence lives in the cloud, not on the appliance.
The disadvantages are equally real. You're entirely dependent on Cato's backbone and their points of presence. If the nearest PoP is 50 milliseconds away, every inter-site communication adds that latency in both directions. You have no control over the routing within Cato's backbone. If they have a capacity issue or a routing problem, your only option is to open a support ticket and wait. The security stack is capable but not as deep as running dedicated Palo Alto or Fortinet appliances. If you have specific security requirements driven by regulatory compliance, verify that Cato's cloud security meets them before you commit. And moving off Cato is harder than moving off a traditional SD-WAN platform because you've outsourced the entire transport layer, not just the overlay.
Palo Alto Prisma SD-WAN
Prisma SD-WAN (formerly CloudGenix, acquired in 2020) fits into Palo Alto's broader SASE strategy. The SD-WAN component is solid. CloudGenix was a good product before the acquisition, with strong application identification and an intuitive policy model. The value proposition now is the integration with Prisma Access for cloud-delivered security, creating a combined SD-WAN and SASE solution under a single vendor.
The reality of that integration is still maturing. Prisma SD-WAN and Prisma Access were built as separate products and are being unified through API-level integration and shared policy constructs, but the operational experience of managing both through a single console is not as seamless as the marketing suggests. The licensing model is among the most complex in the market, with separate entitlements for SD-WAN, SASE, and various security features that can be difficult to forecast.
If you're already committed to the Palo Alto security ecosystem and want a single-vendor approach to both SD-WAN and SASE, Prisma is worth evaluating. If you're starting from scratch and evaluating SD-WAN on its own merits, the platform doesn't differentiate enough from the other major players to justify the premium pricing and licensing complexity.
What "application-aware routing" actually means
Every SD-WAN vendor claims application-aware routing. It's become table stakes in the marketing material. But the implementations vary wildly, and understanding the differences matters because this is the feature that determines whether the platform actually improves your user experience or just moves the same problems to a different circuit.
At the most basic level, application-aware routing means the SD-WAN platform identifies what application a traffic flow belongs to and makes a routing decision based on that classification and the current quality of available WAN links. If it detects that your primary link is experiencing high latency, it can shift latency-sensitive traffic (voice, video) to a secondary link that's performing better. Simple enough in concept.
The first question is: how does the platform identify the application? There are several methods, and each has limitations. Deep packet inspection (DPI) examines the payload of packets to identify application signatures. This worked well when traffic was unencrypted, but with TLS 1.3 and encrypted DNS becoming standard, DPI increasingly sees only the TLS handshake. Some platforms use the Server Name Indication (SNI) field in the TLS ClientHello to identify the destination, but this only tells you the domain, not the specific application or function. Calling out to a cloud-based classification database adds latency to the first packets of every new flow. And heuristic classification (making educated guesses based on packet size, timing, and port numbers) is inherently imprecise.
The second question is: what does the platform do with unclassified traffic? In most networks, a significant percentage of traffic (anywhere from 15% to 40%) doesn't match any known application signature. This includes custom internal applications, legacy systems using proprietary protocols, IoT device communication, and anything that the vendor's signature database hasn't been updated to recognize. If unclassified traffic is dumped into a default best-effort queue, you've just degraded the performance of every application the vendor doesn't know about. Ask the vendor during evaluation: can you create custom application definitions? How granular are they? Can you match on a combination of destination IP, port range, DSCP marking, and protocol? Or are you limited to what the vendor's cloud database recognizes?
The third question (and this is the one vendors hate. Is: what's the reaction time? When link quality degrades, how long does it take the platform to detect the degradation, recalculate the routing decision, and move the affected traffic? If detection is based on BFD (Bidirectional Forwarding Detection) with a 1-second interval, and it takes two missed heartbeats to declare a degradation, and then the platform needs to recalculate the path and reprogram the forwarding plane, you're looking at 5–10 seconds minimum from the onset of degradation to the completion of traffic steering. During those seconds, your voice calls are garbled and your video feeds are frozen. Some platforms react faster by using per-packet steering based on continuous SLA probes, but this comes with its own overhead and can cause reordering issues for TCP-based applications.
The underlay problem nobody wants to talk about
Here is the fundamental truth that SD-WAN vendors would prefer you didn't think about too carefully: SD-WAN is an overlay technology, and its performance is bounded by the underlays it runs on. If your primary internet circuit is dropping 2% of packets at the ISP's peering point during peak hours, the SD-WAN platform can detect this and move traffic to another link. Assuming the other link isn't suffering the same problem for the same reason, which it often is when both circuits come from providers who peer at the same internet exchange.
The vendor demo will show you failover between a "good" link and a "bad" link, where the bad link is artificially impaired and the good link is clean. In production, you frequently face scenarios where all your links are degraded simultaneously because the root cause is upstream of your demarcation point. A regional ISP backbone issue affects all the circuits you buy from providers who transit through that backbone. A submarine cable cut degrades latency to cloud services regardless of which local circuit you use. A peering dispute between carriers means traffic from your London office to your AWS eu-west-1 workloads takes a circuitous path through Amsterdam regardless of your SD-WAN policy.
This is why circuit diversity matters far more than most SD-WAN evaluations acknowledge. If you're running two broadband circuits from providers who share last-mile infrastructure (common in areas served by a single cable operator), your SD-WAN has two paths that fail together. If you're running an ethernet circuit and an LTE backup, the LTE circuit probably doesn't have enough consistent throughput to sustain your production workload when the primary fails. The SD-WAN will faithfully steer traffic to the LTE link, and your users will experience a different kind of misery.
During vendor evaluation, map your actual circuit topology. Understand where physical paths diverge, where they converge, and where upstream provider networks overlap. Then ask the vendor: given this specific underlay topology, what can your platform actually improve? An honest vendor will tell you that SD-WAN can optimize traffic distribution, detect and react to degradation, and provide encrypted overlay connectivity, but it cannot fix bad circuits. A dishonest vendor will imply that their technology somehow transcends the laws of physics.
TCP optimization: when it helps and when it hurts
Several SD-WAN platforms include TCP optimization features. Sometimes called WAN acceleration or protocol optimization. The idea is to intercept TCP connections at the SD-WAN edge, terminate them locally, and use an optimized transport between the two edge devices. This overcomes the inherent limitations of TCP over high-latency or lossy links: TCP's congestion window algorithm was designed for LAN conditions and performs poorly when round-trip times exceed 50 milliseconds or packet loss exceeds 0.1%.
HPE Aruba EdgeConnect (via the Boost license) and Riverbed's SD-WAN offering (from their WAN optimization heritage) do this well. The TCP proxy splits the connection into two segments: client to local edge, and local edge to remote edge using an optimized protocol that's more aggressive with congestion window scaling and handles loss through forward error correction rather than retransmission. On a 200-millisecond latency path with 1% packet loss, this can improve effective throughput by a factor of four or more.
But TCP optimization is not universally beneficial, and it can actively break applications that rely on specific TCP behaviors. Applications that use TCP timestamps for session validation may reject connections that have been proxied. Applications that implement their own congestion control (many modern streaming protocols do this) can conflict with the SD-WAN's optimization, resulting in worse performance than no optimization at all. Encrypted protocols where the SD-WAN cannot inspect the payload can't benefit from data deduplication or compression. And any application that pins sessions to specific TCP parameters (sequence numbers, window sizes) may behave unpredictably when those parameters are modified by the optimization engine.
During evaluation, test TCP optimization with your actual application mix. Enable it and measure. Then disable it and measure again. Some applications will benefit dramatically. Others will break. The platforms that let you selectively enable optimization per application or per traffic class are far more useful in production than those that offer only a global on/off switch.
Security integration: SD-WAN security vs. Dedicated SASE
The convergence of SD-WAN and security has created a genuinely confusing market. Every SD-WAN vendor now claims to provide security features. Every security vendor now claims to provide SD-WAN. The question for your evaluation is: where should security inspection happen, and how much should you trust the SD-WAN platform to do it?
There are two distinct architectures. In the first, security inspection happens on the SD-WAN appliance at the branch edge. Fortinet's approach typifies this: the FortiGate appliance performs SD-WAN steering and full UTM inspection (IPS, anti-malware, URL filtering, SSL decryption) in a single device. The advantage is simplicity. One box, one policy, no additional traffic trombone through a cloud service. The disadvantage is that security processing consumes appliance resources, and the security depth is bounded by what fits on a branch appliance. You're not going to get the same inspection quality from a branch FortiGate that you'd get from a dedicated PA-5250 in your data center.
In the second architecture, the SD-WAN platform steers traffic to a cloud-based security service for inspection. This is the SASE model that Cato, Zscaler (paired with SD-WAN partners), and Palo Alto Prisma follow. Branch traffic exits through a cloud security PoP where full inspection happens. The advantage is that security processing capacity is elastic. You're not limited by branch appliance specs. The disadvantage is that all your traffic now takes a detour through the security cloud, adding latency. If the nearest PoP is 20 milliseconds away, you've added 40 milliseconds of round-trip latency to every flow that needs inspection. For users accessing local resources or peering with nearby services, this penalty is real and noticeable.
The honest answer is that neither approach is universally better. If your organization has strict security requirements (PCI-DSS, HIPAA, government data handling), you probably need dedicated security appliances or a mature cloud security service, and the SD-WAN should focus on being a good transport platform rather than trying to be a mediocre security platform at the same time. If your security requirements are standard commercial-grade and you want operational simplicity, an integrated approach can work. But size the appliances based on the throughput-with-security-enabled number, not the raw forwarding number.
Managed service vs. Self-managed: the real trade-off
Most SD-WAN deployments end up being managed by a service provider rather than operated in-house, and there are good reasons for this. SD-WAN platforms require ongoing care: firmware updates, certificate rotation, policy tuning, tunnel health monitoring, and capacity planning. If you don't have a dedicated network operations team with the skills to manage the chosen platform, outsourcing makes sense.
But managed SD-WAN introduces its own problems. The service provider typically operates a multi-tenant instance of the orchestrator. You get a portal view into your portion of the platform, but you don't get full administrative access. You can't make policy changes in real time. You submit a change request, it goes through the provider's change management process, and it gets implemented in their next maintenance window. When something breaks at midnight, your first call is to the provider's NOC, not to the platform itself. If the provider's NOC is understaffed, outsourced, or unfamiliar with your specific configuration, you're adding a layer of organizational latency to every incident.
The critical question for managed SD-WAN is: what level of self-service does the provider offer? Can you view real-time tunnel health and application metrics? Can you make emergency policy changes without a ticket? Can you access raw logs and flow data for your own troubleshooting? Some providers give you a fully featured read-write portal. Others give you a dashboard with traffic graphs and nothing else. The difference between these two experiences is the difference between "managed service" and "managed helplessness."
If you're considering managed SD-WAN, insist on a trial of the actual management portal before signing. Not a demo of the portal. Actual access to a lab instance where you can click through the interface, attempt a policy change, and see what the escalation process looks like. The quality of the management portal should be weighted as heavily as the quality of the underlying platform.
Questions to ask during vendor evaluation
Most evaluation questionnaires focus on feature checklists: does the platform support OSPF? Does it support BGP? Can it do URL filtering? These questions produce identical "yes" answers from every vendor and tell you nothing useful. Here are the questions that actually differentiate platforms.
Failover under load, not just link failure. Configure the demo with both links running at 70% utilization. Fail the primary link. What happens to the traffic that was on the primary? Does it all move to the secondary, which is already at 70%? How does the platform handle the resulting congestion? Does it queue intelligently based on application priority, or does it just flood the secondary and let TCP sort it out? This scenario (failover into a link that doesn't have enough headroom) is the production reality at most organizations, and many platforms handle it poorly.
Brownout detection sensitivity. Don't just cut the cable. Introduce 0.5% packet loss on the primary link using a network impairment generator. Then increase to 1%, then 2%, then 5%. At what threshold does the platform detect degradation and begin steering traffic away? Is the threshold configurable per application? A voice stream might be unacceptable at 1% loss while a file transfer is fine at 5%. If the platform uses a single SLA threshold for all traffic, it's either going to steer too aggressively (wasting capacity on the secondary for applications that don't need it) or too conservatively (letting latency-sensitive traffic suffer on a degraded link).
What does the platform do when all paths are degraded? This is the scenario vendors never volunteer to demo. Both links have elevated latency and intermittent packet loss. There's no "good" path to fail over to. Does the platform continuously flap traffic between the two degraded links, making things worse? Does it pick the less-bad option and stick with it? Does it apply forward error correction to compensate for loss? The answer to this question reveals more about the platform's engineering maturity than any feature checklist.
Certificate lifecycle management. Every SD-WAN overlay uses certificates for tunnel authentication. Who issues the certificates? What's the validity period? What happens when they expire? Is rotation automatic or manual? If a certificate expires on a remote edge device at a site with no local IT staff, how do you recover? Some platforms handle this transparently. Others have caused production outages when certificates expired because nobody noticed the renewal window.
BGP integration depth. If you're running BGP with your upstream providers (and you should be if you have multiple ISPs), ask the vendor how their platform interacts with BGP-learned routes. Can the SD-WAN policy reference BGP communities? Can it influence BGP path selection based on overlay SLA metrics? Or does it treat the BGP layer as a black box and only operate on traffic after it's been routed? The depth of this integration tells you whether the platform was designed by networking engineers or by application developers who added networking features.
Migration from MPLS: what actually breaks
The most common driver for SD-WAN adoption is replacing or augmenting MPLS. The economic argument is compelling. Internet circuits cost a fraction of equivalent MPLS bandwidth, and you get the flexibility to add or change sites without a six-week carrier lead time. But the migration itself is where organizations get hurt.
MPLS provides guaranteed quality of service end to end. When you buy a 100 Mbps MPLS circuit with a CIR (Committed Information Rate) of 100 Mbps, you get 100 Mbps of guaranteed, low-latency, zero-loss bandwidth between your sites. The carrier manages the QoS queuing across their backbone. Your DSCP markings are honored hop by hop. Your voice traffic gets priority queuing at every router in the path.
SD-WAN over internet circuits provides none of these guarantees. Your DSCP markings are likely stripped at the first ISP hop. There's no CIR on a best-effort internet circuit. Your 100 Mbps broadband might deliver 95 Mbps at 2 AM and 60 Mbps at 2 PM. The internet path between your two sites might traverse six autonomous systems, and a congestion event at any of them degrades your traffic. SD-WAN can detect this degradation and react to it, but it cannot prevent it.
This means that any application currently relying on MPLS QoS guarantees needs to be tested explicitly on the SD-WAN overlay before you decommission the MPLS circuit. Voice systems that use G.711 with no jitter buffer (because they never needed one on MPLS) will have problems on internet underlays. Real-time control systems that depend on sub-10-millisecond latency between sites may not function correctly on internet paths with variable latency. Database replication that assumes reliable, ordered delivery may need its timeout and retry parameters retuned for a higher-jitter environment.
The safe migration approach is to run SD-WAN in parallel with MPLS for a meaningful period. Not two weeks, but two or four months. Migrate traffic category by category, starting with web browsing and email (which are tolerant of variable WAN quality), then moving to business applications, and only moving real-time voice and video traffic after you've established a baseline of overlay performance data that gives you confidence the internet path can support it. Keep the MPLS circuit as a fallback until you've proven the overlay under real conditions, including peak usage periods, seasonal traffic variations, and at least one ISP maintenance window.
Budget for the parallel running period. The MPLS contract probably has an early termination clause, and you'll be paying for both the MPLS and the internet circuits during the migration. This is not wasted spend. It's risk management. Organizations that cut MPLS on day one to show cost savings on a quarterly report are the ones that end up in emergency calls at 11 PM when the internet overlay can't sustain their ERP traffic during month-end processing.
The total cost of ownership trap
SD-WAN vendors love to present a TCO comparison that shows their solution at a fraction of the cost of MPLS. That comparison is accurate in the same way that a car sticker price is accurate. It reflects the cost of one component while ignoring everything else you'll spend money on.
The hardware is genuinely the cheap part. An SD-WAN edge appliance for a typical branch site is a minor line item, even across 50 sites. Hardware is a rounding error in the five-year cost.
Here's what actually drives the total cost:
Licensing. This is where the money lives. Every platform has tiered licensing, and the features you need are rarely in the base tier. Application-aware routing, advanced analytics, WAN optimization, security features, cloud gateway connectivity. Each is a separate license entitlement on most platforms. Map every feature you tested during the POC to its license tier, and get the vendor to quote the exact license configuration you evaluated. If they quoted you "Advanced" pricing during the POC but the production quote defaults to "Essentials," you'll lose the features that made you choose the platform.
Circuit costs. You're replacing one MPLS circuit with two or more internet circuits per site for diversity. Each circuit has its own monthly recurring cost, installation fee, and contract term. LTE or 5G backup circuits have data caps or usage-based pricing that can spike unexpectedly. Calculate the actual circuit cost per site under normal conditions and under failover conditions (when the LTE backup is carrying production traffic and burning through its data allocation).
Implementation. Deploying SD-WAN across 50 sites is a project. It requires circuit ordering, site surveys, appliance staging, configuration development, testing, and cutover coordination. Whether you do this internally or hire a systems integrator, it's a significant effort for a mid-size deployment. The vendors will tell you it's "zero-touch provisioning". and the appliance bootstrap is automated, but the circuit provisioning, firewall rule updates, routing changes, DNS modifications, and application testing at each site are decidedly not zero-touch.
Ongoing operations. Someone needs to monitor the overlay, respond to alerts, tune policies, manage firmware updates, handle capacity planning, and troubleshoot when users complain. If you don't have these skills in-house, you're paying a managed service provider. If you do have the skills, you're allocating engineering time that has an opportunity cost. Either way, the annual operational cost of running the SD-WAN frequently exceeds the annual licensing cost.
Refresh cycles. SD-WAN appliances have a support lifecycle, typically five to seven years. At the end of that lifecycle, you'll need to replace the hardware even if it's still functional, because the vendor will stop providing firmware updates and security patches. Plan for a hardware refresh at year five of your deployment, and account for the project cost of rolling out new appliances across your estate.
When you build the real TCO model (licensing, circuits, implementation, operations, and refresh) SD-WAN is still usually cheaper than MPLS over a five-year period. But the savings are 30–40%, not the 70–80% that the vendor's slide deck promised. And if you factor in the operational complexity of managing an overlay across multiple internet underlays versus calling your MPLS provider and telling them to fix it, the total cost of ownership gap narrows further.
Running the evaluation properly
Here's the process, compressed into what actually matters.
Start by documenting your requirements in detail, before any vendor conversation. What applications matter? What are the latency and loss tolerances for each? What does your current traffic matrix look like (site to site, site to cloud, site to internet)? What's your security architecture today, and what do you want it to be in two years? What are your circuit options at each site? Write this down. It becomes your scoring framework.
Invite vendors to respond to your requirements document, not to deliver their standard pitch. Give them the document and ask for a written response explaining how their platform addresses each requirement. Vendors that can't or won't engage with your specific requirements are vendors that will struggle with your specific deployment.
Run a proof of concept at a representative site (not your headquarters, not a lab. Pick a site with the kind of messy connectivity that exists in the real world. Use your actual traffic. Inject failures. Measure everything. Run the POC for long enough to see the platform under varied conditions) two weeks minimum, four weeks preferred.
Read the contract before the technical evaluation concludes, not after. The commercial terms will eliminate some vendors from contention, and you don't want to discover that after you've invested weeks in a POC.
And accept that no vendor is perfect. The platform that wins your evaluation will have weaknesses. The goal isn't to find a perfect product. It's to find the product whose weaknesses are in areas that matter least to your organization, and whose strengths align with the problems you actually need to solve.