Immediate Response
A poorly managed SD-WAN migration can cripple an infrastructure. The key lies in meticulous planning, thorough testing of QoS policies, and detailed pre-migration traffic analysis to prevent critical service disruptions like VoIP outages. This ensures business continuity and protects critical communications.
Quick Snippet: FortiGate SD-WAN Troubleshooting Commands
| FortiGate Command | Description |
|—————————————|—————————————————————————–|
| diagnose sys virtual-wan-link health-check | Verifies the status of WAN links and active SD-WAN paths. |
| diagnose sys virtual-wan-link sla-log | Monitors traffic by application and WAN link performance. |
| get firewall shaping-policy | Displays configured Quality of Service (QoS) policies. |
| execute ping-options source | Configures the source interface for test pings, useful for per-interface latency checks. |
| execute ping | Executes a diagnostic ping to a specific gateway. |
Adopting SD-WAN solutions promises agility, cost optimization, and network resilience. For an organization with 40 distributed sites and approximately 800 users, migrating from an expensive MPLS infrastructure to SD-WAN seemed the obvious choice. The MPLS contract was expiring, and the pressure to meet the Q1 deadline was palpable. A reputable vendor presented a ‘turnkey’ solution, guaranteeing a painless transition in just 5 days. The reality, however, proved very different. By the third day of migration, 15 of the migrated sites experienced completely unusable VoIP services, plunging the entire operation into chaos. This is not an isolated incident; according to a 2025 Gartner report, 35% of SD-WAN implementations fail initial SLAs due to inadequate QoS planning.
This incident was an operational lesson in how even the most promising technologies can cause disaster if not managed with due attention to detail and a deep understanding of network dynamics. The experience taught me that blind trust in pre-bundled solutions and the absence of thorough testing can turn a modernization project into a downtime nightmare. In this article, I will share the chronicle of those three chaotic days, the mistakes made, and, most importantly, the lessons learned to ensure a successful and uninterrupted SD-WAN migration.
Prerequisites / Test Environment
The environment in question was a distributed network infrastructure across 40 sites, with an MPLS connectivity being decommissioned and FortiGate introduced as the SD-WAN Edge solution. Each site had a FortiGate appliance, and WAN connectivity relied on FTTC/FTTH lines and, in some cases, 4G/LTE for backup. VoIP traffic was managed by a centralized IP PBX and routed via IPsec VPNs on the FortiGates. There was no dedicated test environment that replicated the complexity of the production network, an error that proved critical.
The Project: 40 Sites, MPLS Decommissioning, Q1 Deadline
The project was ambitious: replace the costly and rigid MPLS infrastructure with a more flexible and performant SD-WAN solution. FortiGate was chosen for its integration with security features. The Q1 deadline for MPLS decommissioning put the team under pressure, leading to an accelerated planning phase. The idea was to migrate sites in blocks, starting with the smallest and least critical, then scaling up. The vendor provided a baseline configuration and assured that the default QoS would be sufficient to manage mixed traffic, including data and VoIP. This assumption, unfortunately, was not validated with thorough tests in an environment that simulated production load.
Day 1: First 8 Sites Migrated. All Good (Too Good)
The first 8 sites, primarily satellite offices with few users, were migrated without apparent issues. Data traffic flowed regularly, web browsing was responsive, and superficial VoIP tests (single test calls) did not detect significant anomalies. This initial success instilled false confidence in the team and management. “It works!” was the mantra. No one thought to granularly monitor VoIP call quality under load or to verify the actual application of QoS policies in real-time. This was the first ignored warning sign: performance problems with latency-sensitive traffic like VoIP often do not emerge under light loads or ideal conditions.
Day 2: Quality of Service Not Delivering as Promised
On the second day, migration continued with medium-sized sites and a larger number of users. This is where the problems began. Reports of VoIP call interruptions and poor quality became insistent. Users reported robotic voices, dropouts, and dropped calls. The IT team started investigating, initially focusing on WAN connectivity: latency, jitter, and packet loss on internet links. Commands like diagnose sys virtual-wan-link health-check showed that the links were active and seemingly stable, with acceptable metrics.
# Verify active SD-WAN path on FortiGate
diagnose sys virtual-wan-link health-checkWe also analyzed traffic by application using diagnose sys virtual-wan-link sla-log, but the data, while indicating a high volume of VoIP traffic, did not highlight a direct cause of the problem at the physical link level. The issue was not available bandwidth, but how it was managed.
The Vendor Call That Solved Nothing
Under pressure, we involved the SD-WAN vendor. Their initial analysis also focused on WAN links and basic configurations, without delving into Quality of Service behavior. They suggested increasing bandwidth, an hypothesis we rejected as initial tests showed ample margins. The call turned into a blame game, with the vendor asserting the correctness of their standard configuration and us lacking concrete evidence to prove otherwise, apart from user complaints. This situation highlighted how crucial it is to have a deep understanding of the technology and configurations to effectively communicate with vendors and avoid accepting generic answers. A 2024 TechTarget report indicates that 60% of network performance issues in multi-vendor environments are attributable to incorrect QoS configurations.
Day 3: Discovering the Problem Was in Our QoS Policy
The breakthrough came on the third day, after a sleepless night of troubleshooting. We began to examine QoS policies in detail, not just at the WAN level, but also firewall and shaping policies. Using the command get firewall shaping-policy, we noticed that the vendor’s default policy, while classifying VoIP traffic, did not assign it a sufficiently high priority, or, worse, was in conflict with other general traffic rules. Specifically, a rule applying a general bandwidth limit for unclassified traffic was implicitly penalizing VoIP when the line was under load.
# QoS policy verification
get firewall shaping-policyWe also used execute ping-options source followed by execute ping to test the specific latency of each WAN interface to the VoIP server, ruling out potential internal bottlenecks. This confirmed that latency was acceptable at the link level, further pointing to traffic management. The problem was subtle: not a complete absence of QoS, but a misconfigured QoS that did not reflect the real priority needs of the organization’s critical traffic.
How We Solved It and What Actually Worked
The resolution involved a complete review of QoS policies across all FortiGates. We created specific and much more aggressive rules for VoIP traffic (SIP ports, RTP, etc.), ensuring maximum priority and reserving guaranteed minimum bandwidth, regardless of the overall line load. Additionally, we implemented a more granular monitoring system for VoIP traffic, using integrated FortiGate tools and a SIEM to correlate call quality events with network data. This allowed real-time visualization of the impact of changes.
The real solution was an iterative approach: modify a policy, monitor the impact, and adjust again. We also leveraged SD-WAN’s Path Selection features to dynamically route VoIP traffic over the link with the lowest latency and jitter, even if it wasn’t the default primary link. This required a deep understanding of how FortiGates interpret and apply SLA metrics for path selection. Read also: SSH Hardening Linux: Complete Guide 2026 (10 Critical Settings)
Common Errors and Troubleshooting
- Blind trust in default configurations: Out-of-the-box configurations are rarely optimal for complex environments. Customization is crucial.
- Lack of baseline: We lacked a detailed baseline of VoIP quality on MPLS. This made it difficult to quantify degradation and demonstrate the problem to the vendor.
- Insufficient testing: Initial tests were too superficial and did not simulate real load conditions. VoIP, in particular, requires stress testing.
- Troubleshooting approach: Focusing only on WAN links and not on internal traffic management policies is a common mistake.
FAQ — Frequently Asked Questions
What is Quality of Service (QoS) in an SD-WAN context?
QoS is a set of techniques and protocols that allow network traffic to be managed to ensure a specific service level for certain applications or data types. In SD-WAN, QoS is fundamental to ensure that critical traffic, such as VoIP or video, receives the necessary priority even in congested conditions, avoiding excessive latency and jitter.
How can I test QoS for VoIP before an SD-WAN migration?
To test QoS for VoIP, it is essential to simulate production load. Use VoIP traffic generation tools (e.g., SIPp, Iperf) to saturate links and monitor metrics such as latency, jitter, and packet loss. It is crucial to establish a performance baseline before migration for a comparative reference.
What is the difference between SD-WAN and MPLS for sensitive traffic management?
MPLS offers a private network service with guaranteed SLAs on latency and bandwidth, but it is rigid and expensive. SD-WAN aggregates multiple low-cost internet connections, using optimization techniques and intelligent routing (based on policies and real-time SLA monitoring) to ensure MPLS-like performance, with greater flexibility and lower costs, but requires more careful QoS configuration. For more details, consult the official Fortinet SD-WAN documentation: [https://docs.fortinet.com/document/fortigate/7.4.0/sd-wan-release-notes/33580/what-s-new-in-fortios-7-4-0-sd-wan]
What are the 5 things to do BEFORE migrating to SD-WAN?
- Detailed traffic analysis: Understand every traffic type, its bandwidth, and latency requirements.
- Performance baseline: Measure current performance (MPLS) to have a reference.
- Custom QoS design: Do not rely on default configurations; design policies based on your critical applications.
- Load testing: Perform thorough tests in a pre-production environment or on a subset of sites.
- Rollback plan: Prepare a detailed plan to revert to the old configuration in case of critical issues.
Conclusions with Operational Takeaways
The SD-WAN migration incident, though painful, was a catalyst for learning. The biggest lesson is that technology, however advanced, is just a tool. Its success depends on planning, deep knowledge of your environment, and the ability to question assumptions, even those provided by vendors. Never underestimate the importance of well-configured and tested QoS, especially for critical traffic like VoIP. Proactive monitoring and the ability to analyze data in real-time are the only true allies against production chaos. 73% of post-migration network outages are preventable with adequate testing (IDC 2025).
Updated: June 2026
