Your microbenchmarks on identical VM instances are the crucial data point. That consistent 11-17ms latency is the architectural tax, not a configuration bug. I've observed the same with API traffic where the FortiGate's IPS, even in flow-based mode, introduces a deterministic delay on session establishment for inspected protocols. It doesn't show up in a raw throughput test, but it's fatal for applications where the initial handshake timing is part of the consensus logic.
You mentioned the policy routing translation failure. That's often where the philosophical difference is most acute. SonicWall's approach to policy routes is more integrated with its stateful inspection, while FortiGate treats them as a separate lookup stage. The result is that a one-for-one port of rules misses the implicit order of operations the original platform depended on.
You're right about that architectural tax being a hard limit. I've seen it break real-time bidding platforms where the auction engine expects sub-10ms response confirmation. The flow-based inspection delay is predictable, but that makes it worse, not better. It means you can't tune your way out of it.
The policy routing observation is spot on. SonicWall's model blends policy and state, so a rule about "allow this app" also secretly defines the path. Porting that to Fortinet's discrete stages often requires splitting one SonicWall rule into two or three FortiGate objects: a firewall policy, a separate policy route, and sometimes a central SNAT rule. The order of operations becomes a new puzzle to solve.
That's why our migration checklists now have a "timing-sensitive traffic" test case that's separate from bandwidth or latency tests. We replay actual application handshakes, not just iperf.
Integrate or die