hundreds of migrations, made repeatable

Why most migrations fail before they start

The industry default for a firewall migration has not changed in twenty years: export the rules to a spreadsheet, eyeball them line by line, hand-translate the syntax into the new platform, push the lot, and hope. I have inherited the wreckage of that approach often enough to know where it breaks. The failures are not random. They cluster in the same places, and they are all avoidable.

The mistake underneath all of them is treating a migration as a translation problem. It is not. It is an inventory and risk problem with a translation step in the middle. Get the inventory wrong and the cleanest translation in the world ships a rulebase nobody understands. The method below is ordered to fix the inventory first and translate last, because that is the order that holds up under audit.

Step 1: Discovery & inventory

Start by assuming the documentation is wrong, because it usually is. Temporary rules outlive the ticket that created them. Address groups reference objects that were renamed two years ago. Someone added an any/any "to test something" on a Friday and never came back. The running config is the only source of truth, so that is where discovery begins.

Pull the live policy off each device through its API rather than a CLI scrape: PAN-OS, FortiOS, Check Point R80+, Cisco ASA/FTD/FMC, and the rest each expose their rulebase in a structured form that survives parsing. Then resolve everything the rules point at: address objects, service objects, nested groups, and the references between them. A rule that allows Web-Servers to DB-Tier means nothing until you have expanded both groups down to addresses and ports.

The output of this step is not a report. It is a complete, machine-readable inventory of what is genuinely live, with every object dereferenced. If you cannot answer "what does this rule actually permit, to and from which hosts" for every line, you are not done with discovery.

The estate is never what the diagram says. Discovery exists to find the gap between the two, before that gap becomes a migration defect.

Step 2: Rule normalization across vendor syntaxes

Every vendor models policy differently, and the differences are semantic, not cosmetic. Palo Alto thinks in App-ID and security zones. Fortinet thinks in interfaces and virtual domains. Check Point layers policy and has its own object model. Cisco ASA is interface-and-ACL; FTD adds an access-control policy on top. Treating any of these as a find-and-replace exercise is how you turn an application-aware allow into a flat port-based one and quietly widen the attack surface.

Normalization means lifting every rule, from every platform, into one vendor-agnostic representation: source, destination, service, action, logging, and, where the source platform carries it, application intent. Once rules from different boxes share a single model, you can finally do the thing spreadsheets never let you do: compare them. Find the same intent expressed two different ways. Spot where the new platform has no equivalent construct and the rule needs a human decision rather than an automatic mapping.

This is also where the honest part of multi-vendor work lives. Most rules map cleanly. A minority do not, because the target platform genuinely cannot express what the source did. Those are flagged for a person, not silently approximated. A migration that pretends every rule has a perfect equivalent is lying to you.

Step 3: Shadow, conflict, and redundancy analysis

Now that every rule sits in one model, run the analysis the spreadsheet method can never do at scale: read the rulebase as an ordered system, not a list of independent lines. Three things fall out of that view, and all three are reasons not to carry a rule forward.

• Shadowed rules, a rule that can never match because an earlier rule already catches its traffic. It is dead weight that makes the rulebase longer and the audit harder, and it hides intent. Migrating it forward migrates a lie.
• Conflicts, the same source, destination, and service with contradictory allow and deny actions in different places. The firewall resolves these by order; a human reading the spreadsheet usually does not notice. The new platform's order may differ, which is how a conflict that was harmless on the old box becomes a hole on the new one.
• Redundancy and over-permissiveness: near-duplicate rules that inflate the count without adding security, and the any/any, any-source, and over-broad CIDR grants that should never survive a migration. A cutover is the one moment you are allowed to tighten these without a separate change project. Use it.

The discipline here is to decide the fate of every flagged rule before cutover, on the record. Keep, tighten, retire, each with a reason. The output is a clean target rulebase and a documented decision behind every rule that did not make it across. That document is half your audit evidence, written before you have touched production.

Step 4: Staged cutover with rollback

No flag days. The single biggest predictor of a clean migration is whether the cutover was staged, and the single biggest predictor of an outage is a big-bang switch with no way back. The method moves traffic in controlled windows, smallest blast radius first.

Sequence by risk, not by convenience. Start with a low-impact zone or a non-critical segment, prove the translated policy behaves, then widen. Each stage runs in a scheduled maintenance window with the change captured up front and a rollback that has been tested, not just written down. "We can roll back" means nothing until you have rolled back once in the lab and timed it.

Validate at each stage against the inventory from step one, the traffic that was permitted before is permitted now, the traffic that was tightened in step three is correctly denied, and nothing unexpected appears in the logs. Only then does the next stage start. A staged cutover trades a little calendar time for the ability to stop, reverse, and diagnose at any point, which is exactly the trade a regulated estate should always take.

Step 5: Evidence & audit trail

Compliance is not a phase that happens after the migration. If it is, the evidence is reconstructed from memory and it shows. The method captures the audit trail as the work happens, every change request with its source, destination, port, action, and intent; every approval, with who signed and when; every analysis finding and the decision taken on it; every cutover stage and its result.

Done this way, the evidence pack is a by-product, not a project. When the auditor asks why a rule exists, the answer is already on file, the request, the approval chain, the risk finding, and the window it shipped in. The frameworks European teams actually answer to: NIS2, ISO 27001, PCI-DSS, DORA, KRITIS, TISAX, all want the same underlying thing, a defensible record of who changed what, when, and why. Capture it once, at the source, and you can export it to any of them.

This is the step the spreadsheet method abandons entirely, and it is the step that turns a migration from a piece of infrastructure work into something you can stand behind in an audit. It is also the reason FwChange exists. The method works on paper; the platform makes it provable, repeatable, and faster the second time than the first.

Where the method came from

None of this is theory. It is the residue of a dataset of enterprise firewall migrations across regulated and enterprise environments, many of them KRITIS-regulated, where a botched cutover is not an inconvenience but a reportable incident. The patterns that recur across all of them are documented in the dataset findings; the ways migrations fail are catalogued in the failure taxonomy. Both are worth reading before you start your own.