SD-WAN Migration with Two Data Centers and Six LTE-Only Sites
A 40-site manufacturer in 22 countries has an MPLS contract that expires in nine months. The current hub-and-spoke design backhauls all internet traffic to Frankfurt, so Teams calls from Asian plants show 180–220 ms RTT and jitter complaints. Two data centers, Frankfurt and Singapore, host ERP, which is latency-sensitive and holds about 5,000 concurrent sessions; Microsoft 365 is the main SaaS application. Local internet is available at 24 sites with 100/100 Mbps fiber, at 10 sites with 200/20 Mbps cable/DSL, and at 6 sites with only 4G/5G (20/5 Mbps, behind CGNAT). The security stack (NGFW, IPS, proxy) sits in Frankfurt with 2 Gbps of capacity. Payment card data from EU sites must remain in the EU. The CFO wants WAN spend cut by 30% and will not approve a project that raises the risk of an ERP outage.
1. Propose the target topology and where security inspection sits. Justify with latency and compliance numbers.
Read the worked answer
Topology. Replace the single Frankfurt hub with two regional hubs - Frankfurt and Singapore - and add local internet breakout at every site with usable DIA. The overlay is a partial mesh: each site builds IPsec tunnels to its nearest regional hub plus a direct tunnel to the other hub for ERP. This is not full mesh across 40 sites, which would be 780 tunnels and unmanageable policy; it is mesh only where latency demands it.
Latency arithmetic. An Asian site backhauling to Frankfurt pays 180–220 ms RTT; Teams wants one-way latency under about 150 ms and jitter under 30 ms, so the current design fails by construction. Breaking out to a Singapore PoP should land RTT in the 30–60 ms range for regional SaaS, and ERP to the Singapore data center similarly. European sites keep Frankfurt.
Security. Put inspection at regional SASE PoPs rather than pulling all traffic to Frankfurt. Total DIA across the estate is 24×100 + 10×200 + 6×20 ≈ 4.5 Gbps, more than double the 2 Gbps Frankfurt stack, so central inspection cannot scale even if latency allowed it. Inspect at the PoP nearest the breakout, enforce a single policy set from the orchestrator, and keep EU card-data traffic on EU PoPs only so it never transits Singapore.
Compliance. Classify sites handling card data, pin their breakout and inspection to EU PoPs, and log flows to prove the path. Document this in the DPIA rather than assuming the overlay handles it.
2. What do you do with the six CGNAT 4G/5G sites, and how does that affect the business case?
Read the worked answer
Constraints. Behind CGNAT the sites have no public address, so tunnels must be initiated outbound from the SD-WAN edge with NAT-T; that works, but these sites have 20/5 Mbps shared, variable latency and 5 Mbps of upload - an ERP response of 2 MB takes over 3 seconds on a clean link before any contention. Voice over that link will be marginal at best.
Options.
- Dual-SIM with two providers and forward error correction, which improves loss but not bandwidth.
- Keep these six sites on a small MPLS or carrier Ethernet tail for another contract term, with the SD-WAN edge as the primary for internet/SaaS. This preserves ERP quality and is the lowest-risk answer for a CFO who fears an ERP outage.
- Or accept them on 5G with per-app policy: ERP over the overlay with per-app SLA probes, Teams restricted to audio, and payment traffic not permitted at those sites at all.
Business case impact. Six tails out of 40 is 15% of sites but a small share of circuit spend, so retaining them does not threaten the 30% target - the savings come from removing MPLS at the 34 fiber and cable sites and from consolidating security into SASE. Model the retained tails explicitly so the CFO sees that the savings are not inflated by pretending LTE-only sites are equivalent.
Decision rule. If a site's measured upload cannot sustain the ERP p95 target in a pilot, it does not cut over, regardless of the deadline.
3. Define a migration plan that meets the nine-month deadline while protecting ERP. What are the acceptance and rollback criteria?
Read the worked answer
Plan.
- Months 1–2: pilot three sites, one per access type (fiber, cable, LTE), running SD-WAN in parallel with MPLS. Instrument synthetic ERP transactions against both data centers and Teams call-quality sampling.
- Months 2–5: wave 1, European fiber sites, one site per week, cutover on weekends with the MPLS tail retained as a low-preference path via BGP local preference.
- Months 5–7: wave 2, Americas and Asian fiber sites, then cable sites.
- Months 7–8: LTE sites decided by pilot evidence - cut over or extend the legacy tail.
- Month 9: decommission MPLS at migrated sites, renegotiate or let the contract lapse, and complete the security PoP rollout.
Acceptance criteria per wave. ERP p95 response within 20% of the MPLS baseline, Teams MOS at or above 4.0 for sampled calls, zero P1 incidents attributable to the migration in the 30 days after cutover, and a verified path for EU card data that stays in EU PoPs.
Rollback. Keep the MPLS tail and its BGP session active for 30 days per wave with a documented preference change that restores the old path in under 15 minutes. Pre-stage the rollback commands, not a runbook written after the fact.
Contract actions. Notify the MPLS provider now about the reduced footprint, confirm early-termination terms for individual tails, and secure a six-month extension option on the six LTE sites before the master contract expires.