Migrating from MPLS to SD-WAN should rarely be treated as a simple router replacement. A successful SD-WAN migration checklist needs to cover the existing WAN, application dependencies, underlay connectivity, security, operational readiness, pilot testing, cutover, rollback and post-migration validation.
For many enterprises, the safest journey is not MPLS to internet overnight. It is a controlled transition from an existing private WAN toward a hybrid WAN in which MPLS, internet, broadband, fiber or cellular transports can coexist beneath an SD-WAN overlay. MPLS can then be retained, reduced or retired selectively once application performance and resilience have been proven.
This SD-WAN migration checklist provides a practical framework for planning that migration from assessment through stabilization.
If you need the architectural foundations first, start with our complete guide to SD-WAN architecture, underlays and overlays. For vendor-neutral industry context, see the Mplify Alliance MEF 70.2 SD-WAN service framework.
SD-WAN Migration Checklist at a Glance
An enterprise SD-WAN migration can be organized into nine major phases.
| Phase | Primary Objective | Key Output |
|---|---|---|
| 1. Assess | Understand the existing WAN | Complete network and dependency inventory |
| 2. Baseline | Measure the current service | Performance baseline and success criteria |
| 3. Design | Define the future architecture | Target hybrid WAN and SD-WAN design |
| 4. Security | Secure the target WAN design | Internet breakout and security architecture |
| 5. Prepare | Make the migration executable | Runbook, governance and rollback plan |
| 6. Pilot | Validate assumptions | Approved pilot and lessons learned |
| 7. Waves | Move sites in controlled migration waves | Sequenced production deployment plan |
| 8. Cutover | Execute the migration safely | Controlled production cutover and rollback readiness |
| 9. Validate | Confirm service quality and stabilize the site | Post-cutover acceptance and operational handover |
The important principle is that migration is a lifecycle. A branch should not be considered successfully migrated simply because an SD-WAN edge has established its control connections.
Phase 1: Assess Your Existing MPLS WAN
A migration plan is only as reliable as the information it is built on. Brownfield enterprise WANs often contain years of design choices, exceptions, temporary routes, local internet connections, firewall rules and application dependencies that are not fully reflected in the latest architecture document.
Build the Site and Circuit Inventory
Start with a complete inventory of locations and WAN services. For every site, capture site type and business criticality, existing MPLS circuits, DIA or broadband services, fiber or wireless connectivity, 4G/5G backup, bandwidth, carrier, contract dates, service levels, WAN-edge hardware and local security architecture.
Contract dates matter operationally. A technically sound migration that ignores carrier commitments can create unnecessary parallel costs or force a rushed circuit termination.
Map Routing and Network Dependencies
Document BGP, OSPF or static routing, route redistribution, IP addressing, NAT, DNS and DHCP dependencies, VRFs, QoS, firewall zones, data-center gateways, cloud connectivity, monitoring, logging and telemetry.
This becomes especially important when legacy WAN and SD-WAN domains need to interoperate during migration. Cisco’s SD-WAN migration guidance likewise separates preparation, migration workflow and interworking with external or legacy domains. See the Cisco SD-WAN Migration Guide.
Identify Critical Applications and Traffic Flows
A site inventory alone is not enough. SD-WAN policies are application-aware, so the migration team must understand what the network carries.
A useful mapping is Application → users/sites → destination → traffic path → performance requirement → security requirement → business criticality.
Focus on important services such as voice and video, ERP, CRM, SaaS, public-cloud workloads, private data-center applications, remote desktop and transactional systems.
Phase 2: Establish the Performance Baseline
Before changing the WAN, establish how the current network performs. Otherwise, teams may attribute every post-migration issue to SD-WAN even when the problem already existed.
What Should You Measure?
Useful measures include latency, jitter, packet loss, bandwidth utilization, application response, circuit availability, historical incidents, failover behavior and cloud or SaaS performance.
Define Migration Success Criteria
Separate technical acceptance from business acceptance. Technical criteria can include overlay connectivity, expected routes, segmentation, traffic steering, failover and telemetry. Business criteria can include critical-application availability, voice quality, local-user confirmation and operational support readiness.
Phase 3: Design the Target Hybrid WAN
Once the current state is understood, define the target architecture. Avoid assuming every site needs the same combination of transports.
Choose the Right Underlays by Site Type
Possible designs include MPLS + DIA, MPLS + broadband, dual internet, internet + 5G, dual internet + cellular backup, or MPLS + internet + cellular. The correct design depends on application requirements, site criticality, carrier availability, resilience and economics.
Define the SD-WAN Overlay
The target architecture should define WAN-edge roles, controller or management architecture, segmentation, routing exchange with legacy domains, cloud and data-center connectivity, application policy, resilience and monitoring. For more detail, see our SD-WAN architecture guide.
Define Application Traffic Policies
Do not simply configure “MPLS preferred” or “internet preferred” globally. Match application classes with preferred paths, backup paths and measurable decision criteria such as latency, jitter, packet loss or reachability.
Decide Where MPLS Should Remain
SD-WAN does not require an organization to eliminate MPLS. MPLS may remain useful for highly critical sites, locations with weak internet alternatives, specific latency-sensitive services, regulatory constraints or transitional coexistence.
For the wider strategic question, see where MPLS still provides business value.
Phase 4: Design Security Before Enabling Internet Breakout
SD-WAN migration can change the security architecture significantly, particularly when traffic that was previously backhauled through a data center begins reaching SaaS or cloud services directly from branches.
Identify What Changes
Review internet egress points, firewall enforcement, web filtering, DNS security, malware protection, remote access, segmentation, identity-aware policy, logging and incident response.
Do Not Equate Private Connectivity with Security
Private WAN connectivity and cybersecurity solve different problems. During modernization, security policy should follow the user, device, application and resource requirements rather than relying only on physical network location. This is consistent with NIST SP 800-207 Zero Trust Architecture.
Determine Whether SASE Fits the Target Architecture
Organizations increasing direct internet access, SaaS use and distributed security enforcement may use the SD-WAN migration as a point to evaluate SASE. SD-WAN and SASE are not synonyms: SD-WAN focuses on WAN connectivity and traffic steering, while SASE combines networking with cloud-delivered security capabilities.
See our complete SASE guide for the security architecture.
Phase 5: Prepare the SD-WAN Migration Plan
Define Roles and Responsibilities
A typical migration involves network architecture, operations, security, cloud teams, application owners, site representatives, service providers and project/change management. Our RACI Matrix Examples guide includes an SD-WAN migration scenario that can help structure ownership.
Build the Migration Runbook
The runbook should define pre-checks, configuration preparation, underlay validation, overlay activation, routing changes, security changes, application tests, failover tests, business validation, monitoring and rollback.
Define Go/No-Go Criteria
A change window should not begin merely because it appears in the project schedule. Confirm circuits, hardware, configuration, security approval, application-owner readiness, monitoring, dependencies and rollback capability.
Define the Rollback Plan Before Cutover
Rollback is not an emergency idea to invent after the migration fails. Define trigger conditions, authorization, configuration restoration, routing restoration, security reversal, service validation and incident documentation before the change begins.
Define Communications and Escalation
Identify the migration lead, technical authority, business contact, provider escalation, security escalation, go/no-go authority and rollback authority.
Phase 6: Run an SD-WAN Pilot
A pilot should validate architecture assumptions before scaling deployment.
How to Select Pilot Sites
Select a representative mix rather than only the easiest branch: a standard office, a site using real-time applications, a cloud-heavy site, a location with different carrier connectivity and a site exercising important segmentation or security requirements.
What Must the Pilot Test?
Test underlay connectivity, SD-WAN control and overlay establishment, routing, segmentation, application identification, path selection, QoS, cloud access, internet breakout, security, failover, logging and operational procedures.
Define Pilot Exit Criteria
The pilot should close only when critical defects are resolved, required performance is demonstrated, failover behaves as expected, security validation is complete, operations can support the environment and the runbook reflects lessons learned.
Phase 7: Plan Migration Waves
After the pilot, organize sites into controlled waves: Wave 0 pilot, Wave 1 low-risk sites, Wave 2 standard production sites, Wave 3 complex sites and Wave 4 critical or exceptional environments.
Track carrier delivery, hardware availability, licensing, site access, configuration readiness, firewall changes, cloud routing, maintenance windows and application-owner availability.
Phase 8: SD-WAN Migration Checklist for Cutover
Pre-Cutover Checklist
- Site and business owner confirmed
- Change window approved
- Underlay circuits operational
- WAN edge ready
- Configuration reviewed
- Routing design verified
- Security rules ready
- Monitoring prepared
- Baseline captured
- Application test list available
- Support contacts available
- Rollback procedure verified
Cutover Checklist
- Confirm final go decision
- Record starting state
- Activate the new WAN edge
- Verify underlay reachability
- Verify SD-WAN control connections
- Confirm overlay routes
- Apply routing transition
- Activate application and security policies
- Validate expected traffic paths
- Monitor alarms and logs
Immediate Validation Checklist
- LAN and WAN reachability
- DNS resolution
- Critical internal applications
- SaaS and cloud applications
- Voice and video
- Internet access
- Security policy
- Segmentation
- Monitoring
- Primary and backup path behavior
Define Rollback Triggers
Examples include critical application failure, routing instability, missing security controls, loss of segmentation, persistent severe performance degradation, loss of management visibility or insufficient time remaining in the approved change window.
Phase 9: SD-WAN Migration Checklist for Post-Cutover Validation
Immediate tests prove the site is functioning. Post-migration validation proves it can remain in production.
Validate Routing and Reachability
Review expected prefixes, route preference, redistribution, default routing, legacy-domain interoperability and cloud/data-center reachability.
Validate Critical Applications
Application owners or representative users should confirm the services that matter most to the site.
Validate Application Steering and QoS
Confirm not only that traffic flows, but that it uses the expected paths and classifications.
Validate Resilience
Where permitted, test primary transport loss, secondary path use and recovery to the preferred path.
Validate Security and Logging
Verify policy enforcement, security telemetry and the visibility required by operations and security teams.
Confirm Operational Ownership
A project should not hand a new SD-WAN site to operations without monitoring, runbooks, escalation procedures, known-issue documentation, access and support-provider information.
When Should You Retire MPLS?
Do not terminate an MPLS circuit immediately just because the SD-WAN cutover succeeded. A period of coexistence can provide confidence and fallback while the new environment stabilizes.
Reasons to Retain MPLS
Retain MPLS where internet alternatives are weak, the site is highly critical, specific applications still benefit from the private underlay, termination produces little immediate saving or the site remains in stabilization.
Conditions for MPLS Retirement
Consider retirement when the SD-WAN site is stable, application performance is validated over time, failover is proven, operations can support the site, security is stable, alternative underlays provide sufficient diversity and commercial termination conditions are understood.
The objective is not “remove MPLS.” It is a WAN architecture in which every transport has a justified role.
Illustrative Enterprise SD-WAN Migration Scenario
Consider a fictional enterprise with headquarters, two data centers and 80 branch offices. The existing WAN uses MPLS at all locations and centralized internet breakout. SaaS adoption has increased, and many branches now send cloud traffic across MPLS only to reach a central internet gateway.
The target architecture uses MPLS + DIA for major sites, dual internet for standard branches, internet + cellular backup for small sites, an SD-WAN overlay across all locations and local secure internet breakout for approved cloud applications.
Rather than cancelling MPLS immediately, the organization baselines the WAN, pilots representative sites, runs MPLS and new underlays in parallel, validates application-aware routing and failover, migrates low-risk branches first, moves complex hubs later and retires selected MPLS circuits only after acceptance criteria are met.
Assess → coexist → pilot → migrate → validate → optimize.
Common SD-WAN Migration Risks
| Risk | Potential Impact | Mitigation |
|---|---|---|
| Missing application dependency | Application outage | Map critical flows before migration |
| Poor internet underlay | Degraded user experience | Baseline and qualify connectivity |
| Routing asymmetry or redistribution error | Intermittent connectivity | Validate routing during pilot and cutover |
| Incorrect QoS mapping | Voice/video degradation | Test classification and policy |
| Security added too late | Exposure or blocked traffic | Design security before breakout |
| No clear rollback | Extended outage | Prepare rollback before change |
| Premature MPLS cancellation | Loss of fallback | Use a defined stabilization period |
| Pilot not representative | Problems discovered at scale | Select multiple site profiles |
| Operations not ready | Slow incident resolution | Complete operational handover |
SD-WAN Migration Readiness: Go, Conditional Go or No-Go?
Assess readiness across architecture, connectivity, applications, routing, security, pilot results, rollback and operations.
GO: Critical prerequisites are complete and residual risks are accepted.
CONDITIONAL GO: Minor gaps remain, but they have explicit owners, mitigations and acceptance.
NO-GO: A critical dependency, security requirement, rollback capability or service prerequisite remains unresolved.
Frequently Asked Questions
How do you migrate from MPLS to SD-WAN?
Assess the existing WAN and applications, establish a performance baseline, design the target hybrid WAN, prepare security and rollback, run a representative pilot, migrate sites in waves, validate service quality and retire MPLS only where the new architecture has proven stable.
Does SD-WAN completely replace MPLS?
No. SD-WAN is an overlay and can use MPLS, internet, broadband, cellular and other transports as underlays.
Should MPLS and SD-WAN run in parallel during migration?
In many brownfield migrations, a period of coexistence reduces risk because legacy connectivity remains available while SD-WAN policies, applications and failover are validated.
What should an SD-WAN migration checklist include?
At minimum: WAN inventory, application dependencies, performance baseline, target architecture, security, underlay readiness, pilot plan, migration runbook, go/no-go criteria, rollback, application validation, resilience testing, monitoring and operational handover.
How should SD-WAN pilot sites be selected?
Select representative sites rather than only the easiest locations. The pilot should exercise important combinations of applications, connectivity, security, routing and site complexity.
When should an SD-WAN migration be rolled back?
Rollback criteria should be defined before the change. Typical reasons include critical application failure, serious routing instability, loss of required security or segmentation, severe sustained degradation or insufficient time to safely complete the change window.
When can MPLS circuits be disconnected?
After the SD-WAN site has completed stabilization, critical applications and failover have been validated, monitoring and operations are ready, and commercial termination conditions are understood.
Should enterprises use managed or self-managed SD-WAN?
That depends on internal skills, desired control, operational capacity, geographic scope and provider requirements. See our SD-WAN vs Managed SD-WAN guide.
Conclusion: Migrate the WAN, Not Just the Routers
A strong SD-WAN migration checklist is not defined by how quickly an organization can replace branch routers. It is defined by how safely the enterprise can move applications and users toward a more flexible WAN architecture while maintaining connectivity, performance, security and operational control.
Understand the current WAN → baseline applications → design the hybrid architecture → secure it → pilot it → migrate in waves → validate it → optimize the remaining transports.
For some organizations, that journey eventually removes most MPLS circuits. For others, MPLS remains one of several useful underlays. The architecture should determine the transport strategy, not the assumption that one technology must completely replace another.
Continue Learning
Explore these related TechTeamSynergy guides to continue building your enterprise WAN strategy.
What Is SD-WAN? Complete Guide
Understand SD-WAN architecture, underlays, overlays, application-aware routing and how modern software-defined WANs work.
SD-WAN vs Traditional WAN
Compare traditional WAN and SD-WAN architectures, benefits, limitations and enterprise decision criteria.
Is MPLS Dead?
Explore where MPLS still fits, where internet-based WANs can replace it and why hybrid architectures remain relevant.
What Is SASE?
Learn how networking and cloud-delivered security converge as enterprises modernize branch, cloud and remote access.