How to Do an SD-WAN Migration From Any Starting Point

SD-WAN migration typically involves 8 steps:

It's a phased process that includes planning, preparation, execution, and post-cutover optimization.

Step 1. Assess your current network needs

Before diving into SD-WAN, take a clear-eyed look at how your network works today.

This isn't just about your connections. It's about understanding what your network actually supports and where the complexity lives.

Start with your footprint:

• Inventory all your locations and how they connect: MPLS, broadband, LTE, or otherwise.
• Map out your topology, routing protocols, and any site-to-site or cloud dependencies.
• Note any legacy appliances or services that might need to be replaced, integrated, or retired.

Then look at what your network supports:

• What applications do people use every day and where do they live (cloud, data center, hybrid)?
• How does traffic move between users, apps, and services?
• What invisible dependencies (like DNS, DHCP, firewalls, or CASBs) could break things if not accounted for?

And finally, check your scale:

• Where is bandwidth tight?
• What sites are growing fast?
• Are there places where usage patterns don't match the original design?

This step isn't just technical. It's foundational.

A strong assessment keeps your SD-WAN rollout grounded in reality, not just architecture diagrams.

Step 2. Establish a performance baseline

Before you change anything, you need a clear sense of how things are working now—both technically and from the user's perspective.

Start with the numbers:

• Measure latency, jitter, packet loss, and throughput across different sites and link types.
• Track how traffic flows to cloud apps, internal tools, and data centers.
• Get a snapshot of peak usage times and any bandwidth bottlenecks.

But don't stop there. The user experience tells its own story:

• Which apps feel slow, glitchy, or unreliable?
• Which sites get the most complaints?
• Are certain workflows more painful than they should be?

This baseline gives you something to measure against post-migration and helps set expectations internally.

It also flags performance issues that SD-WAN might fix…or reveal more clearly once you've got better visibility.

Step 3. Define your SD-WAN architecture and migration strategy

Now it's time to sketch out what your SD-WAN will look like and how you're going to get there.

Start with how you'll manage it:

• Will your team build and run everything in-house (DIY)?
• Will you share control with a partner (co-managed)?
• Or will you hand it off entirely (fully managed)?

That decision affects how much control you have, what visibility tools you get, and how support works during and after the rollout.

Next, design your SD-WAN architecture:

• Define the underlay (physical links) and overlay (virtual paths between locations).
• Plan where internet breakouts will happen and what policies control them.
• Consider how you'll integrate with security tools like firewalls, proxies, and CASBs.

Then, choose a migration strategy:

• Phased: migrate a few sites at a time and gradually scale.
• Augmentation: bring in SD-WAN to run alongside your current setup for a while.
• Rip-and-replace: go all in and switch everything at once.

• What Is an SD-WAN Appliance? | SD-WAN Hardware & Equipment
• Types of SD-WAN Deployment Models: A Complete Guide
• How much does SD-WAN cost?

Step 4. Create a detailed migration plan

Now that your architecture's nailed down, it's time to map out how you'll actually pull this off. One site, one connection, one policy at a time.

Start by prioritizing your sites.

Most teams start small—think low-risk branches—so they can test the waters before cutting over critical hubs or high-traffic data centers.

You might also group migrations by region, business unit, or which sites share upstream dependencies.

Next, figure out how your legacy and SD-WAN environments will coexist during the rollout.

That might mean temporarily routing traffic between old and new paths, standing up transitional BGP configs, or keeping backup MPLS circuits in place.

Make sure you've thought through DNS, NAT, DHCP, and any edge cases that could break routing or service discovery during the cutover.

Finally, get your team aligned.

Define who's doing what and when, including third-party providers if you've got them.

Build rollback procedures in case something goes sideways, and prep configuration templates ahead of time to streamline site-to-site consistency.

This plan becomes your migration playbook. The more you lock down now, the fewer surprises you'll run into when it's go time.

Step 5. Onboard and configure SD-WAN components

This is where your migration moves from planning to hands-on setup.

Start by pre-staging your gear.

Make sure SD-WAN appliances are physically racked (if needed), powered, and assigned IPs.

If you're using cloud-managed devices, confirm they're registered and ready for zero-touch provisioning. Getting this squared away early helps avoid delays once migration begins.

Then test your circuits.

Validate that all WAN links—whether broadband, LTE, or otherwise—are delivering the performance you expect. Latency, jitter, and packet loss should be within acceptable thresholds, especially for real-time traffic like voice or video.

Now move into configuration.

Set up routing and traffic steering, define QoS policies, and apply security settings like firewall rules. This is where your design decisions take shape — how traffic flows, what gets prioritized, and how enforcement works across locations.

Don't forget the background essentials.

Systems like DNS, NTP, logging, and monitoring need to be online and integrated. These may not be flashy, but they're critical for visibility and troubleshooting once you're live.

This step lays the groundwork for a smooth cutover with as few surprises as possible.

Step 6. Execute site migration and cutover

This is where the migration goes live.

The goal is to transition each site to SD-WAN without disrupting access to critical applications or services.

Start by executing your cutover plan.

That includes coordinating timing with all stakeholders, verifying that SD-WAN components are staged and configured, and confirming that fallback options are in place if something doesn't go as expected.

When it's time to flip the switch, move the site's traffic to the new SD-WAN path.

Validate that tunnels form, routing behaves as expected, and that traffic is steering correctly. Common issues—like DHCP conflicts, DNS failures, or misapplied policies—are easier to catch if you test early and often.

