Firewall Platform Migration: Moving from Check Point, Cisco ASA, or Fortinet to a Modern NGFW
Retool's new app builder is where AI-generated code ships safely
Building apps with AI is easy. Getting them to production safely is another story.
A firewall platform migration is not a like-for-like swap. Moving from Check Point to Palo Alto, or from Cisco ASA to Fortinet, involves converting potentially thousands of rules to a new vendor's syntax, replacing vendor-specific policy objects with equivalents in the new platform, and re-configuring security profiles (IPS, URL filtering, SSL inspection) that may have significantly different implementations across platforms.
Organizations that migrate by converting rules one-to-one and cutting over inherit all the accumulated security debt of the old platform — stale rules that should have been removed years ago, overly permissive rules that were intended as temporary, and rules with no logging that cannot be audited. The right approach uses the migration as an opportunity to clean the rule base, then converts and validates the cleaned ruleset before the production cutover.
Pre-migration: rule base cleanup
The business disruption of a firewall migration creates an organizational window to clean the rule base that is rarely available during normal operations, because stakeholders have already accepted change risk and attention is focused on the firewall. This section covers two techniques for identifying removable rules before conversion: hit count analysis using the existing platform's log data to find rules with zero traffic in the past 30 days, and permissiveness review to flag any-source or any-destination rules that cannot be traced to a current business justification. Running both analyses typically identifies 20-40% of rules as stale or reducible, which simplifies the converted rule base and removes the inherited security risk that comes from converting permissive rules onto the new platform.
Identify and remove stale rules using hit count analysis
Enable logging on all rules for 30 days if not already enabled. Export rule hit statistics from the firewall management platform. Rules with zero hits in 30 days are candidates for removal. For each zero-hit rule: query your ticketing system and change management records to find the original business justification. If no justification can be found and no owner can be identified after a 2-week inquiry period: schedule the rule for removal during the migration preparation. Create a separate ticket for each removed rule with the original rule details archived for reference. This pre-migration cleanup typically removes 20-40% of rules in mature environments, simplifying the migration and improving security posture.
Flag overly permissive rules for review
During the rule audit: flag any rules with source 'any', destination 'any', or service 'any' that are not documented with a specific business justification. These rules represent the highest security risk in the rule base and the highest migration risk (an overly broad rule converted incorrectly can create unexpected traffic flows in the new platform). For each flagged rule: request documentation from the original requester or rule owner. Replace 'any' sources and destinations with specific IP ranges or named objects where possible. Rules that cannot be scoped after inquiry should be escalated to the CISO for a risk acceptance decision before being converted into the new platform.
Post-migration validation
After conversion and parallel deployment, the validation phase determines whether the new firewall's rule base correctly allows all legitimate production traffic before the old firewall is taken out of the path. The primary validation method is deny log comparison: running both firewalls in parallel while comparing which sessions each platform would allow or deny for the same traffic. Any session that the old firewall allows but the new firewall denies represents a potential production outage at cutover. This section covers how to build this comparison view in a SIEM using dual log sources, what discrepancy patterns indicate conversion errors versus intentional tightening, and how to resolve each category before scheduling the cutover maintenance window.
Compare deny logs between old and new firewall during parallel operation
During parallel operation, the most important comparison is traffic that the old firewall is allowing that the new firewall is logging as denied. Any asymmetry in allows represents a potential cutover disruption. Build a comparison view in your SIEM: query both firewall log sources simultaneously for deny events with the same destination IP and port within the same time window. Discrepancies indicate rules that converted incorrectly, URL categories that differ between vendors, or application identification that does not match between platforms. Resolve each discrepancy before cutover — either add the missing rule to the new platform or confirm the new platform's behavior is intentionally more restrictive.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
The bottom line
A firewall platform migration done correctly improves security posture alongside completing the platform change — the rule base cleanup removes accumulated stale and overly permissive rules that the old platform never prompted removal of. Done incorrectly, it converts and inherits all of the old platform's problems plus introduces new ones from syntax translation errors. The sequence that avoids the second outcome: audit and clean the rule base before exporting it for conversion, use automated conversion tools as a starting point with manual review of complex rules, validate in parallel operation by comparing deny logs between platforms, cut over in a tested maintenance window with a confirmed rollback procedure, and monitor intensively for 30 days before decommissioning the old platform. The entire process takes 3-6 months for an enterprise environment — timelines shorter than this typically skip the validation phase and discover the gaps during production incidents.
Frequently asked questions
What is the recommended order of steps for a firewall platform migration?
Phase 1 (pre-migration, 4-8 weeks): Rule base audit — export the current rule base and identify stale rules (no hits in 90+ days), redundant rules (same as another rule with broader scope), shadow rules (rules never reached because a prior rule matches all the same traffic), and any allow-any rules or rules without logging. Remove stale and redundant rules before migration — this is the only time you will have stakeholder attention and business justification to clean the rule base. Phase 2 (conversion, 2-4 weeks): Run the automated conversion tool, manually review complex rules (NAT, VPN, application-specific rules), build in the new platform's equivalent of the old platform's security profiles (IPS, URL filtering, SSL inspection). Phase 3 (validation, 2-4 weeks): Deploy the new firewall in parallel, mirror traffic, compare logs, resolve discrepancies. Phase 4 (cutover, planned maintenance window): Execute cutover, monitor for 24-48 hours with elevated staffing, roll back if critical issues appear.
How do I audit the existing firewall rule base before migration?
Rule base audit process: (1) Enable comprehensive logging on all rules if not already enabled — rules without logging cannot be audited for hit counts or traffic patterns. Allow 2-4 weeks of logging before the audit to capture a representative traffic sample. (2) Export rule hit statistics from the management platform: Check Point SmartView Tracker, Cisco ASDM logs, FortiGate log analytics. Sort rules by hit count ascending — rules with zero hits in 30+ days are stale candidates. (3) Use a firewall rule management tool (AlgoSec, FireMon, Tufin) if available — these tools automatically identify unused rules, redundant rules, and overly permissive rules (allow any/any). Without a dedicated tool: manually review the top 20 rules by permissiveness (any source, any destination, or any port). (4) For each stale rule: trace back to its business justification using your ticketing system. If no justification can be found and no owner can be identified within 2 weeks, schedule removal during the migration.
Which automated tools convert firewall rule bases between vendors?
Vendor and tool options: (1) Palo Alto Expedition (free): converts rule bases from Check Point, Cisco ASA, Cisco Firepower, Juniper, FortiGate, and SonicWall to PAN-OS format. Handles policy objects, NAT rules, and security profiles with reasonable fidelity. Available at pan.dev/expedition. (2) AlgoSec FireFlow: commercial firewall management platform with migration capability, supports most enterprise firewall vendors, provides detailed analysis of which rules migrated cleanly and which require manual review. (3) Tufin SecureChange: commercial, similar capability to AlgoSec, strong for organizations with compliance requirements. (4) Vendor-provided migration assistants: Cisco provides a migration tool for ASA to Firepower migrations; FortiGate provides migration guides and scripts for converting other vendors' configs to FortiOS format. Important: treat automated conversion output as a starting point, not a finished result. Every converted rule base requires manual review of complex rules and testing in a lab environment before production deployment.
How do I validate the migrated rule base before cutting over to the new firewall?
Validation approaches in order of thoroughness: (1) Lab validation: deploy the new firewall in a lab environment with representative test traffic for all major application flows. Test each business-critical application by simulating a client connecting through the new firewall. This catches obvious conversion errors but misses long-tail traffic patterns. (2) Parallel operation with traffic mirroring: deploy the new firewall in-line but in monitor mode (or use a network tap to mirror traffic to the new firewall) so it sees the same traffic as the production firewall. Compare deny logs between the old and new firewall — any traffic that the production firewall is allowing but the new firewall would deny represents a potential outage at cutover time. Most enterprise firewall vendors support an 'audit mode' or 'shadow mode' for this purpose. (3) Staged cutover: move a non-critical network segment to the new firewall first (guest WiFi, dev environment) and monitor for 1-2 weeks before moving production segments.
How do I plan the cutover maintenance window for minimal downtime?
Cutover planning: (1) Choose a time when traffic is minimal (Sunday 2-4 AM for most B2B organizations; confirm by reviewing traffic volume logs for your lowest-traffic window). (2) Document the cutover runbook: each step listed with expected duration, responsible person, and success criteria. Typical steps: update routing to send traffic to the new firewall, validate top 10 business-critical applications, confirm logging is flowing to SIEM, confirm alerting is active on the new platform. (3) Pre-test rollback: before the maintenance window, test that you can revert routing back to the old firewall in under 30 minutes. The rollback must be tested, not just documented. (4) Staff the window: have network, security, and application owners available during and for 2 hours after cutover — the most common issues appear when business users start their day after a weekend cutover. (5) Define the rollback decision criteria before the window: if [X condition] occurs, we roll back immediately. 'X' should be specific: 'any Tier 1 application is unreachable for more than 15 minutes' is a clear rollback trigger; 'if things look bad' is not.
What commonly breaks during a firewall platform migration and how do I prevent it?
Common migration failure points: (1) SSL inspection differences: if the old platform did SSL/TLS inspection with a specific certificate, the new platform's SSL inspection certificate must be trusted by all clients before cutover — clients that see an untrusted certificate for HTTPS sites after cutover generate helpdesk tickets immediately. (2) VPN re-configuration: site-to-site VPN tunnels require re-negotiation when the local gateway IP or IKE configuration changes — coordinate cutover with all VPN peers (partner networks, branch offices) to minimize tunnel down time. (3) URL category differences: different vendor URL filtering databases classify some sites differently — a URL that was allowed in category X on the old platform may be in a blocked category on the new platform. Review URL category exceptions from the old platform and verify they transfer or add equivalent exceptions on the new platform. (4) Application detection: NGFW application identification varies by vendor — an application allowed by name on one platform may not be detected with the same name on another, causing unexpected blocks.
What should I do with the old firewall after the migration is complete?
Post-cutover firewall management: (1) Keep the old firewall running in parallel for a minimum of 30 days post-cutover, available for immediate rollback if a problem is discovered weeks later by a less-frequently-used application. (2) During the 30-day parallel period: monitor the old firewall's traffic logs — any traffic still reaching the old firewall indicates a routing path that was not updated during cutover. (3) After 30 days with no rollback: begin the decommission process. Remove the device from the network topology, revoke management access, and export the final running configuration for archive (compliance and forensics reference). (4) License review: most firewall vendors use subscription licenses for IPS, URL filtering, and threat intelligence. Canceling these subscriptions on the old platform recovers costs that can offset the new platform. Do not cancel until the old platform is fully decommissioned and you have confirmed the new platform is fully licensed. (5) Hardware disposition: if physical hardware, follow your organization's data destruction and hardware disposal policies — firewall hardware stores configuration that may include IPsec pre-shared keys and certificate private keys.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, daily, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals every morning.
Win a $2,495 Black Hat pass.
Full-access to Black Hat USA 2026 in Las Vegas. Subscribe free to enter.