SD-WAN Total Cost of Ownership: Comparing Value with a Legacy WAN
Compare SD-WAN and legacy WAN economics using a like-for-like scope that includes circuits, platforms, security, operations, transition, contracts, and risk.
By Mark Poulton
SD-WAN Total Cost of Ownership: Comparing Value with a Legacy WAN
SD-WAN does not automatically cost less than a legacy WAN. A fair comparison uses the same sites, applications, service expectations, time horizon, and cost boundaries for both options. It includes transport, platform and edge costs, security services, support, internal operations, contract commitments, migration overlap, and the cost of running the service after cutover.
The result is an organisation-specific business case, not a universal savings percentage. The MPLS vs SD-WAN comparison explains the service and architecture choices; this article concentrates on how to compare their economics.
What belongs in a WAN total-cost comparison?
Set the scope first. Choose a period long enough to include relevant contract and refresh decisions, and compare the same locations and required outcomes. Then identify the cost categories for each option.
| Cost group | Items to include |
|---|---|
| Connectivity | Existing and proposed circuits, internet access, cellular links, installation, service fees, and any required diversity. |
| SD-WAN platform and edge | Licensing or subscription, hardware or virtual edges, orchestration, cloud gateways, support, and replacement or renewal assumptions. |
| Security and adjacent services | Inspection, managed security, identity integration, logging, and other controls needed to meet the same requirement in each design. |
| People and operations | Design, monitoring, incident response, provider management, training, change effort, and ongoing policy administration. |
| Transition | Discovery, implementation, testing, parallel running, migration support, decommissioning, and contract exit or overlap charges. |
| Risk and resilience | Costs required to meet availability, recovery, compliance, and support requirements; record uncertain assumptions separately. |
Do not count an existing cost as eliminated until the contract, circuit, or service can actually be retired. Likewise, do not omit a security or support service from the new design merely because it is bundled or managed by a provider.
How can the comparison be made transparent?
Build a like-for-like model with separate one-time and recurring costs. For each option, show the underlying quantities and rates, the source of each estimate, the time period, and whether the figure is contracted, quoted, measured, or assumed.
At a simple level:
Total cost over the comparison period
= one-time design, migration, and decommissioning costs
+ recurring transport, platform, security, support, and operating costs
+ contract, transition, and other in-scope costs
Use the same scope and service expectations for both cases. If one option assumes a different number of links, resilience level, site count, or support model, explain why. Separate a forecast from current spend and test uncertain inputs with low, expected, and high cases rather than presenting one precise result as certain.
Are savings, cost avoidance, and value the same thing?
No. Realised savings are costs that have actually fallen, such as a retired service no longer being billed. Cost avoidance is a cost that would otherwise have been incurred, such as a planned capacity increase that the new design makes unnecessary; it is a comparison with a counterfactual, not necessarily a reduction in current spend. Operational value may include easier site changes or clearer path visibility, but it should be described separately unless it can be measured credibly.
Do not convert improved application experience directly into a financial benefit without a defensible method and evidence. Avoid counting the same benefit twice, such as recording both a lower provider charge and the same amount as an operational saving.
What assumptions commonly change the result?
Check the sensitivity of the model to:
- contract end dates, renewal terms, early termination, and parallel-running periods;
- how many sites can use the proposed access types and whether those links meet requirements;
- platform, edge, security, and support costs across the full term;
- migration effort, internal capacity, training, and ongoing policy operations;
- required resilience, performance, data handling, and compliance controls; and
- services that must remain in place because of application or provider dependencies.
These factors can change both the break-even point and the preferred design. A phased or hybrid option may have higher short-term overlap but lower transition risk; compare it as a distinct scenario rather than hiding the overlap in an average.
How should SD-WAN value be validated after deployment?
Keep the business case connected to operational evidence. Record actual costs against the assumptions, note which circuits and services were retired, and track transition and support effort. Compare the intended outcomes with a pre-change baseline using consistent definitions. Measuring SD-WAN success and SD-WAN deployment: risks, sequencing, and mitigation cover outcome measurement and rollout evidence in more detail.
For example, if a proposal expects to retire a private circuit after moving a site, show the contract end date, replacement service, security and resilience requirements, expected retirement date, and the invoice or service record that will confirm the saving. If the circuit remains for an application dependency, report the expected saving as deferred or unrealised, not achieved.
Conclusion
A credible SD-WAN business case is explicit about scope, assumptions, costs, and uncertainty. Compare equivalent service outcomes over a stated period, include transition and operating costs, and keep realised savings distinct from avoided future costs or qualitative benefits. Revisit the model after deployment with actual invoices and operational measures; the network label itself is not evidence of financial value.