What Is SD-WAN? How It Works, How It Differs from MPLS, and Where to Place the Hub

In a multi-branch organization, a complaint that “the cloud application is slow” does not always originate in the application itself. If traffic travels from the branch to headquarters, through the security controls there, and then out to the internet, even a cloud service close to the user may be reached by a roundabout route. However, attributing all latency to the WAN connection without measuring the network path is equally misleading; the local network, DNS, authentication, and the application itself all belong in the same investigation.

SD-WAN is a wide area networking approach that manages branch, data center, and cloud connectivity through software-based policies and can select a suitable traffic path according to application requirements and measured path quality. It is not a new type of circuit that replaces MPLS or internet connectivity; it can use these connections together.

This guide explains how SD-WAN works, how it differs from MPLS and VPN, its limitations, and the steps involved in migration for IT directors, infrastructure and network managers, security teams, and enterprise architects. It focuses particularly on one design decision: Where should traffic requiring centralized access converge, which traffic should break out locally, and how should the architecture behave during a failure?

Placing the hub in an office server room, a colocation facility, the cloud, or a managed connectivity location changes both connectivity options and the operating model. However, not every SD-WAN architecture requires a single hub. The policy, testing, and cost tables below are examples intended to support decision-making; they are not configurations for a specific product, service commitments, or actual customer results.

What Is SD-WAN?

SD-WAN stands for Software-Defined Wide Area Network. The approach separates transport connectivity from application policies. An organization can use MPLS-based IP VPN, fiber internet, xDSL, or 4G/5G access across different locations while defining, through a common policy model, which application should use which path under which conditions.

For example, an order-processing application may prioritize a stable connection throughout a transaction. For video meetings, jitter and packet loss may be more prominent concerns. An overnight data transfer can be scheduled to use the remaining capacity. The purpose of the design is not to impose the same path on every application, but to translate business requirements into network behavior.

“Software-defined” does not mean that hardware requirements disappear. Physical or virtual endpoints that process traffic at branches or in the cloud, connectivity services, and a management mechanism are still required. Centralized management or segmentation can provide benefits even over a single connection; however, without an alternative path, switching paths cannot provide redundancy.

SD-WAN is one application of the broader SDN approach in the WAN context; it does not automatically redesign the entire data center network. In hybrid cloud management, it supports the connectivity layer rather than replacing decisions about application dependencies and data placement.

When Does a Traditional WAN Struggle?

A centralized egress model may be appropriate when branches mainly access applications at headquarters. However, when SaaS and multiple cloud environments are introduced, applying the same model to every traffic flow can add distance and processing overhead. Microsoft 365 connectivity principles also recommend reducing unnecessary network detours and considering suitable local egress. This does not mean disabling all security inspection.

Backhauling cloud traffic through headquarters

Backhauling means sending branch traffic to a central point before it reaches its actual destination. The problem is not the existence of a “center,” but failing to assess whether routing through it is necessary for the application. The best path to an ERP system in the data center may differ from the best path to an internet-based collaboration application.

Managing connectivity procurement and changes

When opening a new location, plan circuit delivery, local access quality, security appliance installation, and policy approvals together. SD-WAN can make deployment over an existing connection easier; it cannot create a fiber circuit that has not been delivered or mobile coverage where none exists. Compare the lead times and costs of internet connections and private circuits for the specific location and contract.

Failing to validate continuity despite having a backup link

Buying a second connection does not mean the failure scenario has been addressed. Separately check the backup link’s capacity, reachable destinations, security policy, and application behavior during failure. Investigate whether two contracts depend on the same building entrance or upstream provider. Traditional networks can also use dynamic routing and automation; do not reduce the SD-WAN comparison to “the old network is unintelligent, the new one is intelligent.”

How Does SD-WAN Work?

