Firewall migration checklist: Fortinet, Palo Alto Networks, Check Point, and Cisco

Who this is for: network and security leads replacing a firewall platform, or consolidating several, who need a plan their change board can approve. Our engineers have managed FortiGate, Palo Alto Networks, and Meraki policy lifecycles, segmentation, NAT, and VPN in enterprise environments. The checklist is built on vendor documentation and reports no specific migration.

What do you inventory before you touch anything?#

Scope the whole configuration, not only the rulebase. A conversion tool reads the policy; production depends on everything around it.

An item you cannot explain is a blocker, not a note.

What is the firewall review checklist?#

This is the firewall review checklist. Run it on the source firewall before conversion, because every rule you convert is a rule you must keep testing.

What each counter counts:

• Palo Alto Networks (PAN-OS and Panorama). The rule usage query finds unused rules for removal. It needs the Policy Rule Hit Count setting enabled (Device > Setup > Management) and reports hit count, first hit, and last hit. Panorama marks a rule Used, Partially Used, or Unused across the firewalls of a device group.
• Check Point. Hit Count covers Access Control, NAT, and HTTPS Inspection rules, the last only on R82.10 and later gateways. A rule with zero hits had no matches on gateways where Hit Count is enabled; gateways where it is disabled may still have matches. Hit data is kept for a configurable range, three months by default.
• Fortinet FortiOS. The seven-day rolling counter stores hits and bytes for each of the last seven days plus the current day. The FortiOS 7.4.2 guide supports it on firewall and multicast policies but not security policies; from FortiOS 7.6.0, Fortinet documents a seven-day hit count for security policies in NGFW policy-based mode. Check the guide for your version.

A counter that is off, or was reset, proves nothing, and a seven-day or three-month window cannot show a quarterly job: export the counters, agree the review period with the owners, and use logs for longer cycles.

How do you map features, not syntax?#

A literal translation of rules can behave differently on the new platform. Before conversion, answer each question for the target platform and write the answer down.

Which conversion tools exist, and what is their status?#

This is the migration tool status table, read from the vendors’ pages on October 4, 2026. It will drift, so re-check it before you rely on it. It is not a ranking, and no tool replaces the review or the tests.

Three notes on Expedition, because many guides still center on it:

1. The end-of-life announcement of June 14, 2024, covers all versions of both branches, Expedition1 and Expedition2: no new features, fixes, security patches, or support. It points to Strata Cloud Manager cleanup features and to the Professional Services Migration Factory team.
2. Advisory PAN-SA-2025-0001 (published January 8, 2025, updated January 15, 2025) covers five vulnerabilities that can expose firewall usernames, passwords, configurations, and API keys. Expedition 1 versions below 1.2.101 are affected, and no further fixes are planned.
3. The advisory says to restrict network access to authorized users, hosts, and networks, and to shut Expedition down when it is not in active use. Treat it as a system that holds firewall credentials.

How do you test before cutover?#

Convert in a lab or a staging path first, then test behavior, not syntax. A conversion report shows that the tool wrote output, not that the traffic works.

1. Build a flow list from logs and the inventory: source, destination, port, protocol, and expected action, including VPN peers, monitoring, backups, and partner connections.
2. Define a pass condition per flow: connect, authenticate, transfer, and the log line you expect on the new platform.
3. Run a parallel period where you can, passing the same flows through the new firewall without moving production traffic, and compare logs.
4. Fix by decision, not by loosening. When a test fails, decide whether the rule or the test is wrong; do not add a broad temporary rule to make it pass.
5. Rehearse the cutover and the rollback. The rollback is part of the test.

What is the firewall cutover checklist?#

This is the firewall cutover checklist. It follows the same principle as the DNS cutover checklist for Cloudflare migrations: every step has an owner, a check, and a way back.

• Before the change window: source configuration exported and verified readable; target configuration approved by the rule owners; flow tests passed; window, participants, and the rollback decision-maker agreed in writing; target monitoring confirmed.
• During the change: apply the target configuration and verify interfaces, routing, and HA state; move traffic in stages, a low-risk segment first; run the flow list after each stage and record the results.
• Rollback conditions, agreed in advance: a critical flow fails and is not fixed within the time the change board allowed; a VPN peer or routing adjacency does not come up; logging or management on the target does not work. Rollback returns traffic to the source firewall, which stays configured and powered until the verification period, agreed with the owners, ends.
• After the change: watch denied traffic, tunnel state, HA events, and user reports for the first days; remove temporary rules; recertify rules with their owners; update the runbook; decommission the source on the agreed date.