Skip to content
Log in Sign up My account

Firewall Migration Playbook

Replacing a firewall is mostly a data problem followed by a risky weekend. This playbook walks through the phases that make the weekend boring: inventory, rule cleanup, translation, test and cutover planning, validation, and rollback. It is vendor-neutral, with examples from Cisco ASA-style syntax where a command makes a point clearer.

Phase overview

graph LR
    A["1 Inventory"] --> B["2 Cleanup"]
    B --> C["3 Translate"]
    C --> D["4 Pre-stage and test"]
    D --> E["5 Cutover"]
    E --> F["6 Validate"]
    F --> G["7 Decommission"]
    E -. "fail" .-> R["Rollback"]
    R --> D

Do not skip to translation. Translating a messy rule base faithfully gives you a messy rule base on new hardware, with new bugs.

1. Inventory

You need to know what the firewall does before you can replace it. Build a written inventory covering:

Functions

  • Interfaces, VLANs, subinterfaces, port channels, zones and security levels.
  • Routing: static routes, dynamic protocols, PBR, VRFs or virtual contexts.
  • NAT: static, dynamic, PAT, identity NAT, and the order they are evaluated in.
  • Access rules, object groups, time ranges, user and group based rules.
  • VPNs: site-to-site (peer, proposals, selectors, PSKs or certificates) and remote access (profiles, authentication, split tunnel lists).
  • Inspection and security services: IPS, URL filtering, malware, TLS decryption, application ID.
  • High availability: pair type, failover links, state sharing.
  • Management plane: AAA, SNMP, syslog, NetFlow, NTP, DNS, certificates, local users, API access.
  • Anything unusual: DHCP server or relay, proxy ARP, multicast, DNS doctoring, SIP or other application inspection.

Dependencies

  • Who sends traffic to this firewall as a next hop, and who does it use?
  • Monitoring systems, SIEM parsers and dashboards that depend on its log format.
  • Automation or ticket workflows that edit its rules.
  • Other firewalls or third parties that have rules pointing at its addresses.
  • License and support dates, so you know the timeline pressure.

Tip

Take full configuration backups and also capture operational state: routing table, ARP, show xlate, show conn count, VPN tunnel list, interface counters. This is your before-picture for validation.

show running-config
show access-list
show nat detail
show route
show vpn-sessiondb summary
show conn count
show interface ip brief

2. Rule cleanup

Most rule bases have decades of accumulation. Clean first, on the old device, so you migrate what is needed.

Gather usage evidence. Hit counts and last-hit timestamps are the cheapest data. On ASA-style platforms, show access-list includes hit counts; many platforms also give a last-hit time. Counters reset on reload, so collect over a long window, ideally 90 days or more, and via logs rather than counters alone if logging is on.

Classify rules:

Class Action
Shadowed (a rule above matches first) Delete
Redundant (duplicate of another) Merge or delete
Zero hits over the window Candidate for removal, confirm with owner
Overly broad (any any, large ranges) Tighten using observed flows
Disabled or expired Delete
Undocumented Identify owner or flag for review

Clean up objects too. Unused address objects, duplicate objects with different names for the same host, and nested object groups several levels deep all carry over into translation.

Rule hit analysis script. A small script saves time. This one reads a file of exported ACL lines with hit counts (ASA text output) and lists rules with zero hits.

import re
import sys
from pathlib import Path

HIT = re.compile(r"\(hitcnt=(\d+)\)")

def zero_hit_rules(path: str) -> list[str]:
    zero = []
    for line in Path(path).read_text().splitlines():
        m = HIT.search(line)
        if m and int(m.group(1)) == 0 and "remark" not in line:
            zero.append(line.strip())
    return zero

if __name__ == "__main__":
    for rule in zero_hit_rules(sys.argv[1]):
        print(rule)

Get owners to sign off. A rule with zero hits might be a quarterly batch job or a disaster recovery path. Send the candidate list to application owners with a deadline and a default of "removal" if no answer, and keep the removed set in version control so it can be restored.

Do not change policy and platform at the same time without recording both. If the rule cleanup is done on the old firewall before the migration, a problem after cutover is a migration problem, not a cleanup problem.

3. Translation

Translation converts configuration from the source vendor's model to the target's.

Options

  • Vendor migration tools. Several vendors provide tools for importing a competitor's or predecessor's configuration, for example Cisco's Secure Firewall Migration Tool for ASA to Secure Firewall. They handle objects, rules and NAT, and produce a report of what could not be converted. Use the current version of the tool and read its report.
  • Scripts. Parse the source with a library (for example ciscoconfparse), build a normalized data model in YAML or JSON, and render target configuration or push it via API or Terraform/Ansible.
  • Manual. Reasonable for small rule bases, and for the parts tools cannot convert.

What translation gets wrong

  • NAT semantics. Order of evaluation and the point where NAT is applied relative to ACLs differ between platforms. Rules written against the real (pre-NAT) address on one platform may need the translated address on another. Review every NAT rule and its matching access rule as a pair.
  • Zones vs security levels. Moving from interface security levels to zone-based policy changes implicit permit behaviour, such as higher-to-lower traffic being allowed by default.
  • Application inspection. Default inspections are not equal across vendors.
  • Application-aware rules. Port-based rules can become application ID rules; this is an improvement, but changes what is permitted.
  • Implicit rules. Default deny logging, implicit permits for management and ICMP handling.
  • VPN parameters. Crypto proposal names, DH groups and lifetimes must match the peer. Use the peer's required values, not the new platform's defaults.
  • Object limits. Platform-specific limits on rule count, object nesting and NAT entries.

