Palo Alto to FortiGate migration: what the converter cannot do

The two policy models

Both platforms allow and deny traffic. They disagree about where the decision lives.

How PAN-OS states a rule

A PAN-OS security rule matches on zones, addresses, users and applications, then allows or denies. Application identity is part of the match condition. Inspection is attached separately as a security profile group, and decryption is a separate policy with its own rulebase.

The consequence for a migration is that the rule itself carries the intent. A rule that allows a named application says what the author wanted in the rule, and reading the rule is enough to know it.

How FortiGate profile mode states a rule

A FortiGate policy in profile mode matches on interface, address, service and schedule. Application awareness arrives through an application control profile attached to the policy, alongside web filter, antivirus and IPS profiles.

The intent is therefore split across two objects. The policy says which endpoints and ports are permitted. The profile says which applications are inspected and what happens to them. Reading the policy alone tells you less than reading a PAN-OS rule alone.

How FortiGate policy mode changes it

Policy mode moves application intent back into the policy. In policy-based NGFW mode, applications and URL categories are used directly in security policies without requiring web filter or application control profiles. Pre-match rules sit ahead of the security policies and carry the broader decisions such as SSL inspection and user authentication.

That structure maps more closely onto PAN-OS than profile mode does, which is why it matters to this migration specifically.

Mapping compiled from Fortinet's FortiOS administration guide section on profile-based and policy-based NGFW mode, and Palo Alto Networks policy documentation. Checked 8 August 2026. Behaviour is version sensitive on both platforms, so confirm against the release you are deploying.

Profile mode or policy mode

This is the first decision of the project and it constrains everything after it.

Policy mode is the closer structural match to a PAN-OS ruleset. It carries documented constraints. The NGFW mode is set per VDOM and is available only when the VDOM inspection mode is flow-based. Central NAT is always enabled, so source NAT moves out of the individual policies and into central SNAT policies. The IPsec wizard is unavailable, so tunnels are built manually.

Profile mode is the FortiOS default. Most FortiOS documentation, most partner runbooks and most FortiManager templates assume it. An engineer hired later is more likely to have seen it. Proxy-based inspection is available, which policy mode excludes.

Two criteria decide it in practice. Choose policy mode when the source ruleset is genuinely application-based and the team that will maintain it reasons in applications. Choose profile mode when the rest of the customer's estate already runs profile mode, when proxy-based inspection is required, or when the migrated ruleset turns out to be mostly ports and addresses wearing application names.

The third option deserves saying plainly. A ruleset that has drifted for six years is a candidate for rewriting rather than converting, and a migration is the only moment anyone will fund that work.

What converts cleanly

Fortinet's FortiConverter lists Palo Alto Networks among its supported source vendors and provides a dedicated conversion wizard for it. The objects below transfer with high confidence and need review rather than reconstruction.

Confidence ratings are our judgement based on the migrations we have run, rather than a vendor figure. Supported source vendors are from Fortinet's FortiConverter Palo Alto conversion documentation, checked 8 August 2026.

What needs a person

Six categories of configuration arrive as valid syntax that enforces the wrong thing.

Application-based rules

A rule allowing a named application on PAN-OS describes a decision about business traffic. Converting it produces either a port-based rule that is broader than the original, or an application control entry whose action depends on the profile it lands in. Both load. Both enforce something the original author did not write.

Each of these rules needs a sentence of intent before it can be rebuilt. What was this rule for, who asked for it, and what breaks if it is removed. That sentence is frequently unavailable, which is the actual reason migrations run long.

Custom application signatures

A custom App-ID has no counterpart to convert into. The equivalent FortiGate object is a custom application signature written against the same traffic. Identify these early, because they usually exist for a line-of-business application that somebody notices immediately.

Decryption policy

Decryption rules and their exemptions rebuild by hand on both platforms. The exemption list matters more than the rules. It encodes years of accumulated knowledge about which applications break under inspection, and losing it produces a sequence of user-reported faults with no obvious common cause.

User identity

User-ID mappings, group mappings and the agents that supply them are environment specific. The FortiGate equivalent is configured against the customer's directory during the build. Rules that match on a user group stay disabled until identity is confirmed working, because a user-matched rule with no identity source matches nobody.

Logging and reporting

Log fields, retention and report formats differ. A customer receiving a monthly report will notice a change in its shape before they notice anything else about the migration. Agree the report format before the cutover.

High availability and management

Cluster configuration, management access, administrator roles and backup schedules are rebuilt rather than converted. Treat them as part of the build rather than part of the conversion.

The manual pass

Run this in order. Each step depends on the one before it.

1. Export the running PAN-OS configuration and record the date. Every later comparison refers to this file.
2. Pull 30 days of traffic logs from the existing firewall. This is the evidence base for every intent question that follows.
3. Identify rules with zero hits over that period. Confirm each one with the customer rather than deleting it, since a rule may exist for an annual process.
4. Decide profile mode or policy mode, and record the decision.
5. Run the conversion. Read the tool's own report for what it declined to convert.
6. Rebuild application-based rules from intent, one at a time, using the log evidence to confirm what each was actually carrying.
7. Rebuild the decryption policy and its exemption list.
8. Configure identity, then enable user-matched rules.
9. Attach inspection profiles, or configure inspection in the security policies if you chose policy mode.
10. Review rule order end to end. Conversion frequently changes relative order in ways that are correct for individual rules and wrong in aggregate.
11. Rebuild NAT, and verify it explicitly in policy mode where central NAT applies to all matching traffic.
12. Configure logging, retention and the customer's report format.

Proving intent survived

The conversion report is not evidence. It describes what the tool produced rather than what the new firewall permits.

Traffic log comparison is the evidence. Run both firewalls against the same traffic where the topology allows it, or run the new firewall in a monitoring posture before it enforces. Compare the set of permitted flows on each, grouped by source and destination, and treat every difference as something to explain.

Choose the shadow period to include the things that happen rarely. A month end, a backup window, a patch cycle and a payroll run each generate traffic that a two-day validation misses. Most post-migration incidents come from this category rather than from anything in the daily flow.

Four checks belong in the cutover plan and are frequently absent.

• Test what happens when a rule matches and inspection is unavailable, on both platforms, before you rely on the answer.
• Verify the decryption exemption list against the applications the customer's staff use daily, including the ones nobody mentioned.
• Confirm that logging reaches the collector and that retention is what the customer's obligations require.
• Rehearse the rollback, including how long it takes and who authorizes it.

FortiGate to Palo Alto

The principle holds in this direction and the tooling has changed.

Palo Alto Networks retired Expedition, its free migration tool, at the end of December 2024. Configuration migration now runs through its Professional Services and Migration Factory team, with cleanup and optimization features available in Strata Cloud Manager for configurations managed there. Plan the reverse direction as a services engagement or as scripted work, rather than around a self-service tool.

The technical problem is the mirror image and it is harder. A profile-mode FortiGate ruleset carries application intent in profiles attached to policies, so the policies themselves describe ports and addresses. There is less intent available to translate, and the target platform expects application-level rules. The practical route is to author the PAN-OS ruleset from traffic evidence rather than from the source configuration, which is a rewrite with a reference document rather than a conversion.

Expedition end-of-life status and the current migration path confirmed against Palo Alto Networks announcements and community documentation, checked 8 August 2026. Vendor tooling in this area changes, so confirm the current path before scoping a project.