SD-WAN establishes logical connections over existing access networks; edge devices classify traffic and select among permitted paths according to policy. Centralized management does not require user packets to pass through the management server. In Cisco’s architecture, for example, control components distribute routing and policy information while edge devices carry data traffic; different vendors may combine these functions in different components.

Do not think of the underlay solely as a “physical cable”: a carrier’s IP service can also form part of this layer. Likewise, the overlay alone is not a security guarantee; validate the encryption and authentication capabilities of the tunnel being used.

How does application-aware routing make decisions?

Application-aware routing identifies traffic and compares measurements such as latency, packet loss, and jitter against policy conditions. Path selection is not simply a search for the lowest latency: permitted connections, cost preferences, security requirements, and behavior when no suitable path is available also influence the decision. The set of thresholds a product calls an “SLA class” is not the same as a contractual SLA signed with a carrier.

First, record the endpoints between which measurements are taken. A test between a branch and a hub does not automatically cover the path from the hub to a SaaS application. Do not use round-trip time (RTT), one-way latency, and jitter measurements interchangeably. Two paths shown as green on the same dashboard may have been evaluated against different destinations or over different measurement periods.

Traffic classification also requires evidence rather than assumptions. When application signatures, destination addresses, ports, or markings are used, validate during the pilot that actual flows match the expected class. Define the scope of recognition for encrypted applications with changing endpoints, and separately specify the default policy for unrecognized traffic.

A link outage and performance degradation are different events

A circuit becoming completely unreachable and a gradual increase in packet loss may require different detection mechanisms. Measurement frequency, the averaging period, the number of consecutive failures, and the hold-down period before returning to a recovered path balance responsiveness against stability. Advanced routing options in vendor documentation reflect this distinction; there is no single failover time that applies to all products.

Add two more decisions to the policy: If every path falls below the quality target, should traffic use the best remaining path, or should specific flows stop? When the original link recovers, should traffic return immediately or wait until stability has been confirmed? Security and application owners should approve these decisions.

What Is the Difference Between SD-WAN and MPLS?

MPLS is a label-switching architecture; SD-WAN is an approach to using connections according to policies and application requirements. In enterprise procurement discussions, an “MPLS link” usually refers to a carrier-provided, MPLS-based IP VPN service. The right comparison is therefore not “Which technology eliminates the other?” but “Which transport services will we use, and under which policies?”

The logical separation provided by an MPLS-based IP VPN does not mean that data is cryptographically encrypted; RFC 4364 explicitly makes this distinction. Similarly, an SLA for an internet connection does not imply an end-to-end performance guarantee to every destination across the internet. Review the contract’s measurement points and exclusions.

An SD-WAN project does not require MPLS to be removed. An organization can retain MPLS at one location, use two internet connections at another, and reserve mobile access for critical transactions elsewhere. Make the decision based on application requirements, actual test results, and total cost rather than the name of the technology.

What Is the Difference Between SD-WAN and a Conventional VPN?

VPN addresses secure or logically private connectivity; SD-WAN addresses the management of such connections at scale through application policies. The comparison here concerns site-to-site VPNs between locations. VPN or ZTNA access for remote workers is a separate design topic.

The generalization that “VPN is static, SD-WAN is dynamic” is incomplete. VPN tunnels can support dynamic routing such as BGP and redundant tunnel mechanisms; AWS Site-to-Site VPN documentation provides a clear example. SD-WAN’s distinction is its ability to bring together application classification, path quality, centralized policy, and lifecycle management.

During procurement, go beyond asking, “Does it support VPN?” How is policy preserved across different tunnels? How are existing sessions affected? Which measurements govern application traffic routing? How are changes audited? The enterprise value lies in the answers to these questions.

What Are the Benefits and Limitations of SD-WAN?

SD-WAN creates value by connecting existing network services to business requirements, not simply by buying more links. The table below can help distinguish a design objective from the conditions required to achieve it.

Are sessions always preserved when a link changes?

