Palo Alto → FortiGate: The Honest Engineering Guide

Palo Alto Networks built one of the cleanest enterprise firewall platforms of the last decade. App-ID, User-ID, GlobalProtect and Panorama are all genuinely well-designed primitives. The decision to migrate to FortiGate is rarely about quality. It is about subscription pricing, the talent pipeline, the gap between Cortex Data Lake retention costs and FortiAnalyzer's, and the operational reality that almost every Indian enterprise running PAN already runs FortiGate or FortiAnalyzer somewhere else in the estate.

This is the guide we wish existed when we did our first PAN-OS → FortiGate migration. It is honest about what FortiConverter handles automatically, honest about the seven things that always break, and honest about the when-to-wait cases.

Why customers ask about migration

Palo Alto's product is good. Customers don't move because of bad firewalls — they move because of three or four reasons that compound:

• Subscription economics. PAN's per-gateway subscription pricing — Threat Prevention, URL Filtering, WildFire, DNS Security, GlobalProtect — adds up. For mid-size BFSI estates the three-year delta against equivalent FortiGate bundles is material.
• Cortex Data Lake retention costs. Long-term log retention on Cortex bills by ingest volume. FortiAnalyzer (on-prem or VM) decouples retention from ingest cost. CFOs notice.
• Talent pipeline. NSE-certified engineers in India outnumber PCNSE-certified engineers by a wide margin. Easier to hire, easier to retain, easier to find at the SI partner level.
• Consolidation. If the customer already runs FortiManager, FortiAnalyzer, FortiSASE or FortiClient EMS for other reasons, removing the Palo silo simplifies operations.
• India compliance. RBI Master Directions, SEBI CSCRF, DPDPA 2023 and CERT-In all push for India-resident logging and crypto-agility. Both vendors satisfy these — but the cost of layering them onto an estate that depends on Cortex Data Lake is higher.

The 5-phase migration framework

Same proven pattern across every migration we run, regardless of source vendor. The discipline of the five phases is what determines whether you cut over in one weekend or spend three months chasing ghosts.

FortiConverter — what it actually does (and doesn't)

Fortinet's FortiConverter ships a native Palo Alto conversion wizard. Per Fortinet's official 7.4 documentation, it accepts a PAN-OS device config and optionally a Panorama config to convert together. Here's what it covers — and where it explicitly stops.

The "FortiConverter does NOT handle" column is precisely where most Palo Alto estates accumulate complexity. Per the same official Fortinet documentation, "Application conversion requires manual processing" when you choose the as-is App-ID conversion mode. The first 70% of your config takes a day. The remaining 30% takes weeks.

⚠️ The 7 things that always break

Every one of these has cost us a debugging cycle on a real production migration. Read them before you start.

Summary of what FortiConverter calls out for Palo Alto

Taking only what Fortinet itself documents in the Palo Alto Start options and conversion wizard pages:

• Source files supported — PAN-OS device config; Panorama config can be uploaded together with device config.
• Application conversion — "Converted source vendor's application ID as-is" output still requires manual processing.
• URL filters with paths — convert to external resources, requiring external server maintenance.
• Virtual router handling — must choose between merging into default VRF or converting to FortiOS VRFs. Both approaches change the original network structure.
• NAT policy module — PAN-OS uses two separate modules (NAT + Security). FortiGate handles NAT inline. FortiConverter makes "best effort" mapping; review the result.
• Wizard sections — Start options, PAN Source Configuration, Interface Mapping, Route Information, Conversion Result, Application Mapping.

Should You Migrate Off Palo Alto?

PAN-OS is a fine product. Do not migrate just because the renewal hurts in one cycle. The two questions worth answering before you start are whether the commercial case is clear and whether the timing actually works.

Common questions from prospect calls

✅ Key Takeaways

1. Palo Alto → FortiGate migration is a project, not a tool problem. Plan 8–14 weeks per gateway pair, not a single weekend.
2. FortiConverter ships a native Palo Alto wizard that handles the deterministic 70% — address objects, services, NAT (best-effort), most security policies. The remaining 30% needs manual work.
3. The seven always-break items — intra-zone default action divergence, custom App-ID signatures, universal rules, NAT module split, GlobalProtect HIP, Panorama hierarchy, decryption exclusions — are predictable. Build the project plan around them.
4. Run a minimum 14-day shadow log diff before cutover. Anything less misses weekly business cycles.
5. If your Palo Alto renewal is less than 8 weeks away or you are running another core change in parallel, renew PAN for one more cycle and migrate when the team is settled.
6. Whether you migrate yourself or use a partner, document every rule's original PAN-OS intent in the FortiGate comment field. The audit trail saves the next engineer six months from now.