Treat the current firewall as evidence, not the specification
A migration should not begin by converting every object and rule. Existing configurations contain historical exceptions, duplicate objects, undocumented dependencies, and controls that may no longer match the business.
Build a migration inventory that identifies interfaces, VLANs, routes, NAT, VPNs, public IPs, authentication, logging, high availability, SD-WAN, monitoring, and ownership. Confirm which items are genuinely required before translating them.
Validate behavior, not only syntax
Successful import does not prove equivalent behavior. Route preference, NAT order, application identification, security profiles, VPN negotiation, asymmetric traffic, and session handling can change across platforms and versions.
Create validation tests for business-critical traffic, remote access, site-to-site connectivity, internet publishing, failover, logging, and monitoring. Assign an owner and expected result to every test.
- Record current-state evidence
- Define the approved target state
- Agree the maintenance window
- Protect a tested rollback path
- Capture as-built documentation
Plan the first operating week
The migration is not complete when traffic passes. Teams need alert ownership, support contacts, backup procedures, change records, known exceptions, and a short list of post-change observations.
A controlled migration produces a supportable production state—not simply a new appliance with the old ambiguity copied into it.