No. Finding a new path is not the same as maintaining an existing application session without interruption. In particular, switching to another ISP for local internet egress can change the source public IP address. NAT state, firewall sessions, remote endpoint behavior, and the application’s ability to reconnect all affect the outcome. Fortinet’s technical guidance also describes specific conditions for reassessing NAT sessions.

During the pilot, do not stop at demonstrating that a new connection can be established. Test an ongoing file transfer, an active ERP session, and a call separately. Do not report a path change within an encrypted overlay and a change of direct internet egress as though they were the same test.

Do two internet links double the speed of a single connection?

Distributing flows across different links does not demonstrate that a single transfer will achieve the sum of all link speeds. Some solutions distribute traffic by session or address; support for specialized bandwidth-bonding mechanisms requires separate evaluation. Fortinet’s SD-WAN rule options also define different session- and address-based distribution methods.

For example, two 100 Mbps connections can provide more aggregate capacity to different flows, but they do not automatically guarantee 200 Mbps for a single flow. Measurements must also account for tunnel overhead, security processing capacity, and remote endpoint limitations.

The impact of a poor link can be reduced, but not every problem can be fixed

In some products, forward error correction (FEC) or packet duplication can help an application under specific packet-loss conditions. These features consume additional bandwidth and CPU resources, and the supported tunnels and traffic types vary. For example, Palo Alto Networks documentation calls for selective use and consideration of product-specific limitations. These features do not guarantee protection against a physical outage or insufficient capacity.

At a location with two poor-quality links, the first decision may therefore not be to buy new software. It may be necessary to improve last-mile access, fix the local network, or select a more suitable carrier path.

Where Should the Hub Be Placed in an SD-WAN Architecture?

A hub is a data-forwarding point to which branches send traffic to reach specific destinations, use shared security services, or connect to other networks. It does not serve the same function as the management dashboard. A hub can be in a data center while the management system runs in the cloud; some flows can also reach their destination directly without passing through the hub.

Single-hub hub-and-spoke, multiple regional hubs, and mesh models that permit direct branch-to-branch communication address different requirements. Cisco’s design guide evaluates these topologies alongside tunnel scale and regional design. Therefore, neither “SD-WAN must have a single center” nor “Let’s send all traffic through the same data center” is the right starting point.

What does a carrier-neutral environment provide, and what does it not guarantee?

A carrier-neutral data center offers a choice of providers that reduces enforced dependence on a single connectivity provider. However, the presence of multiple carriers in one facility does not automatically prove that two purchased circuits are physically independent. A shared duct, building entrance, intermediate carrier, or power component can affect both connections.

Investigate shared failure domains rather than simply counting providers. Which routes do the two circuits follow? Are there separate entrances? Do different contracts use the same last-mile infrastructure? Can the backup connection also be used during planned maintenance? Link diversity becomes a real continuity design through the answers to these questions.

Peering, internet access, and private cloud connectivity are not the same

Peering concerns traffic exchange between participating networks; private cloud connectivity provides defined access to a particular cloud provider. DE-CIX also defines GlobePEER and DirectCLOUD as separate service scopes. Access to an internet exchange does not imply a direct route to every internet destination or the lowest latency for every application.

When selecting a hub, complement “Which exchange is it close to?” with “Through which peering or transit relationships do we reach our destination networks?” Evaluate the provider’s Internet Exchange and peering options separately from its Direct Cloud Access connections. Purchasing access to one does not automatically activate the other.

Do not assume that a private circuit to the cloud is encrypted by default. For example, AWS Direct Connect explicitly states that it does not encrypt traffic in transit by default; IPsec or suitable MACsec options require separate evaluation. This distinction means that “isolation” and “encryption” requirements should be addressed separately in every private connectivity design.

A capable hub does not require all SaaS traffic to pass through it

An organization can use a colocation hub for enterprise application access while designing egress close to users for approved SaaS flows. For Microsoft 365, local egress and suitable DNS resolution should be evaluated together; for a different SaaS product, follow that provider’s own connectivity guidance. Do not automatically force all cloud traffic into a single model.

