From MPLS to SD-WAN: a checklist for a clean migration

Many MPLS contracts date back to a time when applications ran in the company's own data center and sites mostly needed to talk to each other. Today the bulk of traffic goes to the cloud, and every contract renewal raises the same question: why pay this much for lines that haul traffic halfway across the country to a central breakout?

Moving to SD-WAN answers that question — but only if the migration is planned properly. From our projects, from mid-sized companies to a rollout across more than 250 sites, a sequence has proven itself. Here it is as a checklist.

Sort first: think of sites in T-shirt sizes

The most common planning mistake is treating every site as a special case. Whoever plans 40, 100 or 300 locations individually produces 300 one-off solutions — and manages them that way afterwards.

The better approach: group sites by requirements and slot them into size classes, like T-shirts. An example grid:

• S – small offices, pop-up spaces, construction sites: one internet line plus mobile (5G/LTE), compact hardware, standard bandwidth.
• M – standard offices: two lines from different providers, active redundancy, medium bandwidth class.
• L – headquarters, production, logistics: two separately routed lines plus mobile as a third path, high bandwidth, extended availability requirements.

Where the lines between S, M and L run is specific to each company: user count, critical applications or revenue relevance. What matters is that there are few classes — and every new location is assigned to one of them.

Templates instead of one-off builds

Each size gets exactly one template: hardware model, bandwidth class, redundancy pattern, QoS and security policies, configuration building blocks, documentation. A new site then doesn't mean planning from scratch, but: pick a size, roll out the template.

This standardization pays off several times over. Rollouts get faster because configuration comes from the template rather than manual work. Error rates drop because deviations stand out immediately. Ongoing management becomes predictable because fault patterns repeat across identical sites. And spare-parts stock shrinks to a handful of device types.

There will always be exceptions — a production hall with OT connectivity follows different rules than a sales office. The point is: exceptions are deliberate, documented deviations from the template, not the default.

Connecting lines: redundancy doesn't end at the building entry

Two lines at a site sound like redundancy, but they aren't automatically. If both come from the same provider, they often share equipment, duct routes or building entry — and fail together. That's why redundant sites get lines from different providers.

And even that isn't quite enough. The often overlooked point is peering : even separate providers exchange their traffic at the same internet exchanges. If one provider's peering has a problem there — an outage at the exchange, congested ports, a routing error — the second line only helps if its traffic actually takes different paths: different peering, different upstreams, different AS paths. Two lines whose traffic ultimately crosses the same exchange point are, at this level, a single one.

When selecting providers, it's therefore worth looking beyond price and bandwidth at how the carriers are connected to the internet. With ASKAEMI, our own autonomous system (AS 51834), we see peering issues directly in the routing data — and exactly that knowledge feeds into the line selection per site. Mobile (5G/LTE) completes the picture as a third, technologically separate path that shares neither duct nor exchange with the fixed lines.

Plan security in from the start

With SD-WAN, the internet breakout moves to the sites — traffic no longer runs entirely through the central firewall in the data center. That's intentional (shorter paths, better cloud performance), but it demands a security model that keeps up: SASE/SSE moves inspection and policies into the cloud, close to users and sites. Whoever tackles this only after the migration builds twice.

Migrate in waves, not in a big bang

The rollout starts with a pilot wave of small size-S sites. That's where templates, logistics and cutover processes prove themselves — at manageable risk. The lessons flow back into the template; then the further waves follow by size class.

Per site the rule is: run MPLS and SD-WAN in parallel until the new connection is demonstrably stable, with a defined rollback path. And MPLS notice periods are scheduled backwards from the end, so double payments run no longer than necessary.

After the rollout: manage, measure, optimize

The real work begins with the last migrated site. That includes monitoring per line, maintained templates and above all carrier management: detecting faults, reporting them to the right provider, driving resolution and escalating when things stall. With many sites and several providers each, this effort is easy to underestimate. What this looks like in practice across more than 250 sites: our industrial case study .

The checklist at a glance

1. Inventory sites and slot them into size classes (S/M/L)
2. Define one template per size: hardware, bandwidth, redundancy, policies
3. Clarify applications and dependencies per site class
4. Diversify providers per site — including a look at peering, upstreams and AS paths
5. Plan mobile (5G/LTE) as a third, separate path
6. Settle the SASE/SSE architecture before the migration
7. Run a pilot wave with small sites and sharpen the templates
8. Provide for parallel operation and rollback per site
9. Schedule MPLS notice periods backwards
10. Clarify post-rollout management: monitoring, carrier escalation, template maintenance

Moving from MPLS to SD-WAN is less a technology project than a sequence of standardization decisions. Think in templates and size classes, look all the way down to peering when choosing lines — and you get a network that rolls out faster, fails less often and stays manageable for good.