For two decades, MPLS was the unquestioned standard for enterprise wide-area networking. It delivered guaranteed bandwidth, predictable latency, and end-to-end quality of service — and enterprises paid dearly for those guarantees. Then cloud happened. Then SaaS happened. Then a global pandemic forced every organization to rethink how and where work gets done. Today, MPLS is not dying — it is being systematically replaced by SD-WAN, and the organizations making this transition thoughtfully are discovering performance improvements, cost savings, and operational flexibility that MPLS could never have delivered. The ones making the transition carelessly are discovering a new category of security and operational problems that are entirely avoidable.
Why MPLS is Being Replaced: The Economics and Architecture Have Both Failed
MPLS made sense in a world where enterprise applications lived in corporate data centers and traffic followed predictable hub-and-spoke patterns. Traffic from a branch office traveled to headquarters, went through the corporate firewall and proxy, accessed the application in the data center, and returned. The entire traffic model was centered on the data center as the hub of enterprise computing.
That world no longer exists. In most enterprises today, 60 to 80 percent of traffic from branch offices is destined for cloud and SaaS applications — Microsoft 365, Salesforce, SAP on Azure, video conferencing platforms, HR systems. Routing that traffic through headquarters before allowing it to reach the internet creates a severe performance penalty: traffic that could flow directly from the branch to the SaaS provider instead takes an inefficient detour through the corporate data center, adding latency and consuming expensive MPLS bandwidth for traffic that should never have been on the private WAN at all.
The cost differential is stark. MPLS circuits typically cost between 300 and 600 USD per megabit per month, depending on geography and provider. Enterprise broadband in the same locations costs 10 to 30 USD per megabit per month — an order of magnitude less expensive. For organizations running 10 Mbps MPLS circuits at multiple sites, replacing those circuits with 100 Mbps broadband connections while deploying SD-WAN to manage quality and reliability is not a marginal improvement — it is a fundamental economic transformation of the WAN.
For Norwegian enterprises, the geography adds additional complexity. Branch offices in smaller cities and towns, offshore oil and gas platforms, remote industrial sites, and distributed retail networks all have WAN connectivity requirements that MPLS cannot serve economically. SD-WAN's ability to aggregate multiple lower-cost connections — broadband, 4G/5G, satellite — and provide policy-based path selection across that aggregate is precisely what distributed Norwegian enterprises need.
SD-WAN Fundamentals: How It Actually Works
SD-WAN separates the WAN control plane from the data plane. Traditional WAN routers make forwarding decisions locally, based on routing protocols and static configuration. SD-WAN centralizes policy definition while distributing policy enforcement to edge devices at each site.
Overlay Networking and Path Selection
SD-WAN creates encrypted overlay tunnels across all available WAN transport links — MPLS, broadband, 4G/5G, or any combination. These tunnels form a mesh of connectivity between sites. The SD-WAN controller continuously monitors the performance characteristics of each tunnel: latency, jitter, packet loss, and available bandwidth. Based on this real-time performance data and application-specific Quality of Service policies, the SD-WAN platform selects the optimal path for each traffic flow.
The result is dynamic path selection that traditional WAN routers cannot achieve. A VoIP call that requires low latency and jitter will be steered to the path that meets those requirements at that moment. A bulk data transfer that is latency-insensitive will use whatever path has spare capacity. If a primary circuit degrades or fails, traffic is automatically shifted to alternative paths — often within seconds, rather than the minutes required for OSPF or BGP convergence on traditional WAN architectures.
Application-Aware Routing
SD-WAN platforms recognize applications using deep packet inspection, similar to NGFW application awareness. This allows policies to specify not just quality requirements but also routing preferences by application. Microsoft Teams traffic can be sent directly from the branch to the internet via local breakout. SAP traffic that requires guaranteed performance can be pinned to a dedicated MPLS circuit. Development and test traffic can be deprioritized during business hours. These policies are defined centrally and enforced consistently at every site — without requiring per-site router configuration.
Zero-Touch Provisioning
New SD-WAN sites can be deployed without on-site technical expertise. A pre-configured edge device is shipped to the site; a local employee plugs in the WAN connections and powers it on. The device calls home to the SD-WAN orchestrator, receives its configuration, establishes tunnels, and begins operating within minutes. This zero-touch provisioning model transforms WAN operations: new sites that previously required specialized network engineers and multi-week installation timelines can be deployed by non-technical staff in an hour.
Security Integration: The Part That Organizations Get Wrong
This is the section that deserves the most attention, because it is where SD-WAN deployments most commonly fail to deliver their promised value — and sometimes actively create security risk.
SD-WAN is not a security product. It is a connectivity and performance product with some security features (encryption, application identification) included. Treating SD-WAN as a comprehensive security solution is one of the most dangerous mistakes an enterprise can make in a WAN modernization project.
The Local Breakout Security Problem
One of SD-WAN's primary value propositions is local internet breakout: sending internet-bound traffic directly from each branch to the internet, rather than routing it through headquarters. This eliminates the performance penalty of backhauling cloud and SaaS traffic across the private WAN. But local breakout means branch traffic is reaching the internet without passing through the centralized security stack at headquarters — the firewalls, proxies, DLP systems, and other controls that protect headquarter-based users.
If local breakout is deployed without compensating security controls at each branch, those branches are effectively connecting directly to the internet with minimal protection. This is a real and significant risk, particularly for smaller branch offices that may have previously relied entirely on headquarters security infrastructure.
SASE: The Right Answer for Cloud-First Enterprises
Secure Access Service Edge (SASE) addresses the local breakout security problem by moving security controls into the cloud, close to where both users and cloud applications are. Rather than backhauling branch traffic to a headquarters firewall, SASE routes branch internet traffic to the nearest cloud security point of presence, where it is inspected by cloud-native security services: URL filtering, malware detection, data loss prevention, cloud access security broker controls, and zero-trust network access.
Leading cloud security providers operate global networks of security points of presence that provide both performance and security: branch traffic reaches the cloud security service with low latency, is inspected and policy-enforced, and is then forwarded to its destination. The security stack follows the user rather than requiring the user to reach a specific corporate location.
For organizations evaluating SD-WAN, the question of security integration should be answered before the SD-WAN architecture is finalized. SASE integration requirements will influence the choice of SD-WAN platform, the topology of the deployment, and the cost model of the overall solution.
Firewall at the Branch
Not every organization is ready for full SASE adoption. An alternative approach for local breakout security is deploying NGFW capabilities at each branch — either as dedicated appliances or as security services integrated into the SD-WAN edge device. Branch firewalls with URL filtering, IPS, and application control can provide meaningful protection without the architecture shift that full SASE requires.
The tradeoff is operational complexity: managing security policies across dozens of branch firewalls requires centralized management infrastructure and dedicated operational attention. For organizations with small IT teams and many sites, SASE typically provides better security with less operational overhead than distributed branch firewalls.
SD-WAN Architecture Options: Choosing the Right Model
There is no single SD-WAN architecture. Understanding the available models and their tradeoffs is essential for making the right choice for your organization.
DIY SD-WAN with Hardware at Each Site
The traditional SD-WAN deployment model involves purchasing and deploying dedicated SD-WAN hardware appliances at each site. Your team manages the SD-WAN platform — orchestrator, policies, upgrades, troubleshooting. This model provides maximum control and can be the right choice for organizations with strong internal networking expertise and specific customization requirements.
The operational demands are significant. Someone must maintain the orchestration platform, manage firmware updates, respond to failures, and handle the ongoing configuration management as the business evolves. For many organizations, these demands exceed what internal teams can sustain while also managing other networking and security responsibilities.
Cloud-Managed SD-WAN
Cloud-managed SD-WAN platforms simplify operations by hosting the orchestration infrastructure in the cloud and providing management interfaces optimized for IT generalists rather than WAN specialists. Configuration templates, automated provisioning, and built-in analytics make these platforms accessible to organizations without deep SD-WAN expertise.
The tradeoff is reduced customization flexibility compared to carrier-grade platforms, and dependence on the vendor's cloud infrastructure for management plane availability. For many small to medium enterprises, this tradeoff is clearly worthwhile — the operational simplicity and reduced expertise requirements outweigh the flexibility limitations.
SASE (Secure Access Service Edge)
SASE architectures integrate SD-WAN connectivity with cloud-delivered security services into a unified platform. Branch traffic is steered to the nearest cloud point of presence, where security inspection occurs before forwarding to the destination. This model provides the best combination of performance optimization and security coverage for cloud-first enterprises.
SASE requires careful planning around traffic steering, identity integration, and the transition from existing security infrastructure. Organizations should expect a 12 to 24-month implementation timeline for a full SASE transformation, though significant value can be realized from early phases of the deployment.
Migration Planning: Making the Transition Without Disruption
Migrating from MPLS to SD-WAN is a significant undertaking that requires careful planning. The following principles guide successful migrations.
Application Mapping First
Before configuring a single SD-WAN policy, map your applications to their performance requirements and current traffic patterns. Which applications are latency-sensitive? Which require guaranteed bandwidth? Which SaaS applications generate the most traffic? This mapping becomes the basis for SD-WAN quality-of-service policies and local breakout decisions. Skipping this step results in SD-WAN configurations that do not reflect actual business priorities.
Parallel Running During Transition
Never cut over from MPLS to SD-WAN in a single step for production sites. Run MPLS and SD-WAN in parallel during the transition period, gradually shifting traffic to the SD-WAN overlay as it is validated. Start with non-critical traffic flows, measure performance against baselines, and progressively migrate more critical applications as confidence builds. Maintain MPLS as a fallback until SD-WAN performance has been validated over a meaningful period.
Site Prioritization
Not all sites carry equal risk. Begin the SD-WAN rollout at sites where a failure is tolerable: development offices, smaller branches with low business criticality, or sites where staff can work productively even if WAN connectivity degrades temporarily. Save the high-stakes sites — primary data center connections, major branch offices, locations supporting time-sensitive business processes — for later in the rollout when the team has operational experience with the platform.
ISP Diversity
SD-WAN's resilience depends on transport diversity. If all WAN links at a site are from the same ISP and terminate in the same exchange, a single ISP outage eliminates all connectivity. Effective SD-WAN deployments use multiple ISPs at each site, ideally with different access technologies and diverse physical routes. In Norway, this might mean a primary fiber connection from one provider combined with a 4G/5G connection from a mobile operator.
Real-World Performance Gains
When SD-WAN deployments are planned and executed well, the performance improvements are substantial and measurable.
Microsoft 365 performance is the most commonly cited improvement. When Microsoft 365 traffic is identified and sent via local breakout directly to Microsoft's network entry points rather than being backhauled through headquarters, latency reductions of 50 to 80 percent are typical. This translates directly to improved responsiveness in SharePoint, faster email sync, and better Teams call quality.
Video conferencing quality improvements are equally dramatic. Jitter and packet loss — the primary enemies of video call quality — are addressed by SD-WAN's dynamic path selection and Quality of Service mechanisms. Organizations transitioning from MPLS to SD-WAN commonly report significant reductions in video call degradation events and user complaints.
Application SLA visibility is a benefit that is less visible to end users but highly valuable to IT operations. SD-WAN platforms provide continuous monitoring of application performance against defined SLAs, giving operations teams real-time visibility into the user experience and proactive alerting when performance degrades below acceptable thresholds — capability that traditional WAN monitoring rarely provided.
Common Pitfalls to Avoid
- Deploying SD-WAN without a security strategy: Local breakout without compensating security controls is not a WAN modernization — it is a security regression. Define your security architecture before you finalize your SD-WAN design.
- Underestimating ISP diversity requirements: Single-ISP SD-WAN provides limited resilience improvement over traditional WAN. Budget for multiple ISPs at critical sites from the start.
- Ignoring the support model: SD-WAN platforms are more complex than traditional routers. Ensure your team has the expertise to operate the platform, or engage a managed service provider who does.
- Skipping the application mapping phase: SD-WAN QoS policies that do not reflect actual application requirements are worse than no QoS — they deprioritize the wrong traffic and create unexpected performance problems.
- Treating SD-WAN as a one-time project: WAN needs evolve continuously. SD-WAN requires ongoing policy management, performance monitoring, and periodic reassessment of traffic patterns and business requirements.
ZeroSubnet Managed SD-WAN: Expert Deployment and Ongoing Operations
ZeroSubnet has designed and deployed SD-WAN solutions for Norwegian enterprises across a range of industries and geographies — from multi-site retail networks to offshore oil and gas facilities to distributed public sector organizations. We understand the specific challenges of Norwegian geography, the regulatory environment, and the ISP landscape in ways that generic global SD-WAN vendors do not.
Our managed SD-WAN service covers the full lifecycle: architecture design that accounts for your specific application portfolio and security requirements, procurement and pre-configuration of hardware, zero-touch site deployment, ongoing 24/7 operations and monitoring, and continuous optimization as your business needs evolve. We integrate SD-WAN deployment with security architecture — ensuring that local breakout is protected by appropriate security controls and that your SD-WAN investment delivers performance improvements without creating new security gaps.
If you are evaluating a move from MPLS to SD-WAN, or if you have already deployed SD-WAN and are not satisfied with the results, contact ZeroSubnet. We offer a no-commitment WAN assessment that evaluates your current architecture, identifies performance and security gaps, and produces a concrete recommendation for improvement. Let us help you get the WAN your business actually needs.