The critical decision is less about “centralized or distributed” and more about which application will use which path under which security and access conditions. Centralized ERP, local SaaS egress, a private cloud circuit, and restricted mobile backup can coexist within the same organization.

How should a redundant hub design be evaluated?

Two devices in the same rack can help protect against device failure, but they do not provide the same protection against the loss of the facility. Define the backup hub’s role according to the chosen risk scenario. A single device failure, a carrier outage, the loss of a building, and a regional outage are different events; the same redundancy mechanism may not be sufficient for all of them.

Locating the hub close to backup and recovery environments can simplify connectivity planning. However, placing the primary application, every hub, and recovery access within the same failure domain creates a separate risk. A network recovery plan should cover more than spare devices: it must also address access to alternative destinations, DNS, identity services, and management connectivity.

This table is a design assessment tool, not a product ranking. Evaluate a hub’s measured capacity with the actual functions enabled rather than its advertised port speed. For a virtual hub, do not treat CPU, network interface, and licensing limits as though they were a single capacity figure.

What Is the Relationship Between SD-WAN, SASE, and SSE?

SD-WAN focuses on connectivity and traffic policies; SASE is a broader framework that integrates networking and security functions. SSE refers to the security-focused part of that framework. Similar names do not imply identical scope. Mplify’s SASE framework addresses connectivity, security, policy, and Zero Trust requirements together.

When comparing SSE and SASE, examine the functions the product actually includes. The scope of secure web gateway (SWG), cloud access security broker (CASB), Zero Trust Network Access (ZTNA), and firewall capabilities can vary under the same package label.

Where will security be enforced when local internet breakout is enabled?

If a branch is given internet egress independent of headquarters, document which controls are applied at the edge device, through a cloud-based security service, and at the endpoint. Define separate requirements for enterprise users, guests, management traffic, and third-party access. Do not create an alternative path that unintentionally bypasses the security chain in pursuit of performance.

WAN segmentation can help separate access between branches or business units; it does not automatically provide authorization within an application or workload-level control. Consider this distinction alongside the Zero Trust approach and the microsegmentation guide (in Turkish).

Protect the management layer as well

Centralized policy distribution amplifies the impact of a management account. Multi-factor authentication, role-based permissions, controlled administrative access, configuration change logs, and software update processes should therefore be included in the project. Joint international guidance on network hardening also emphasizes visibility into management connections and strong authentication.

Also plan device certificate renewal, configuration backups, service account permissions, and an emergency management path. Approve decisions such as stopping traffic or allowing restricted continuation when the security service cannot be reached; do not leave the default behavior to be discovered during an outage.

When Does SD-WAN Make Sense, and When Can It Add Unnecessary Complexity?

Do not base the decision solely on branch count. Multiple locations, varying link quality, extensive SaaS usage, frequent branch openings, and the need for consistent policies strengthen the case for evaluation. However, an organization with only two locations can also benefit because of critical business continuity or centralized management requirements.

Focus on three questions in the initial assessment: Which measured problem in the existing network is being addressed? Can SD-WAN solve it more appropriately than the alternatives? Is there a responsibility model for operating policies and monitoring results? If the only objective is to purchase a lower-cost connection, include a simpler dual-WAN solution in the comparison.

Having all applications in one data center does not automatically make SD-WAN unnecessary; link diversity, segmentation, or operational standardization can still add value. Conversely, if the network is simple, performance is adequate, and change requirements are limited, an additional licensing and operating layer may not deliver enough benefit. Support the decision with a pilot and a like-for-like cost comparison.

Eight Practical Steps to an SD-WAN Migration

An SD-WAN migration begins with understanding existing traffic and failure scenarios, not with selecting a device. The sequence below is a project framework; security and operating decisions should not be left to the final steps, but should accompany every phase from the outset.

