NGFW Migration Playbook: Replace Firewalls Safely

A firewall migration is the one moment an organisation rebuilds its whole network policy, and converting the old rule base as-is copies every unused rule, broad exception, stale VPN account and shared secret onto new hardware that will run for another decade. Firewall replacements are driven by end of support, hardware refresh, a change of vendor, consolidation after a merger, or a move of perimeter functions into the cloud. This playbook covers moving from one next-generation firewall platform to another: what has to move besides rules, cleaning the rule base during conversion, re-issuing secrets held in the configuration, hardening the new management plane, cutover patterns, validation and rollback, and decommissioning the old devices. It is vendor-neutral and draws on NIST SP 800-41, joint government hardening guidance and NIST SP 800-53 controls. Day-to-day rule management is covered in the Firewall Management Guide; this page does not repeat it.

Key takeaways

Clean before you convert. Remove unused, shadowed and expired rules on the old platform first, so the conversion tool and the reviewers handle a smaller, truer rule base.
Configuration files are secret stores. Pre-shared keys, RADIUS and TACACS+ secrets, SNMP communities, API keys and the TLS inspection CA key sit in the config; re-issue them on the new platform rather than importing them.
VPN accounts are identities, not settings. Migrate users from the directory with MFA, and do not carry local accounts and their old passwords across.
Harden the management plane before the first packet. Out-of-band management, no internet-facing admin interfaces, SSO with MFA and central logging belong in the build, not after cutover.
Prove equivalence with traffic, not with rule counts. Test flows, compare hit counts and logs, and keep the old device ready to swap back until the freeze ends.

What has to move

NIST SP 800-41 Rev. 1 frames firewall work as policy first, then selecting, configuring, testing, deploying and managing the solution. For a migration, that means inventorying every object the old platform holds and deciding, per object, whether it moves, is rebuilt or is retired.

Object	Migration approach	Watch for
Security rules	Clean on the source, convert, then review every converted rule	Converted "any" fields and application rules translated back to ports
NAT rules	Convert and test each public mapping	Order-dependent NAT behaving differently on the new platform
Address, service and application objects	Normalise naming; merge duplicates	Application identification differs between vendors; some apps have no equivalent
Zones and interfaces	Map to the target zone model and segmentation design	Collapsing zones to simplify conversion
Site-to-site VPN tunnels	Rebuild with new pre-shared keys or certificates, stronger proposals	Peers that only support legacy algorithms
Remote access VPN	Rebuild on directory authentication with MFA	Local user accounts and their passwords carried over
TLS inspection policy and CA	Issue a new inspection CA; distribute to endpoints before cutover	Exporting the old CA private key; exemptions lost
Intrusion prevention, URL and malware profiles	Map categories; start from the target's recommended profile	Profiles attached to fewer rules than before
User identity sources	New directory integration accounts with least privilege	Old service accounts with directory read rights left enabled
Dynamic routing and authentication keys	Rebuild peers with new keys	Route leaks during the swap
Management settings (admins, AAA, SNMP, syslog, NTP, API)	Build fresh from a hardened baseline	Default or shared admin accounts; SNMPv2c communities
External threat feeds and dynamic lists	Re-subscribe; verify update frequency	Lists referenced in rules but empty on the new platform
Logs and audit history	Archive for the retention period	History destroyed with the old appliance

Cleaning the rule base during conversion

Automated converters translate syntax, not intent. A rule base that grew over ten years usually contains rules that nobody can explain, and conversion is the cheapest moment to remove them. See the Firewall Rule Review Checklist and the Firewall rule lifecycle guide.

Collect hit counts: export rule hit counters covering at least a full business cycle (our recommendation is 90 days, longer where quarterly or annual jobs exist).
Remove dead rules on the source: zero-hit, shadowed and expired rules, after owner confirmation. Disabling first and deleting later gives a cheap rollback.
Attach an owner and reason to the rest: rules without an owner go to a review queue rather than to the new platform.
Convert: run the converter on the cleaned source and keep its report of untranslated items.
Tighten where evidence allows: replace broad port rules with application-aware rules where logs show the actual applications. Do it in a later wave if the team is learning the platform, but schedule it.
Keep a default deny: NIST SP 800-53 SC-7(5) asks for deny by default, allow by exception; check the converted policy still ends in an explicit, logged deny.

Re-issuing secrets held in the configuration

A firewall configuration file is one of the most sensitive files an organisation holds. Treat exports and conversion workspaces as secret material, and re-issue rather than move each secret.

