Next-gen firewall licensing stacks per-appliance costs with threat-subscription bundles (IPS, URL filtering, sandboxing) and renewal uplifts. Open firewalls, OPNsense, pfSense, or Linux nftables, run on commodity hardware with Suricata-based IDS/IPS, removing the subscription tax for many edge and segmentation use cases. Palo Alto pairs per-appliance cost with Threat Prevention, URL Filtering, and WildFire subscriptions plus Panorama licensing; Fortinet stacks FortiGuard bundles across the fleet with features gated behind higher tiers; Check Point charges per gateway plus software blades and annual support uplifts; SonicWall bundles the appliance with security-service subscriptions and renewal uplifts. Open firewalls remove that recurring line, in exchange for assembling and operating the equivalent controls yourself.
There is no clean importer
Set the expectation early: there is generally no reliable automated importer from these commercial firewalls to an open one. Treat the vendor export as documentation, not an input. The rulebase has to be rebuilt by hand, recreating address and service objects as aliases, then translating each rule onto the correct interface in the original evaluation order, and mapping NAT as its own pass. That manual work is slower than an import would be, but it is where you find and delete the rules that survived only because nobody dared touch them, so you finish with a cleaner policy than you left.
Know which NGFW features you actually use
Export the rulebase, NAT, objects, and VPN configuration, document IDS/IPS profiles and threat features in use, and note HA and logging/SIEM integrations. Be honest about NGFW features you depend on, advanced app-ID, cloud-delivered threat intel, and central management have varying open equivalents. App-ID-style application identification, cloud sandboxing of unknown files, and vendor-curated URL and app categories rarely have a one-for-one open replacement; Suricata covers signature IPS and web-proxy plugins cover some filtering, but neither reproduces app-identification policy. Where a segment genuinely depends on those features, plan to keep the incumbent there rather than forcing a feature-for-feature swap.
Sizing matters more here
Size on NGFW (threat-protection) throughput, not raw firewall throughput, and remember TLS inspection can cut effective throughput by 50–70%. Account for IPSec VPN throughput, concurrent sessions, and connections/sec. Under-sizing is the classic firewall migration mistake.
Rebuild and pilot
Deploy the open firewall in HA (CARP), recreate rules/aliases/NAT, rebuild VPN tunnels (IPsec/OpenVPN/WireGuard) and remote-access users, and enable Suricata IDS/IPS with the relevant rulesets. Wire logging to your SIEM. Rebuild IPsec tunnels with phase-1 and phase-2 parameters matched to each peer exactly, and where a proprietary SSL-VPN client has no open equivalent, move those users to OpenVPN or WireGuard. Start Suricata in alert-only mode, tune out false positives on real traffic, then switch to blocking, doing it the other way round takes down legitimate flows on day one.
Cut over per site
Pilot at a low-risk site first, validate an allow/deny matrix and VPN connectivity live, then roll out site-by-site with rollback ready. Monitor logs and IPS for anomalies during hypercare. Roll back by re-pointing traffic to the source firewall.
What to test before you trust it
Rule/NAT verification (allow + deny), VPN connectivity (site-to-site and remote), IDS/IPS detection and throughput tests, and an HA failover test.
Use the TCO calculator to model a per-firewall comparison.