1. Build a location and connectivity inventory

For each location, record connection type, provider, capacity, actual usage, public IP/NAT status, contract expiry, and backup access. Add the device model, software support, power, local network, and site access to the same inventory. Mark the assumption that two connections are independent as a separate item requiring verification.

2. Classify applications and dependencies

Create groups such as ERP, voice/video, SaaS, data transfer, and guest access, while ensuring that every application has an owner and a defined business impact. Record dependencies such as IP allowlists, DNS, identity providers, license servers, and external business partners. A test showing that “internet access works” does not prove that these dependencies work.

3. Establish baseline quality and acceptance criteria

Take baseline measurements covering peak hours and periodic business activities. Evaluate application transaction time, error rates, and user behavior during outages alongside network data. Define RTT and packet-loss thresholds with the application owner rather than copying them from another organization. Record the measurement endpoints and observation period.

4. Make a separate decision on hub and egress architecture

Map the forward and return paths for enterprise application, SaaS, internet, and private cloud traffic. Define the backup hub, NAT, security inspection, and alternative egress IPs as well as the hub’s location. Check whether mobile links or connections behind NAT meet the selected product’s tunnel-establishment requirements. Investigate MTU-related issues through large-packet and real-application tests.

5. Select pilot locations with different profiles

Do not run the pilot only at headquarters where connectivity is good. A busy branch, a site with limited connectivity, and a location using a different access type can provide a more meaningful comparison. Plan tests for link loss, performance degradation, hub loss, and recovery as well as normal operation. Do not begin a broad rollout before pilot results are approved.

6. Change the role of existing MPLS and other connections based on measurements

Rather than automatically removing MPLS, decide at which locations it should remain as a primary or backup path. Change its role gradually when contracts, rollback requirements, and test results allow. Before canceling a transport service, confirm that the new architecture can support all critical business periods and that rollback remains feasible if needed.

7. Implement security policy within the same change plan

Local internet breakout, segments, device management, and cloud security services should be tested together. Are existing access rules compatible with the new egress IPs? Have third-party permissions been updated? Does the alternative path enforce the same security controls? Do not grant acceptance on performance results alone before these questions have been answered.

8. Complete monitoring, acceptance, and operational handover

Document who is responsible for policy changes, carrier outages, device replacement, and security incidents. Test configuration backups and the rollback procedure. As in the observability approach (guide in Turkish), connect infrastructure status to the outcome of the business service. The project ends not when devices appear on a dashboard, but when acceptance conditions are met and operations have been handed over.

Example: How to Design an SD-WAN Pilot for an Organization with 20 Branches

The following scenario is fictional. It is not an actual customer case, a commercial offer, a measured performance result, or a ready-made configuration for a particular product. Its purpose is to show how different paths for different applications can be evaluated within the same network.

Assume that an organization has 20 branches and that its ERP application runs in a colocation environment in Ankara. The branches also use SaaS collaboration tools. Some locations have both MPLS and internet access; others have internet access with mobile backup. Initially, all internet traffic exits through headquarters.

Proposed design hypothesis

The organization evaluates routing ERP traffic through a hub with access to the application environment and approved SaaS traffic through a secure egress point appropriate for the user. A second hub in a different failure domain is considered for access to the recovery environment. Mobile connectivity is planned as an option for sustaining defined critical transactions, not as an unlimited backup that will absorb the entire workload.

Three pilot locations are selected: a branch with a high transaction volume, a branch with fluctuating link quality, and a site that relies on mobile backup. Actual traffic classification and ERP transactions are validated first. A complete link outage and performance degradation while the link remains up are then tested separately.

Distinguish a network target from a business acceptance criterion

For example, solely for this pilot, the team might select a branch-to-hub RTT of no more than 80 ms, measured jitter of no more than 20 ms, and packet loss of no more than 1% as a starting point for investigation. These values are not universal standards or recommended service levels. They must be defined together with the measurement period and the device’s calculation method, then adjusted based on application testing.