Secret	Re-issue approach	Old secret
Site-to-site VPN pre-shared keys	New key per tunnel, or move to certificates	Retire at tunnel cutover
TLS inspection CA	New CA key generated on the new platform or an HSM	Remove from endpoint trust stores after cutover
RADIUS and TACACS+ shared secrets	New secret per device on the AAA server	Delete the old device entries
SNMP	SNMPv3 with authentication and encryption	Disable v1 and v2c communities
Directory integration account	New service account, read-only, scoped	Disable and remove
Management API keys	New scoped keys for automation, stored in a secrets manager	Revoke on the old platform
Routing protocol keys	New keys agreed with peers	Remove at peer cutover

The joint guidance published by CISA, NSA, FBI and partner agencies in December 2024, Enhanced Visibility and Hardening Guidance for Communications Infrastructure, recommends storing configurations centrally and pushing them to devices, alerting on configuration changes made outside change management, using SNMPv3 with authentication and encryption, and changing default passwords on first use. Build those into the new platform from day one. The live Salt Typhoon breach page shows how stolen credentials and network device secrets kept attackers inside telecom networks.

Where identity fits: VPN and admin accounts

Remote access VPN users and firewall administrators are the identities most often abused on edge devices (ATT&CK T1133 External Remote Services, T1078 Valid Accounts). A migration is the moment to fix how they authenticate.

Do not carry local VPN accounts: in the SonicWall SSL VPN account compromises, the vendor linked an earlier wave of attacks to customers keeping old local passwords after firewall migrations. Authenticate VPN users against the directory with MFA, and if a local account must exist, reset its password on the new device.
Remove dormant accounts before conversion: the Colonial Pipeline attack began with an unused VPN account. Compare VPN accounts against HR and directory status, and migrate only active, owned accounts.
Federate administrators: admins should sign in through central AAA or SSO with phishing-resistant MFA; keep one break-glass local account per device, with its password vaulted and changed after each use, as the joint guidance advises.
Scope automation identities: orchestration and configuration management tools that push policy need their own scoped API keys, not a shared admin login. See the Next-generation firewall (NGFW) integration security guide.

Hardening the new management plane

No internet-facing management: CISA BOD 23-02 requires federal civilian agencies to remove management interfaces of devices including firewalls and VPN concentrators from the public internet within 14 days of discovery, or protect them with a zero trust policy enforcement point. It is a sound baseline for any organisation.
Out-of-band management: manage the new devices only from a separate management network and dedicated admin workstations, per the joint guidance.
Disable insecure services: Telnet, HTTP management, SNMPv1 and v2c, and unused protocols, before the device joins production.
Verify the software image: compare image hashes with the vendor's published values before installing, then patch to the current supported release.
Central logging first: send traffic, threat, system and configuration logs to the SIEM before cutover, so the first day of production is visible.

Choosing a cutover pattern

Pattern	How it works	Choose it when	Trade-off
Parallel run in monitor or tap mode	New firewall sees a copy of traffic and logs verdicts without enforcing	Large or complex rule bases; application identification changes	Needs span or tap capacity; no enforcement evidence for NAT and VPN
Segment or site by site	Move one zone, branch or data centre at a time	Many sites or a clear segmentation model	Mixed estate for months; policy in two places
Single window swap	Re-cable or re-route all traffic to the new pair in one change	Single site, well tested config, short maintenance window	All issues at once; rollback is a physical or routing swap
Routing-based cutover	Shift traffic by route preference, then remove the old path	Data centre and cloud edges with dynamic routing	Asymmetric routing breaks stateful inspection if not planned

Decision guidance: a small organisation with one site and a modest rule base can swap in one maintenance window after lab testing, provided the old device stays racked and configured for rollback. A large organisation should run in monitor mode where possible, then move by segment or site, starting with low-risk branches and leaving the data centre core and internet edge to last. Use the move to apply the segmentation the organisation wants, not just the one it has; see the Network Segmentation Guide.

The phased playbook

Phase 0, inventory and baseline: export configuration, hit counts, VPN accounts and active sessions; map flows per segment from logs; record baseline metrics.
Phase 1, clean the source: remove dead and unowned rules and dormant VPN accounts on the old platform.
Phase 2, build the target: hardened management plane, central logging, AAA, new secrets, then the converted and reviewed policy.
Phase 3, test in the lab: run a test plan per segment: allowed flows succeed, denied flows fail, NAT mappings resolve, VPN tunnels establish, inspection profiles trigger on safe test files, and failover works.
Phase 4, monitor mode or pilot site: compare verdicts and hit counts with the old firewall.
Phase 5, cutover per wave: in a change window, with application owners on call and a test script per critical flow.
Phase 6, freeze: the old device stays powered and configured, but out of path, for the agreed period.
Phase 7, decommission: see below.

