SD-WAN evaluation: a practical acceptance checklist

At a glance

Test degraded links as well as complete outages.
Measure application recovery and failback, not just tunnel status.
Price the circuits, security and operating work together.

Pulling out a WAN cable makes a convincing demonstration. The dashboard changes colour, traffic moves to another circuit and the presenter carries on. A branch whose connection is still up but intermittently losing packets is a harder test. Staff can sign in, yet calls break up and transactions stall.

SD-WAN evaluation should cover both conditions. The buying decision is about how applications behave across the available connections and how much work the team must do to keep them usable. A successful tunnel switchover is useful evidence, but it does not settle that decision.

Start with three application journeys

Select a real-time session, an interactive business transaction and a bulk transfer. For example, use a support call, an order submission and an overnight backup. Agree what a usable outcome means with each service owner before suppliers configure their demonstrations.

Record the current route, busiest operating period, dependencies and acceptable interruption. Include DNS, identity and security inspection. If a branch reaches its application through a cloud security service, a trial that bypasses that service is testing a different design.

Keep the test repeatable: the same clients, traffic mix, security policy and observation window for each candidate. The objective is a defensible comparison, not an impressive peak throughput figure that the production estate cannot reproduce.

Ask what the routing decision actually measures

Agree how packet loss, latency and application delay will be measured before comparing routing policies. Record the probe path and sampling interval alongside each result.

Application-aware routing can use measurements such as loss, latency and delay variation to choose a path. In its vEdge application-aware routing documentation, Cisco describes SLA classes and the measurement and averaging used to classify tunnels. That is an implementation example, not a promise that every SD-WAN product behaves identically.

Ask each supplier to explain the measurement interval, averaging window, decision threshold and recovery conditions for the proposed software release. A long window can hide short disruptive bursts; an aggressive threshold can cause repeated path changes. Neither is automatically wrong. The choice has to match the traffic and the cost of moving it.

Also ask what happens when every available path fails the target. Does traffic use the least impaired route, remain on a preferred path or get dropped under a strict policy? Have the supplier show the configured behaviour and its consequence for the selected applications.

Use an acceptance matrix that includes recovery

Condition	Observe	Acceptance question
Primary circuit disconnected	Detection, path change and transaction recovery	Can users resume within the service’s agreed limit?
Loss or delay increases while the link stays up	Measurements, policy decision and user experience	Does the system react before the application becomes unusable?
Both circuits degrade	Fallback policy and traffic prioritisation	Which work continues, and who is alerted?
Primary circuit recovers	Stability period, failback and session interruption	Does recovery avoid repeated route changes?
Management service unavailable	Existing forwarding and permitted local actions	What can the branch and support team still do?

Run impairment tests in an agreed pilot or lab, with bounded traffic and a reversal plan. Do not introduce uncontrolled loss into a production service to make a sales comparison. Capture the event timeline from both the application and the network so the supplier cannot substitute a control-plane timestamp for user recovery.

Ask for evidence of circuit diversity: building entry, access provider, upstream dependency and power. Two commercial contracts do not establish physical separation. If that evidence is unavailable, record the uncertainty in the resilience case.

A mobile backup introduces different constraints. Test reception at the installed equipment, busy-period capacity, data allowance and the behaviour of business traffic after the public source address changes. Check third-party allowlists and security controls that depend on the original egress address.

Decide what the backup is meant to sustain. Keeping order entry and support calls available may be achievable where preserving every background transfer is not. Make that prioritisation explicit in the policy and in the service owner’s acceptance.

Compare the operating bill, not only the appliance

Include circuit charges, licences, security services, hardware replacement, monitoring, installation and escalation coverage. Ask which party owns diagnosis when the SD-WAN supplier says the underlay is at fault and the carrier says its circuit is healthy.

Give the support team a trial incident to resolve. Can they see the affected application, selected route, measurements and recent policy changes? Can they export useful evidence for a carrier without needing the supplier to operate the console?

This is where network monitoring that separates loss, latency and application delay matters. A purchase should improve the team’s ability to explain an incident as well as move traffic around it.

Finish with an acceptance record: the tested release and configuration, results for each journey, failed tests, remaining dependencies and named owners. Use that record in the contract and rollout plan. If a supplier cannot explain the slow-link result, the cable-pull demonstration has not answered the most important question.

Your next step