The ERP acceptance criterion is different from the network counter: for example, order transactions must complete under the approved user load, no transaction may be lost during a path change, and retries must not create duplicate records. While the network team validates the path, the application owner validates the transaction outcome. This check prevents the assumption that SD-WAN alone ensures data consistency within the application.

At the end of the pilot, the report should go beyond “latency decreased.” Which application used which path? How many sessions were re-established during each event? Were security controls preserved? Was the remaining capacity adequate? Record the results in the acceptance matrix and decide on remediation and retesting for unmet conditions.

Which Tests Should an SD-WAN Pilot Include?

Acceptance testing distinguishes a device’s supported feature list from the behavior the organization actually needs. Run the tests below in a controlled pilot environment with an approved change and rollback plan. Establish success thresholds before testing; the table does not prescribe universal time or performance targets.

Loss of access to the management dashboard is not the same failure as a hub being unable to forward data. In some designs, edges may continue forwarding for a period using the last valid information; the relationship between that period and route and key lifecycles varies by product. Cisco’s explanation of graceful restart is one example and cannot be generalized to all SD-WAN products.

Use a real application transaction for each test. A successful ping does not prove that authentication, a TLS session, or an order-processing workflow has completed. Include forward and return traffic, large data transfers, DNS, and external integrations in the test scope.

How Should SD-WAN Cost and Vendor Lock-in Be Evaluated?

The economics of SD-WAN cannot be calculated simply by comparing an MPLS invoice with an internet invoice. Calculate total cost of ownership for the same number of locations, capacity, security scope, and service expectations. The table below is not a price estimate; it defines the cost categories needed to compare proposals on an equal basis.

As a simple comparison framework: total cost = one-time setup/migration costs + recurring expenses over the chosen period + internal operating effort + planned exit costs. Avoid double-counting an item that appears in more than one device, service, or licensing proposal. Evaluate the financial impact of downtime risk as a separate scenario from these defined expenses; do not present a hypothetical benefit as realized savings.

Discuss vendor lock-in from the outset as well. Using standard components such as IPsec or BGP does not prove that different vendors’ policy engines and control planes are interchangeable. Ask what rights the organization has over policy definitions, inventory, configurations, logs, API access, and credentials when changing providers. The Vendor Lock-in guide examines this exit assessment in the broader infrastructure context.

Use the same scope when comparing self-management with a managed service. If carrier fault coordination, after-hours intervention, security updates, and policy approval sit with different parties, the totals in two proposals may not represent the same work.

How Should Monitoring and Operational Responsibilities Be Shared?

A centralized dashboard does not automatically centralize responsibility. A performance issue may originate in the access link, SD-WAN policy, security layer, or application. Define incident ownership and a joint investigation process to prevent every incident from simply being passed to the next supplier.

In addition to tunnel status, the monitoring plan should consider which application uses which path, policy matches, time spent outside critical thresholds, session re-establishments, and change history. Make peak periods and user impact visible alongside averages. When evaluating Managed Services, clarify which of these network and application indicators are included in the monitoring scope.

During a post-incident review, do not settle for explanations such as “the link was green” or “the device was running.” Record the onset of the issue, policy changes, path transitions, and the point at which the application became usable again on a shared timeline. Lasting improvement comes not from generating more alerts, but from understanding the cause and preventing recurrence.

Pre-Migration SD-WAN Checklist

Use the following checklist as a readiness table at the beginning of the project. Add your organization’s responsible owner, target date, and evidence link to each row. Do not mark an unfinished item as complete simply because it has been discussed in a meeting.

Frequently Asked Questions About SD-WAN

Does SD-WAN completely replace MPLS?

No. MPLS-based IP VPN can remain one of the transport services used by SD-WAN. Decisions about where to retain it depend on application requirements, performance measurements, redundancy, and cost. Canceling existing connectivity before acceptance testing of the new architecture is complete is not a sound migration assumption.