Store the translated configuration in version control, and review it by diff against the intended policy, not only against the old config.

Warning

A translation report that says "100% converted" tells you the syntax converted. It does not tell you the behaviour is the same. Plan tests for behaviour.

4. Pre-stage and test

Build the new platform fully before the change window.

  • Install and license it, apply firmware you have tested, and set up management, logging and monitoring.
  • Configure the HA pair and test failover.
  • Load the translated policy with interfaces in an isolated state, or connected to a test segment.
  • Pre-stage VPN configuration and certificates and agree timing with remote peers.
  • Prepare the upstream and downstream changes: switch ports, VLANs, routes, ARP considerations.

Test traffic against the new rule base without production traffic if you can:

  • Packet-tracer style tools (for example packet-tracer on ASA, policy simulators on others) to verify specific flows.
  • A test host on each zone running a scripted set of connectivity checks.
  • A shadow or parallel period: mirror traffic to the new firewall in monitor mode, or run it in front of a non-critical segment first.

Write a test matrix before the change window: source, destination, port, expected result (permit or deny), and how to verify. Include the critical business flows, management access, DNS, NTP, authentication, VPNs, and log delivery.

5. Cutover plan

Choose the cutover model.

Model How Risk Rollback speed
Big bang Swap all traffic in one window High Depends on how clean the revert is
By zone or segment Move one VLAN, zone or site at a time Lower Fast per step
Parallel run Both firewalls live, routes shifted gradually Lowest Fast
In place hardware swap Same IPs and cabling moved to new unit Medium Needs re-cabling

A common clean pattern is to move the default gateways or routes for a segment from old to new using a routing change rather than re-cabling. Segment by segment, you shift and validate.

graph TB
    subgraph Before
    SW1["Core switch"] --> OLD1["Old firewall"] --> INT1["Internet edge"]
    end
    subgraph During
    SW2["Core switch"] --> OLD2["Old firewall"]
    SW2 --> NEW2["New firewall"]
    OLD2 --> INT2["Internet edge"]
    NEW2 --> INT2
    end

The runbook is a numbered list with times, owners and commands. For each step include:

  1. Action and exact commands.
  2. Owner.
  3. Expected result and how to check it.
  4. Abort criteria and time limit.

Include a communications plan: who is told, where status goes, who can call a rollback. Freeze other changes in the affected area. Get remote peers (VPN partners, carriers, DNS owners) lined up with contacts for the window.

Tip

Lower DNS TTLs and ARP/MAC aging expectations in advance if the cutover involves address moves. Check what MAC address and virtual IP behaviour the new HA pair uses so upstream devices learn it quickly. Gratuitous ARP generally handles this, but verify.

6. Validation

Validate in layers, directly after each step, and again after the window.

Immediately

  • Interfaces up, HA state healthy, routes present.
  • Run the test matrix. Record pass or fail.
  • Check that NAT translations are being created and that connection counts are rising.
  • Check VPN tunnels are up and passing traffic on both sides.
  • Confirm logs are reaching the SIEM, and syslog format parses.
  • Confirm monitoring, SNMP and NetFlow are collecting.

Compare to the before-picture. Connection counts, throughput, CPU, and the routing table should be in the same range. Large differences deserve an explanation.

After the window

  • Watch deny logs for traffic that the old device allowed. A spike in denies from known-good sources means a missing rule or a translation error.
  • Hand a short list of business owners a way to report problems and watch the first business day closely, including month-end or batch jobs if the window is near them.
  • Hold a post-change check after a week for things that run rarely.

7. Rollback

Decide the rollback criteria and design the rollback before you start.

  • Triggers: a critical flow in the test matrix fails and cannot be fixed within a set time, HA instability, a VPN that will not establish, or performance outside limits.
  • Method: for routing-based cutover, revert the routes. For re-cabled cutover, keep the old device powered, configured and cabled-ready. Do not wipe or repurpose it for at least the agreed retention period.
  • State: remember that moving back loses sessions in both directions. Long-lived connections will reset, and that is acceptable only if it was announced.
  • Rehearse: practise the rollback in the lab or in a pre-change dry run so the commands are tested.
  • Decision point: set a time in the runbook after which rollback is no longer practical, and a person authorized to make the call.

8. Decommission

Keep the old firewall available for a defined period. After that:

  • Remove its addresses from monitoring and inventory.
  • Revoke certificates, remove its credentials from AAA and shared secrets from VPN peers.
  • Securely wipe the device configuration and storage.
  • Archive the final configuration and the migration documentation.
  • Close out support contracts and license entitlements.

Common failure causes

  • NAT rule order or scope different on the new platform.
  • Missing rule for a flow that only appears monthly.
  • Asymmetric routing exposed by the stateful new device.
  • MTU or MSS differences causing slow or stalled large transfers.
  • Upstream devices holding an old ARP entry for the gateway.
  • Remote VPN peers not updated for a new public IP or different proposal.
  • Logging or monitoring dependencies forgotten.

For the routing and NAT fundamentals behind the cutover steps, see the CCNP study resources at cisconets.com/ccnp and the study plan.

References