Once a site is live, confirm users can reach what they need.

Monitor link health, application responsiveness, and policy enforcement. If anything looks off, troubleshoot on the spot before moving on to the next location.

If a site runs into persistent issues, fall back to your rollback plan.

That could mean reverting to the old path, reapplying configurations, or staging a second cutover attempt. The important part is not to push forward until you're confident the environment is stable.

Step 7. Perform post-migration validation and tuning

Once the SD-WAN migration is complete, the first thing to do is validate the network from the end user's point of view.

Start by confirming basic services—like DHCP and DNS—are working as expected.

If users can't get an IP address or resolve domain names, applications won't function. So keep an eye on these services even after initial tests.

DNS issues, for example, can show up later when devices try to renew leases or connect to less commonly used domains.

Next, move up the stack.

Check access to internal applications first, then validate external SaaS apps. If local breakout is enabled, verify that the new source IP addresses are whitelisted on the SaaS platforms.

And don't rely only on real-time dashboards. Compare current performance metrics—like latency, packet loss, and link stability—against your pre-migration baseline.

This will help you confirm whether the migration actually improved performance or introduced new issues.

Now it's time to tune.

Use SD-WAN analytics to look for abnormal behaviors or trends.

Use this insight to refine QoS, adjust traffic steering rules, and confirm your policies are being applied as intended.

If some paths are underperforming, you may need to tweak routing priorities or work with your underlay providers to resolve issues.

Finally, treat this as an ongoing process.

Post-migration isn't a one-time event. It's the beginning of continuous optimization.

Keep monitoring user experience, underlay health, and application behavior over time. That's how you maintain performance, reduce support tickets, and get the most out of your SD-WAN investment.

Step 8. Continuously monitor and optimize

Once migration is done, the focus shifts to keeping performance steady and improving it over time.

This isn't just about watching dashboards. It's about making sure your SD-WAN actually holds up in real-world use, across every location and link type.

Start with consistent visibility.

You need ongoing insight into underlay and overlay health, including latency, jitter, loss, and path changes across internet and private circuits.

If something degrades, you should be able to tell where and why. That includes DNS resolution, proxy behavior, BGP changes, and CASB performance, depending on your architecture.

Then use that data to refine how the network behaves.

If traffic isn't hitting the right QoS or steering policies, fix it.

If queues are overloaded or low-priority traffic is using premium paths, reallocate bandwidth or adjust shaping rules.

Optimization isn't just about performance. It's also about resource alignment.

Important: Remember optimization isn't a one-time exercise.

As usage shifts, providers change behavior, and new apps are introduced, the network will need to adapt.

Keep tracking performance against your original baseline. And if users start reporting issues, that's a signal to recheck assumptions, not just troubleshoot symptoms.

How does SD-WAN migration differ based on your starting point?

The core migration process stays the same no matter where you're coming from.

But your starting point still shapes how that process plays out. Especially when it comes to architecture, coexistence, and rollback planning.

Here's how to adapt your approach depending on what kind of environment you're migrating from.

MPLS-based WANs

If your network relies on MPLS, SD-WAN changes the architecture entirely. You're moving from provider-managed, circuit-bound routing to dynamic, overlay-based control.

Expect to run MPLS and SD-WAN side-by-side during the transition, especially for high-priority sites.

Plan for hybrid routing, QoS mapping, and local internet breakout. All while maintaining application availability.

This type of migration benefits most from clear rollback plans and precise traffic steering policies during rollout.

Site-to-site VPNs over the public internet

If your WAN is built on manually configured VPN tunnels—often using IPsec, DMVPN, or GRE —SD-WAN simplifies and centralizes what used to be brittle and error-prone.

Migration here is less about replacing circuits and more about replacing static configs with dynamic, policy-based control.

Be ready to retire tunnel meshes, simplify NAT rules, and untangle hardcoded dependencies that built up over time.

Broadband-only router deployments

If you're already using DIA or broadband at remote sites, the circuits may stay the same. But SD-WAN brings smarter routing, visibility, and security.

These deployments often lack centralized control, consistent enforcement, or resilience across link types. So migration focuses on validating link quality, optimizing application steering, and replacing basic routing with performance-aware decisions.

Expect to tune for jitter, packet loss, and variability between consumer and business-grade connections.

Cloud-native or greenfield environments

Greenfield and cloud-first deployments offer a clean slate. But they also carry more risk if things go wrong.

With no legacy equipment or configurations to fall back on, success depends on getting architecture, policies, and connectivity right the first time.

Focus on defining breakout points, identity enforcement, and observability from day one.

Hybrid WANs (MPLS + broadband or LTE)

In hybrid WAN environments, you're already juggling multiple transport types. SD-WAN helps unify that experience, but migration still requires careful coordination.

Expect to phase in new overlays while keeping legacy routing in place for a time.

Your focus here is on harmonizing traffic across dissimilar links, validating failover behaviors, and confirming that policies apply consistently regardless of underlay.

Be especially watchful for asymmetric routing or traffic blackholing during partial cutovers.

Legacy WAN optimization appliances

If your WAN includes optimization tools (pre-SD-WAN), your architecture may already use overlay tunnels and app-based prioritization.

But migrating to SD-WAN means replacing those features with integrated platform controls and eliminating the complexity of point solutions.

You'll need to unwind custom acceleration paths, confirm that new QoS settings provide equivalent performance, and validate that critical apps still meet SLAs after optimization is removed.

SD-WAN migration FAQs