280 Firewall Migrations: Dataset Findings 2026

Between 2018 and 2025 I led or contributed to 280+ enterprise firewall migrations across DAX-30 clients, KRITIS-regulated operators, and tier-1 financial services. After the dust settled on the last project I went back through the engagement records and produced a structured dataset. This post is the headline-numbers summary: cutover times, rule counts, failure modes, and vendor-specific edge cases that consistently surfaced.

The full dataset is the basis for the FwChange methodology and the technical white paper. It is single-author research, not vendor marketing. Numbers are anonymized and aggregated; no client identifiers are included.

1. Dataset Scope and Composition

Two hundred and eighty migrations is the post-cutoff count of projects where I had primary or secondary engineer responsibility for rule-base translation, validation, or cutover execution. Smaller advisory engagements where I reviewed somebody else’s work are excluded. The window is January 2018 through December 2025.

• Vendor mix on the source side: Cisco ASA (38%), Check Point R7x/R80+ (24%), Juniper SRX/Netscreen (16%), Fortinet FortiGate (12%), Palo Alto PAN-OS (6%), other (4% — mostly McAfee Sidewinder and Stonesoft remnants).
• Vendor mix on the target side: Palo Alto PAN-OS (51%), Fortinet FortiGate (29%), Check Point R80+ (11%), cloud-native (AWS Security Groups + Azure NSG, 6%), other (3%).
• Average rule-base size: 4,700 rules per estate; median 2,800; largest single estate 47,000 rules.
• Object counts: average 18,000 address objects, 3,200 services, 1,400 groups.
• Industry distribution: finance 31%, manufacturing 22%, energy/utilities 14%, healthcare 11%, public sector 10%, telco 8%, other 4%.

2. Time-to-Cutover Patterns

Cutover time was not a function of rule count alone. Three project sizes emerged in the data, separated more by complexity (number of zones, vendor diversity, audit scope) than raw rule count.

The drop from manual to AI-assisted in 2024+ was not magic. Most of the saving was eliminated rework: object resolution, NAT translation, application-ID divergence, and shadow-rule pruning are the four biggest time sinks, and all four respond well to LLM-driven analysis when the model has access to the normalized rule base.

3. Failure Mode Distribution

Across all 280 migrations there were 1,847 distinct cutover defects logged (an average of 6.6 per migration). Defects were classified at root cause, not symptom. The taxonomy was developed iteratively across the dataset; the companion post (Firewall Migration Failure Taxonomy) walks each class in detail. The headline distribution:

• Translation errors (28%) — rule semantics were misrepresented in the target syntax. Most common: PAN-OS “application” vs. ASA “service” confusion, and Check Point Cluster XL rule ordering.
• Object resolution gaps (24%) — nested groups, dynamic objects, and FQDN objects that did not resolve to the expected IPs in the target.
• NAT semantics drift (19%) — source/destination NAT order, hide-NAT vs. static, and policy-based NAT handled differently across vendors.
• Logging policy loss (12%) — per-rule logging settings were not preserved during translation; SIEM integrations broke silently.
• Application-ID divergence (10%) — PAN-OS App-ID matched traffic that ASA service entries did not, or vice versa.
• Implicit-deny inversions (7%) — default deny ordering between source and target produced different end-state behavior for unmatched traffic.

Translation errors and object resolution together account for more than half of all cutover defects. Both are deterministic given a complete source rule base, and both can be prevented with rigorous pre-cutover validation.

4. Vendor-Specific Edge Cases

Each vendor has consistent edge cases that surface in roughly every migration involving that vendor. These are well known to senior engineers but are rarely documented in vendor migration guides.

Cisco ASA → PAN-OS

• ASA service-objects that combine TCP and UDP in one definition need splitting into two PAN-OS service objects.
• ASA “any” in object-group form can hide intent; PAN-OS prefers explicit zones.
• Identity-based ASA rules using LDAP/AD groups require User-ID configuration on PAN-OS, not just rule translation.

Check Point R7x → R80+ or PAN-OS

• Inline-layer rules in R80+ do not translate cleanly to flat rule bases; ordered policies must be flattened.
• Cluster XL rule installation order can differ from policy order. Test with single-gateway dry-run before HA cutover.
• SmartDashboard objects with the same display name but different UIDs cause silent collisions when exported via the management API.

Juniper SRX → FortiGate or PAN-OS

• Junos zones may be more granular than PAN-OS zones — consolidation needs explicit decision.
• Junos policy “then count” statements provide per-rule hit counters that other vendors expose differently.
• SRX dynamic VPN policies have no direct PAN-OS equivalent; usually require GlobalProtect rebuild.

Fortinet FortiGate-to-FortiGate (version jumps)

• Major version jumps (5.x → 7.x) introduce new policy-id requirements; in-place upgrade preserves IDs but cross-platform migration does not.
• FortiManager policy package import drops per-rule comments unless explicitly migrated.
• SSL-inspection profiles bound to policies need certificate-chain rebuilds at the new endpoint.

5. What Changed Across the 7-Year Window

Three trends shifted the migration landscape between 2018 and 2025.

1. Cloud-native targets grew from 1% to 6% of migrations. AWS Security Groups, Azure NSGs, and to a lesser extent GCP firewall rules absorbed perimeter functions previously held by hardware appliances. Translation to cloud-native targets has its own failure modes (no FQDN object support, rule limits per security group, region-by-region replication) that did not exist in the appliance-to-appliance era.
2. Application-aware policies became table stakes. By 2022, more than 80% of new policies referenced applications rather than ports/protocols alone. This added complexity to translation but reduced the rule count for new estates by 35–45% on average.
3. AI-assisted analysis moved from research to production. The 2024 cutoff in the table reflects when LLM-based tooling matured enough to handle realistic vendor-syntax translation with verifiable output. Earlier attempts (2020–2022) produced too many translation errors to be trusted in regulated environments.

6. Methodology

Records were drawn from project closeout reports, change-management tickets, and post-cutover review documents. Rule counts and object counts came from the source firewall management platform exports. Defect taxonomy was developed iteratively: an initial list of 14 categories was reduced to the current 6 after pattern saturation around migration 180. Defect counts were drawn from cutover-window incident logs and the first 30 days post-cutover.

All numbers are anonymized at the engagement level. Industry distribution preserves regulatory context but no client identifiers. The dataset itself is not currently published; the white paper draws on aggregated findings.

7. Limitations

• The dataset over-weights European and DACH-region engagements; US Federal and APAC representation is thin.
• Pre-2020 records are less complete than later years; defect counts for 2018–2019 are conservative.
• Cloud-native migrations are under-represented relative to the current market mix — expect this to shift in any 2026–2027 update.
• The dataset is single-engineer experience. Cross-checking with peer datasets is welcome.

8. Practical Implications

Three actionable takeaways for teams currently planning a migration:

1. Budget for translation validation, not translation itself. The bottleneck is not converting syntax; it is proving the translation preserves intent. Automated diff-testing against a representative traffic capture is the cheapest insurance.
2. Plan object resolution as a separate phase. Treating address-group flattening, FQDN resolution, and dynamic-object handling as a distinct work stream with its own acceptance criteria avoids object failures cascading into rule failures.
3. Reserve cutover capacity for logging and NAT verification. These two failure modes account for 31% of post-cutover defects and are easy to miss in a rule-only validation pass.

The companion post on the failure taxonomy walks each defect class with detection patterns, sample symptoms, and prevention strategies. Together with the white paper, these three artifacts are the practical output of seven years of migration work.