Does SD-WAN make internet connectivity guaranteed?

Not on its own. It can reduce the impact of a problem by selecting among available paths. However, it cannot eliminate a shared physical failure affecting both paths or compensate for insufficient alternative capacity. Review the guarantees, measurement points, and exclusions in internet and managed service contracts separately.

Are SD-WAN and VPN the same thing?

No. A site-to-site VPN provides a tunnel or private connection between locations; SD-WAN can use these connections alongside application policies, quality measurements, and centralized management. A VPN is not necessarily static; dynamic routing and redundant tunnels can also be used.

What is the difference between SD-WAN and SASE?

SD-WAN focuses on WAN connectivity and traffic management. SASE combines connectivity and security functions within a common architecture. SSE refers to the security-focused components. Purchasing an SD-WAN product does not mean that all SASE requirements have been met.

Does a small company need SD-WAN?

Location count is not the sole decision criterion. Even an organization with two branches may need critical connectivity and centralized policies. Conversely, the additional cost and operational effort may be excessive for a simple, stable network that changes infrequently. Evaluate it alongside simpler options that meet the same requirements.

Should SD-WAN be managed in-house or through a managed service?

The decision depends on team skills, support hours, change frequency, and the desired level of control. Even in a managed model, application priorities, security approvals, and business acceptance must have clear owners. Compare responsibility matrices, scope, and escalation mechanisms rather than service names.

Does SD-WAN always require a hub?

A single central hub is not mandatory in every architecture. Direct branch-to-branch connectivity, regional hubs, cloud edges, and local internet breakout can be used together. Application placement and security requirements determine which flows should pass through a hub.

Is using two carriers in a carrier-neutral data center enough?

Provider choice is an important starting point, but actual redundancy requires route and shared-infrastructure validation. The same building entrance, duct, or upstream provider can affect both circuits. The number of separate contracts is not the same as the number of separate failure domains.

Can active sessions disconnect when a link changes?

Yes. Public IP addresses, NAT, firewall session state, tunnel behavior, and application reconnection all influence the result. Test link transitions separately with new connections and ongoing transactions. Seamless operation cannot be assumed from the product name.

Does SD-WAN combine two links’ speeds for a single transfer?

Not in every solution or for every flow. Distributing sessions across links can improve aggregate utilization; achieving their combined speed for a single transfer is a separate capability. When required, validate bandwidth-bonding support, remote endpoint requirements, and performance with actual traffic.

Does the entire network stop if the controller cannot be reached?

It depends on the product and design. Some systems continue forwarding under defined conditions using the last valid routes and policies; new device onboarding, route changes, or key renewal may be affected. Test loss of controller access, management access, and hub availability separately.

How long does an SD-WAN migration take?

The duration depends on the number of locations, circuit delivery, security integrations, application dependencies, and pilot results. Onboarding a device over an existing connection is not the same as completing an enterprise migration. Plan discovery, pilot, acceptance, phased rollout, and operational handover separately.

Ixpanse and the Connectivity Layer of an SD-WAN Architecture

Regardless of the SD-WAN product, assess the hub’s hosting environment, carrier options, and enterprise application access design. The carrier-neutral infrastructure approach described in Ixpanse’s Colocation service and the connectivity options within Ankara IX provide a basis for considering hosting and access together in this assessment.

For branch-side operational requirements, review the managed network approach within Premise Services; for security and continuity requirements, review Data Protection services separately. Do not assume that the SD-WAN product, licensing, policy operations, carrier service, and cloud connection share the same scope; the project and contract should clarify which party provides each element.

To assess hub placement, multi-carrier design, colocation requirements, and cloud access paths together, contact the Ixpanse expert team. Preparing your location list, critical applications, existing connections, and acceptable outage conditions before the discussion will support an assessment tailored to your requirements.

