SD-WAN Migration Plan: Moving from MPLS Without Disruption
Saudi multi-site enterprises with established MPLS networks face a recurring decision: migrate to SD-WAN. The cost savings are substantial. The capability gains are meaningful. The migration risk is the obstacle. Done badly, an SD-WAN migration takes branches offline, breaks WAN-dependent applications, and creates operational chaos. Done well, it transitions seamlessly with minimal user-visible disruption. This piece walks through the migration plan that works.
The parallel-running approach
The fundamental migration principle: run MPLS and SD-WAN in parallel, then transition site-by-site. Never cut over the entire network in one event.
The pattern: install SD-WAN edge devices alongside existing MPLS routers. Route new SD-WAN traffic via internet circuits while MPLS continues handling existing traffic. Validate SD-WAN performance per site. Cutover sites individually once each is verified. After all sites migrated, decommission MPLS.
This approach: keeps MPLS as fallback during transition, allows per-site validation, contains risk to one site at a time, supports rollback if specific sites have issues.
The 12-week typical project timeline
Weeks 1-2 — Discovery and design. Inventory current network architecture, document application flows, identify per-site bandwidth requirements, choose SD-WAN platform, design target architecture.
Weeks 3-4 — SD-WAN platform deployment. Install SD-WAN orchestrator, configure central policy. Pre-stage edge devices for first sites.
Weeks 5-6 — Pilot sites (2-3 sites). Install edge devices at pilot sites. Configure them to route new application flows via SD-WAN while keeping MPLS active. Validate performance for 1-2 weeks.
Weeks 7-10 — Phased rollout. Wave-based migration. Each wave covers 5-15 sites depending on enterprise size. Each wave: install edge devices, route traffic, validate, decommission MPLS at site.
Weeks 11-12 — Cleanup and optimisation. Decommission centralised MPLS infrastructure, optimise SD-WAN policy based on real usage patterns, train operations team, transition to managed support.
Site-by-site cutover sequence
The sequence within a wave matters:
Pilot sites first. Choose 2-3 representative sites for pilot — varied geography, varied size, varied applications. These uncover configuration issues at low risk.
Less critical sites next. After pilot success, migrate sites where downtime is tolerable: branch offices, secondary locations.
Core sites last. HQ, primary data centre, customer-facing operations migrate after the SD-WAN is proven at scale.
Customer-impacting sites with extra care. Retail stores, hospitality properties, anywhere where downtime affects customers — schedule cutover during low-traffic windows with rollback plans ready.
Application-aware routing during transition
During the parallel-running window, SD-WAN can be configured to route specific applications via internet (SD-WAN) while keeping others on MPLS. Common pattern:
- Microsoft 365, Office 365, web traffic → internet via SD-WAN
- Internal application traffic, ERP, file shares → MPLS until cutover
- Voice (VoIP) → MPLS until SD-WAN proven for voice quality
This approach validates SD-WAN gradually rather than all-at-once.
Rollback plans
Every site cutover needs a rollback plan. The pattern: SD-WAN edge device installed alongside MPLS router; if SD-WAN cutover fails, revert to MPLS routing within 30 minutes by reconfiguring at the site or via central orchestrator. MPLS circuit not decommissioned until SD-WAN proven stable for 30+ days.
Internal team training
SD-WAN operates differently from traditional MPLS. Operations teams need training on: orchestrator UI and policy management, application-aware routing concepts, troubleshooting flows (different from MPLS), monitoring dashboards.
Budget 2-5 days of training per network engineer. Without training, the team operates SD-WAN as if it were MPLS — losing most of the platform’s value.
Operational handover
Post-migration, the operations model changes. SD-WAN can be self-operated (your team manages everything) or managed-service (vendor or partner manages the platform). Most Saudi enterprises start with managed service for the first 12-18 months while building internal expertise, then transition to self-operation if they want.
Common gotchas
Several patterns that trip up SD-WAN migrations:
Application performance differs from MPLS. Some applications that worked well on predictable MPLS struggle with internet variability. Application-specific tuning required.
Internet circuits insufficient. Sites that ran on 50 Mbps MPLS often need more internet bandwidth than expected because internet traffic is less efficient than MPLS-routed traffic. Plan for 1.5-2x the MPLS bandwidth in internet capacity.
Voice quality issues. Voice over SD-WAN-routed internet typically works but requires specific QoS configuration. Don’t assume; test.
VPN concentrator changes. Mobile users and remote workers may need configuration updates if their VPN endpoints change.
Carrier handoff coordination. Decommissioning MPLS requires coordination with carriers. STC, Mobily, and Salam contracts may have minimum-term clauses; verify exit terms before committing to migration timeline.
Get help with SD-WAN migration
For a written SD-WAN migration plan with risk mitigation and timeline specific to your environment, contact our team. Pair with networking services, cyber security, and IT consulting.