We've been doing MPLS-to-SD-WAN migrations on Fortinet for several years. The pattern is repeatable when an ordered sequence is respected and stops being repeatable when steps are skipped. This is the playbook we use today for clients with 50 to 200+ branches.
1. Inventory, not design
Before deciding topology you need a verified inventory: contracted links, actual bandwidth (not billed), measured latency and loss, legacy devices, per-site critical services and acceptable operational windows.
Common mistake: starting to design the solution before knowing what's actually on the ground. The inventory usually takes 2 to 4 weeks if done properly.
2. Application-driven design
SD-WAN is only useful if routing decisions are based on the application, not the subnet. That requires clear classification: which applications are critical, which tolerate latency, which require backhaul for compliance?
On FortiGate this translates to internet-service-id and prioritization
policies. It's documented before touching production.
3. Lab and validation
Every client has their own mix of applications, vendor idiosyncrasies and legacy dependencies. Pre-production lab with mock FortiManager, configuration templates and cutover simulation using a pilot site.
Any change going to production first passes through the lab. If it can't be reproduced, it's not approved.
4. Per-site cutover, no big bang
Migrating 50 sites in one weekend is a bad idea. The cadence that works for us: 2-5 sites per week, with per-site coordinated window and a lab-validated rollback plan.
Pilot sites first (low traffic, tolerant operation), then medium sites, then HQ. If an unforeseen problem appears at any step, the cadence pauses and the issue is diagnosed before continuing.
5. Visibility from day one
FortiManager and FortiAnalyzer at the client from the first cutover. No "we'll see how it behaves once it's in production". If the first migrated site has no continuous visibility, the second one goes in blind.
6. Operational hand-off
The migration doesn't end at the last site. It ends when the operations team (internal or BITS NOC) has per-application runbooks, client contacts, escalation criteria and a month of operation without surprises.
That month is part of the project, not a hidden cost afterwards.
What typically breaks
- Internal DNS with cross-site dependencies.
- Applications that assume MPLS latency and fail at Internet RTT.
- Inherited firewall rules with hard-coded IP addresses.
- Voice applications that require specific QoS not translated to the new design.
Detecting it in lab costs hours; detecting it in production costs days and crisis.
In closing
SD-WAN isn't magic. It's project discipline over a tool that lets you do things MPLS didn't. A well-executed migration improves operations; a rushed migration adds complexity without benefit.