Conclusion: SD-WAN Is a Traffic and Responsibility Decision Before It Is a Device Decision

SD-WAN makes it easier to use different connections under a common policy, but it does not remove application requirements, the importance of physical link quality, or operational responsibility. It can work alongside MPLS, use VPN technologies, and form the connectivity component of a SASE architecture. Its value should be measured by validated behavior, not by the label applied to it.

A sound design explains where each application runs, which paths it may use, where security inspection is enforced, and what happens during a failure. Carrier-neutral colocation can be a strong hub option in suitable scenarios; however, neither centralizing all traffic nor treating two links as redundant without validating their independence is a sound assumption.

The first question in an SD-WAN project should not be “Which device should we buy?” but “Which business transaction depends on which connection, what happens if that path degrades or fails, and how will we prove the outcome?” Organizations that answer through inventory, pilots, acceptance tests, and clear operational responsibilities can connect technology selection to concrete business requirements.

Related Content

What Is a Carrier-Neutral Data Center? · What Is Direct Cloud Access? · What Is an Internet Exchange? · Network Recovery Guide · What Is Vendor Lock-in? · What Is Hybrid Cloud?

Technical Sources

The general architectural explanations in this guide are supported by the standards bodies, vendors, and official technical sources below. Behaviors described in vendor documentation are specific to the relevant product and version; they should not automatically be assumed to apply to other solutions. The example policy tables, pilot scenario, acceptance matrix, and cost framework are assessment tools prepared for this article.

1. Mplify Alliance — SD-WAN Service Standards. The SD-WAN service, application flows, and the distinction between edge and underlay.
2. Cisco — Catalyst SD-WAN Solution Overview. Control, management, and data planes; underlay and overlay. A product-specific architectural example.
3. Microsoft Learn — Microsoft 365 Network Connectivity Principles. Local egress, network detours, and access to the appropriate cloud entry point for Microsoft 365.
4. Cisco — Application-Aware Routing. Latency, packet loss, jitter, policy-based path selection, and behavior when thresholds are not met.
5. Cisco — Enhanced Application-Aware Routing. Measurement periods, degradation detection, and stable path recovery. Version and feature dependencies apply.
6. IETF — RFC 3031: Multiprotocol Label Switching Architecture. MPLS as a label-switching architecture.
7. IETF — RFC 4364: BGP/MPLS IP Virtual Private Networks. The carrier IP VPN model and the distinction between logical isolation and encryption.
8. AWS — Static and Dynamic Routing in Site-to-Site VPN. Static or BGP-based dynamic routing over VPN and redundant tunnel behavior.
9. Fortinet Technical Tip — Routing Change and Session Fail-over with SD-WAN. Conditions for NAT and session reassessment. Validate against the specific product and version.
10. Fortinet — SD-WAN Rules. Examples of flow/session- and address-based load distribution; not a general guarantee of bandwidth bonding.
11. Palo Alto Networks — Recover Corrupted or Lost Data to Improve Reliability. FEC, packet duplication, additional bandwidth/CPU cost, and product-specific support limitations.
12. Cisco — Catalyst SD-WAN Design Guide. Hub, mesh, and regional topologies; tunnel scale and behavior when controller access is lost.
13. DE-CIX — GlobePEER. The scope of peering services and traffic exchange between networks.
14. DE-CIX — DirectCLOUD. Private cloud connectivity and the cloud exchange model.
15. AWS — Encryption in AWS Direct Connect. The absence of default encryption on a private connection and additional encryption options.
16. Mplify Alliance — SASE Service Framework. Evaluating connectivity, security, policy, and Zero Trust components together.
17. Palo Alto Networks — SD-WAN vs. SASE vs. SSE. Comparing the scope of SD-WAN, SASE, and SSE.
18. ASD / ACSC and international partners — Enhanced Visibility and Hardening Guidance for Communications Infrastructure. Management access, strong authentication, logging, and network infrastructure hardening.