Rollback

Write the swap-back steps: cabling, routing or HA changes needed to return to the old pair, rehearsed in the lab.
Agree triggers: for example any critical business flow failing after 30 minutes of troubleshooting, or VPN success rate below 95% of baseline (our recommendation).
Freeze rule changes on the old device: during the freeze, so a rollback does not reintroduce an outdated policy; record any emergency change on both.
Never roll back to an "allow any" rule: on the new device to make a problem go away; roll back the wave instead.

Decommissioning the old firewall

Archive logs and the final configuration: keep them for the retention period your policy sets (NIST SP 800-53 AU-11), encrypted, with access restricted.
Revoke what it held: AAA client entries, directory service accounts, VPN certificates, API keys, SNMP users and the old inspection CA in endpoint trust stores.
Remove cloud and support portal links: configuration backups stored in a vendor cloud service contain the same secrets; delete them. SonicWall confirmed in October 2025 that firewall configuration backups in its cloud service had been accessed.
Sanitise the device: follow the vendor's factory reset and storage wipe procedure and NIST SP 800-88 Rev. 2, and record it (MP-6), before return, resale or disposal.
Update diagrams and the asset inventory: so the old device's addresses and DNS names are not reused unexpectedly.

Detection and measurement

Metric or signal	Why it matters	Target (our recommendation)
Rules migrated without owner and reason	Shows unreviewed carry-over	Zero
Rules with any source, destination and service	Broad exceptions surviving the move	Fewer than on the old platform, each justified
Local VPN accounts on the new platform	Accounts outside directory and MFA	Break-glass only
Secrets imported rather than re-issued	Old exposure moved to new hardware	Zero
Management interfaces reachable from the internet	BOD 23-02 exposure	Zero
Configuration changes outside change management	Detects drift and tampering	Zero unexplained; alert on each

Monitor denied traffic and VPN authentication failures closely in the first weeks: denied flows show missed rules, and authentication failures show accounts that should not have migrated.

Common failure patterns

One-to-one conversion: every old rule copied, so the new firewall starts life with the old one's debt.
Imported secrets: the same PSKs, SNMP communities and inspection CA key now live on two platforms and in a conversion workspace.
Local VPN passwords kept: accounts and passwords carried across without reset or MFA.
Management exposed during build: the new device is staged with its admin interface on the internet "just for setup".
Application rules converted back to ports: losing the main reason for buying a next-generation platform.
Old device left powered on the network: unpatched, still holding valid secrets, and still answering on its management address.

Framework mapping

Activity	NIST SP 800-53 Rev 5	NIST CSF 2.0	Other
Rule base and default deny	SC-7, SC-7(5), AC-4	PR.IR-01	NIST SP 800-41 Rev. 1
Baseline and hardened configuration	CM-2, CM-6, CM-7	PR.PS-01	Joint hardening guidance (Dec 2024)
Change control and rollback	CM-3	PR.PS-01	Not mapped
VPN and admin authentication	AC-17, IA-5, AC-6	PR.AA-05	ATT&CK T1133, T1078
Management interface exposure	SC-7, AC-17	PR.IR-01	CISA BOD 23-02
Flow documentation	AC-4	ID.AM-03	Not mapped
Monitoring and log retention	AU-6, AU-11	DE.CM-01	Not mapped
Device sanitisation	MP-6	PR.DS-01	NIST SP 800-88 Rev. 2

Practitioner checklist

Export hit counts over at least a business cycle and remove dead, shadowed and unowned rules before converting.
Review every converted rule and the converter's untranslated items report.
Treat configuration exports as secrets and re-issue PSKs, AAA secrets, SNMP, API keys and the inspection CA.
Migrate VPN users from the directory with MFA; keep only vaulted break-glass local accounts.
Build out-of-band management with no internet-facing admin interfaces before cutover.
Send traffic, threat and configuration logs to the SIEM before the first production packet.
Test allowed and denied flows, NAT, VPN, inspection and failover in a lab, then in monitor mode or a pilot site.
Keep the old device configured and out of path for the freeze period, with rehearsed swap-back steps.
Archive logs and configuration, revoke the old device's identities and secrets, delete cloud backups and sanitise it.

Next-generation firewall (NGFW) migration playbook: replace firewalls without carrying old risk