How FwMigrate Translates Firewall Configs Without Missing a Rule

A technical walk-through of the parsing, normalisation, and validation pipeline behind cross-vendor firewall migration.

1. The migration problem in mid-market environments

A typical mid-market firewall migration touches between 800 and 4,000 rules. Most of those rules were written by people who have left. Comments are sparse, naming is inconsistent, and shadow rules accumulate for years.

The traditional migration playbook is a spreadsheet, two engineers, and four to eight weeks. Roughly one rule in fifty gets transcribed wrong. Half of those errors are caught in UAT. The rest surface in production, usually at 02:00 on a Tuesday.

FwMigrate addresses the underlying cause: vendor syntax divergence forces humans to context-switch hundreds of times per migration. Each switch is a chance to introduce a defect.

2. Per-vendor parsers and the intermediate representation

Each supported vendor (Palo Alto, Cisco ASA, Cisco FTD, Check Point, Fortinet, Juniper SRX, F5, pfSense, OPNsense, MikroTik, AWS Security Groups) has a dedicated parser. The parser walks the configuration top to bottom and emits structured tokens: address objects, service objects, security rules, NAT rules, application filters, and policy chains.

Tokens are then mapped into a vendor-neutral intermediate representation (IR). The IR uses the same primitives across all vendors: SourceZone, DestinationZone, SourceAddress, DestinationAddress, Service, Action, LogProfile, plus vendor-specific extensions stored as opaque metadata.

The IR is the contract. As long as a vendor parser produces a valid IR and a vendor emitter consumes one, any source vendor can target any destination vendor without a quadratic explosion of pair-wise translation code.

3. Translation: emitting target vendor syntax

Translation is IR → target. The emitter for each vendor knows the syntax, the object-naming constraints, and the policy-evaluation order of its target platform.

Two classes of translation exist. Lossless translations preserve every IR field exactly. Most rule-set migrations are lossless when the source and target both support zones, address objects, and service objects. Lossy translations drop or coerce fields that the target platform does not represent. FwMigrate flags every lossy translation explicitly rather than silently dropping data.

NAT rules, application-aware filtering, and identity-based policies are the most common sources of lossy translations. The emitter records the original IR alongside the emitted target rule so a human reviewer can see both.

4. Rule-by-rule validation and the risk diff

After emission, FwMigrate validates the migration along three axes. Equivalence: does the target rule match the same traffic as the source? Coverage: does the union of target rules cover every flow the source allowed? Drift: do new shadows or conflicts appear in the target rule-set that did not exist in the source?

Equivalence is checked by traffic-simulation: a representative set of synthetic packets is evaluated against both source and target rule-sets, and verdicts are compared. Coverage uses set-theoretic analysis on flow tuples. Drift detection re-runs the rule-analysis engine from FwChange against the target rule-set.

The output is the risk diff: a per-rule report listing equivalence verdict, coverage delta, and any new shadows or conflicts introduced by translation. Reviewers see the entire diff before any change touches a live firewall.

5. What gets flagged for human review

FwMigrate does not silently drop rules. The following always surface for human review:

• Lossy translations where target platform cannot represent a source feature
• Rules referencing user-identity or application-aware criteria when the target lacks those primitives
• Shadow rules that exist only in the source and would be unreachable in the target evaluation order
• Object-name collisions when source and target use different naming conventions
• Any rule whose equivalence verdict is uncertain (for example, when source action depends on URL filtering not yet ingested)

This is by design. Pretending that every config translates cleanly is what makes 02:00-Tuesday outages happen.

6. Deployment, scope, and the parts FwMigrate does not do

FwMigrate ships as a Docker image. On-premise deployment is the default — configurations never leave your environment. A hosted version exists for evaluation and small projects.

FwMigrate produces export-ready configuration packages. It does not push configurations to live firewalls. That deliberate separation keeps the change window in your control. Pair FwMigrate with FwChange when ongoing change management on the new platform is required.

Vendors not yet supported (Sophos, SonicWall, Hillstone, others) are tracked on the development backlog. The IR is stable enough that adding a new vendor parser plus emitter typically takes two to three weeks per platform.