Software-defined wide area networking decouples transport connectivity from routing and security policy. Edge devices at branch offices establish encrypted tunnels across whatever underlay links are available — MPLS, broadband, LTE, 5G — while a central controller pushes application-aware forwarding rules that select paths based on real-time performance. SD-WAN promises cost reduction by replacing expensive MPLS with internet broadband, improved application performance through intelligent path selection, and simplified management through centralized policy — when designed and operated correctly.
SD-WAN is not a single technology but an architecture combining overlay tunneling, centralized orchestration, path measurement, and often integrated security. Vendor implementations differ significantly in tunnel protocols, controller deployment models, security feature depth, and behavior during controller or cloud management outages. Evaluating SD-WAN requires understanding these differences against your specific branch count, application portfolio, compliance requirements, and existing WAN investments.
Overlay and Underlay
The underlay is whatever physical or virtual connectivity exists between sites — MPLS VPN, internet broadband, cellular, point-to-point wireless. SD-WAN edge devices build overlay tunnels across all available underlay paths, encrypting traffic with IPsec or vendor-proprietary protocols. The overlay presents a unified logical network independent of underlay characteristics. A voice call might traverse MPLS while a software update uses broadband simultaneously from the same edge device, selected automatically by policy.
Underlay diversity is the foundation of SD-WAN value. Branches with single broadband links gain simplified management but not path redundancy. Design standards should require dual underlay at every site — typically MPLS plus broadband or dual broadband from different ISPs. LTE or 5G provides tertiary backup at critical locations. SD-WAN cannot compensate for single-homed branches during ISP outages regardless of how sophisticated the controller policies become.
Path Selection and SLA
Controllers measure latency, jitter, and packet loss on each tunnel continuously. Application policies map traffic to SLA classes — real-time voice requires low latency and jitter; bulk file transfer tolerates higher latency but needs throughput. When the primary path degrades below SLA thresholds, traffic steers to backup paths automatically. Some implementations duplicate packets on multiple paths for critical real-time traffic, accepting bandwidth overhead for loss protection.
Define SLA thresholds based on application requirements, not generic defaults. Interactive desktop protocols need latency under 150 milliseconds; voice needs jitter under 30 milliseconds. Test threshold sensitivity — overly aggressive failover causes path flapping when marginal links oscillate around thresholds. Hysteresis and hold-down timers prevent rapid switching that disrupts stateful sessions. Document which applications use which SLA classes and review mappings when application portfolios change.
Centralized Policy Management
Policy templates define forwarding, security, and QoS rules applied consistently across hundreds of edges. A new SaaS application requirement updates one template and propagates to all relevant sites rather than configuring each edge individually. Templates should parameterize site-specific values — local LAN subnets, ISP circuit identifiers — while keeping policy logic centralized. Version control policy templates in Git with CI/CD validation before controller deployment.
Controller deployment options include vendor cloud management, on-premises controller clusters, and hybrid models. Cloud management simplifies operations but creates dependency on internet connectivity for policy changes — existing tunnels typically persist during controller outages, but configuration updates queue until connectivity restores. On-premises controllers suit organizations with strict data sovereignty requirements or unreliable internet management paths to cloud controllers.
Security Integration
SD-WAN edges often include firewall, intrusion prevention, and URL filtering replacing separate branch security appliances. Local internet breakout routes SaaS traffic directly from branch to internet through edge security inspection rather than backhauling through data center security stacks. This reduces latency for cloud applications but distributes security policy enforcement to edges that must receive consistent threat intelligence updates.
Integrate SD-WAN with existing security architecture — centralized logging to SIEM, consistent policy with data center firewalls, and compliance with data residency requirements for inspected traffic. Some regulated industries prohibit local internet breakout for certain data classifications, requiring policy exceptions that route specific traffic through centralized inspection despite SD-WAN local breakout defaults.
Migration and Operations
Pilot SD-WAN at representative branches covering different underlay types, application mixes, and geographic regions before global rollout. Run parallel with existing WAN during pilot — SD-WAN carries production traffic while MPLS remains available for rollback. Measure application performance, helpdesk ticket volume, and operational overhead during pilot before committing to MPLS contract reductions.
Monitor tunnel health, path utilization, policy hit counts, and controller synchronization status. Alert on single-underlay-active conditions at dual-homed sites. Plan controller redundancy and document behavior during split-brain scenarios. SD-WAN succeeds when transport diversity, application-aware policy, and security integration are designed together — not when overlay tunnels are simply draped over existing single-homed branch connectivity with unchanged operational practices.
Vendor Evaluation Framework
Compare SD-WAN vendors against structured criteria: tunnel protocol standards compliance, independent third-party security audits, behavior during split-brain controller scenarios, maximum tunnel throughput per appliance model, integration with your existing SIEM and ITSM tools, and contractual exit provisions avoiding proprietary lock-in that prevents migration. Request reference customers with similar branch counts and application mixes, not just flagship deployments unlike your environment.
Lab evaluation should simulate your actual underlay — introduce latency, jitter, and loss on test links to validate path selection behavior under degradation. Test zero-touch provisioning workflows for new branch deployment because operational time savings during rollout often justify SD-WAN investment as much as ongoing MPLS cost reduction. Measure mean time to deploy a new site with SD-WAN versus traditional router configuration to quantify operational benefits for business case documentation.
Plan for coexistence duration realistically — most enterprises run SD-WAN parallel with MPLS for twelve to twenty-four months during migration. Budget dual connectivity costs during overlap rather than assuming immediate MPLS elimination. Contract renewal negotiations with MPLS providers change when SD-WAN provides viable alternative paths; use evaluation results as leverage while maintaining provider relationships needed for sites not yet migrated.
Regulatory and Data Residency
Regulated industries may require traffic inspection within specific geographic boundaries. SD-WAN local internet breakout routes traffic through branch countries directly to internet, potentially bypassing data center inspection in home countries. Policy must enforce backhaul for regulated traffic classes while permitting local breakout only for approved SaaS applications meeting residency requirements.
Document data flows after SD-WAN deployment for compliance audits. The same application may traverse different paths before and after SD-WAN adoption — compliance teams need updated data flow diagrams reflecting local breakout, cloud security inspection, and encrypted tunnel termination points for privacy impact assessments.