Why the legacy WAN is failing the return to the office

Employees heading back to the office are finding corporate networks noticeably slower than their home broadband. Two forces are at play: legacy line speeds and security architectures that hairpin all traffic through centralized data centers. While 44% of the US now has access to fiber-based Internet at up to 1 Gbps, many MPLS sites still run on 1.5 Mbps circuits. The gap exposes a fundamental mismatch: MPLS-era networks were built for centralized datacenter applications, not today's distributed SaaS and hybrid multi-cloud traffic.

The last decade of enterprise networking has been a story of accumulation rather than redesign. As cloud adoption grew, organizations bolted point solutions onto aging hub-and-spoke WANs, creating what are effectively franken-networks. Bandwidth demand multiplied at branches from business Internet use, data analytics, and security monitoring, straining both the infrastructure and budgets. The result is measurable business loss from project delays and productivity hits caused by outages.

What SD-WAN solves—and what it doesn't

SD-WAN has been the go-to answer for escaping MPLS cost structures. It lets organizations trade private lines for broadband Internet, significantly cutting cost per Mbps. It also adds genuinely useful features: application-aware routing based on path quality, orchestration for faster deployment, and analytics for visibility.

But SD-WAN remains a hardware-dependent edge routing technology that largely ignores the middle mile. Broadband may be fast and widely available, but it lacks the end-to-end security and reliability that mission-critical applications need. And managing security policies across hundreds of edge devices is complex enough that many organizations still choose to backhaul traffic to central data centers—negating much of the benefit. The architecture still lacks what a modern WAN requires: security, speed, and reliability built in from the start.

Magic WAN: network as a service

Cloudflare Magic WAN approaches the problem differently. Instead of a mesh of tunnels between sites, it uses a single Anycast IPSec or GRE tunnel from each site to the Cloudflare network, which acts as the hub. This collapses operational overhead dramatically. Security enforcement points move out of the data center and into the Cloudflare points of presence where WAN traffic enters: firewall-as-a-service for inbound and site-to-site traffic, and a security web gateway for outbound traffic. Policies are defined once and enforced at the data center closest to the user, across 270+ cities.

Because many SaaS destinations are already on Cloudflare's network, traffic can be routed directly to the Internet from the edge—sometimes hitting the destination on the same server. There are no appliances to manage or scale, which means an elastic WAN with no capital investment, expandable or contractible as business needs change.

The Zero Trust destination

For most organizations, the endpoint of this journey is moving from a castle-and-moat model to Zero Trust. In that model, there is no hard boundary between "private" and "public" networks. Instead, security is enforced per user and per application using identity, endpoint health, and location as key attributes. A managed laptop in its home country might get full access; a personal laptop gets limited access to specific applications. If malware is detected on a managed device, its access can be revoked quickly, potentially stopping ransomware from spreading.

This requires a WAN that understands user identity and endpoint health and can make enforcement decisions based on those attributes. It also requires enforcement points that apply consistent policy whether a user is in a branch office or working from home over the Internet. Magic WAN, as part of the Cloudflare One suite, builds this security natively into the network layer.

Planning the transformation

An MPLS-to-Zero Trust migration is a team effort crossing network, security, infrastructure, and application teams. The recommended preparation involves several concrete steps:

  • Network, security, infrastructure, and application teams should jointly document the current and future state, including traffic flows, device types, user profiles, applications, and enforcement technologies.
  • Run a transformation workshop to map all combinations of future traffic flows and use them to establish the future architecture baseline.
  • Invite vendors, partners, and providers to validate the design and assess technology readiness.
  • Conduct budgeting exercises and develop a business plan mapping current pain points to proposed solutions and pricing.
  • Assemble a dedicated project team with project managers, engineering points of contact from each technical group, local site contacts, escalation support, and business stakeholders.

A practical transition plan

A solid transition plan is what separates a smooth migration from one causing outages, business disruption, and budget overruns. The recommended sequence looks like this:

  1. Identify bridging points. Regional and global data centers make ideal bridges between sites already on the new WAN and those still on MPLS.
  2. Create a user acceptance test (UAT). Work with internal teams and site contacts to build it, then run it before and after each site's cutover.
  3. Develop a migration schedule. Sequence site migrations to minimize business impact.
  4. Prepare Magic WAN. Connect applications and branch WAN edge devices (routers, SD-WAN devices, firewalls) to the Cloudflare platform. This step should not affect existing MPLS traffic, but change control guidelines and maintenance windows still apply.
  5. Confirm readiness for cutover. All preparation should be complete before any traffic moves.
  6. Execute the cutover. Production traffic shifts from MPLS to the Cloudflare network. Run the UAT before and after.
  7. Disconnect MPLS circuits. As each site migrates, its legacy circuit can be retired.

Additional considerations:

  • Legacy VPN access can be retired in favor of Cloudflare's Zero Trust Network Access for application connectivity.
  • The customer is responsible for procuring and installing Internet circuits to replace MPLS.

Summary

Replacing MPLS and modernizing network security is a business imperative, not just a technical upgrade. Point solutions and temporary fixes have led to business losses, poor employee experience, and increased risk. The move to Zero Trust is becoming inevitable, but with coordinated teamwork, proper planning, and the right architecture, the transition from MPLS to a Zero Trust WAN is an achievable project—one that can be completed in weeks rather than years.