Firewall migration

Expedition is end-of-life. Here is what actually replaces it.

Palo Alto Networks stopped supporting Expedition in January 2025. The official replacement for configuration migration is a paid professional service. This page lays out every option that still exists, what each one can and cannot do, and how to do the conversion by hand if you would rather not trust a tool at all.

Written by a network security engineer · last reviewed 20 August 2026

What actually happened

Palo Alto's announcement is unambiguous:

Two replacements were named:

• Strata Cloud Manager — cleanup and optimisation features are planned, but no release date was given for functionality comparable to Expedition's config migration.
• Professional Services / Migration Factory — a paid engagement using “automation, tactical scripts, and custom solutions”.

So the free path disappeared and the supported path became billable. If you have a migration scheduled and no budget line for professional services, that is the gap you are standing in.

The tools that still exist

All of the vendor migration tools are still maintained. The thing worth noticing is not that they are bad — they are good — it is which direction each one runs.

Doing it by hand — the parts people get wrong

You do not need a tool. Plenty of migrations are done manually, and if the estate is small that is a reasonable choice. What follows is the order that avoids the usual rework, whichever direction you are going.

1. Inventory before you translate anything

Interfaces first — including VLAN subinterfaces, port-channels and bridge groups — then zones, then objects and groups, then rules, then NAT, then routes. Translating rules before the interface and zone map is settled is the single most common cause of a rebuild, because rule scope is expressed in terms of zones that do not exist yet on the target.

2. Decide the zone map explicitly, on paper

ASA works in named interfaces with security levels. PAN-OS and FortiOS work in zones. Check Point works in a policy package with an implicit topology. These do not map one-to-one, and the mapping is a design decision, not a mechanical one. Write it down and get it reviewed before any conversion runs.

3. Expect NAT to be the hard part

Source NAT, destination NAT, static bidirectional and policy NAT each have a different shape on each platform, and ASA's twice-NAT in particular has no single clean equivalent. Convert NAT last, and verify each rule against the original by hand.

4. Do not silently drop what you cannot convert

VPN configuration, certificates, dynamic routing, HA pairing, and application/URL-filtering features generally do not convert cleanly. The failure mode that hurts is not “this did not convert” — it is “this did not convert and nobody was told”. Keep an explicit list of every element that needs manual rebuild, with the source line it came from.

5. Verify by re-parsing, not by reading

Once you have the target config, feed it back through a parser and diff it against what you intended. Reading a 400-rule config and believing it is correct is not verification.

RuleForge

I am a network security engineer and I have done these migrations. RuleForge is the tool I wanted to exist: it converts between any two of five vendors — Cisco ASA, Cisco FTD, Palo Alto PAN-OS, Fortinet FortiGate and Check Point — through a vendor-neutral intermediate model. Twenty directions, not one.

It runs as a single Go binary with SQLite storage and an embedded UI. It is offline by design: no telemetry, no outbound connections, nothing leaves the host. Your firewall configuration is the most sensitive text file in your estate and it has no business being uploaded anywhere — including to me.

The pipeline follows the manual order above, deliberately: Analyze → Map → Convert → Review. Conversion never runs on an unseen interface/zone map; you edit and approve it first. Every job produces a Conversion Process Report listing every element and its outcome, as a self-contained HTML file that prints to PDF.

What the free edition does, and where it stops

Stated plainly, because you should know before you spend an hour on it:

The 50-rule cap is enough to run your own config through it and judge the output quality on rules you know by heart. That is the point of it — evaluate on your real data before deciding whether the tool is worth anything to you.

Honest limits

• Five vendors. Juniper, Sophos and others are not supported.
• VPN, certificates, dynamic routing, HA and App-ID/URL features are reported for manual rebuild, not converted. They are captured with their source lines so nothing vanishes quietly — but you will still rebuild them by hand.
• A converted config is a starting point for a change window, not something to paste into production unreviewed. No migration tool changes that, including the vendor ones.

Run it

Grab the tarball and SHA256SUMS from the releases page, then:

sha256sum -c SHA256SUMS
tar xzf ruleforge-free-*-linux-amd64.tar.gz
./ruleforge
# dashboard on http://127.0.0.1:8428

Or build it yourself — one dependency, no build system:

git clone https://github.com/nizartuanku/ruleforge
cd ruleforge && go build ./cmd/ruleforge && ./ruleforge

Upload a config, pick the target vendor, walk the four steps.

Sources

• Important Update: End of Life Announcement for Palo Alto Networks Expedition — Palo Alto Networks LIVEcommunity
• Expedition board — Palo Alto Networks LIVEcommunity
• Firewall Migration Tool (FMT) FAQ — Cisco Community