How to Replace Your Firewall (Firewall Migration Plan)

Written by Mike Pearlstein, CISSP, CEO of Fusion Computing Limited. Helping Canadian businesses build and manage secure IT infrastructure since 2012 across Toronto, Hamilton and Metro Vancouver.

A firewall migration plan is the documented sequence a Canadian SMB follows to retire one perimeter firewall and stand up its successor without breaking production traffic, audit evidence or the rollback path. The plan, more than the hardware, decides whether the cutover succeeds.

This playbook walks the seven steps Fusion Computing uses on managed cybersecurity services engagements in Toronto, Hamilton and Metro Vancouver. Each step names its output artefact and the failure mode it prevents.

When should a Canadian SMB migrate firewalls?

According to the Canadian Centre for Cyber Security (2025), threat actors are actively exploiting edge devices. The assessment names routers, firewalls and VPN appliances as the perimeter gear under attack, and notes that exploitation often starts within days of a disclosure. A firewall past vendor support cannot receive the patch that closes that window.

Four triggers move a firewall onto the replacement calendar. Fusion Computing recommends planning the swap at year five, and treats two triggers firing in one quarter as a hard deadline rather than a planning note.

• The unit is past vendor end-of-life, so security patches have stopped arriving.
• Throughput or inspection load has outgrown the model, usually visible first in TLS decryption.
• A compliance gap needs a feature the platform cannot deliver, such as identity-aware policy.
• Annual maintenance passes 30 percent of what a new unit costs.

The Cyber Centre baseline for small and medium organizations (2020) puts perimeter defence in section 3.9, and asks for dedicated firewalls at every boundary between the corporate network and the internet. CIS Control 12, Network Infrastructure Management, makes the same point in operational terms.

The 7-step firewall migration playbook

According to Statistics Canada (2024), about one in six Canadian businesses was hit by a cyber security incident in 2023. Firms that size rarely carry a dedicated network team, so the runbook has to survive being executed by people who also answer the phones. Every step below names one owner, one output and one pitfall.

Scope a Firewall Migration

Scoped and reviewed by Mike Pearlstein, CISSP, with our Toronto, Hamilton and Vancouver teams.

Step 1: Inventory the current ruleset

According to the Cyber Centre (2025), TLS, IPsec and SSH deployments still carry algorithms its guidance now marks for phase-out. The VPN export is where those surface. Capture IKE and IPsec parameters during inventory and the migration becomes the moment weak crypto retires, rather than the moment it gets copied onto a new appliance.

Inventory exports six artefacts: rule base with hit counts, NAT and routing tables, VPN tunnel list with IKE and IPsec parameters, IPS profile, throughput baseline and a 12-month change log.

Pull hit counts using FortiGate Hit Count, Palo Alto Panorama Policy Optimizer, or Cisco Firepower Management Center analytics. AlgoSec and Tufin cover mixed-vendor estates. Capture at least 30 days so month-end processes appear in the dataset.

Step 2: Audit the rules

According to NIST SP 800-41 Revision 1 (2009), managing a firewall solution includes reviewing the policy on a schedule. A migration is where that deferred review comes due. A rule base nobody has read in five years becomes the new appliance starting configuration unless somebody stops to score it first.

The audit turns the inventory into a smaller, justified rule set. Rules with zero hits over 30 days get flagged. Shadowed rules, the ones that never trigger because an earlier rule already matches, get removed. Every survivor gets an owner, a ticket reference and a justification.

In our practice, 38 percent of ACL rules in firewalls older than five years are unused or shadowed. Our engineers found the same pattern whether the outgoing appliance came from Fortinet, Cisco or Palo Alto. We audit before shortlisting next-generation firewall types, so the new device runs the policy a business actually needs.

Sitting on a rule base nobody has scored? Book a consultation with our CISSP-led team and we will read the hit-count export with you before the platform decision gets made.

Step 3: Choose the destination platform

According to the Center for Internet Security, CIS Control 12 asks organizations to actively manage network devices so attackers cannot exploit vulnerable services. Read that as a shortlist filter. The platform your own team can operate every week beats the platform with the longer datasheet, every time.

Match feature need to operational fit. FortiGate suits sub-100-seat single-site SMBs wanting native SD-WAN, Canadian log residency and one bundled license. Palo Alto fits multi-site estates carrying PCI-DSS or PIPEDA evidence load. Cisco Secure Firewall fits Cisco-standardised identity stacks.

Feature parity at the top of this market is real. Application-aware policy, integrated IPS and TLS inspection ship as table stakes on Fortinet, Palo Alto and Cisco alike. What decides a migration is the licensing model, where logs land and how much policy your team can change without a vendor ticket.

Step 4: Pre-migration testing (lab cutover)

According to Fortinet (2026), its FortiConverter tool performs unlimited configuration conversions across a library of third-party firewalls. Automated conversion is a starting point. It reproduces syntax faithfully and tells you nothing about whether the converted policy holds up under live TLS-decrypt load.

The lab cutover runs the new policy through 3 phases. Phase one is a clean policy commit on an isolated lab. Phase two is parallel passive, with the new device behind a tap or SPAN port, logging only. Phase three mirrors production traffic to it while the legacy stays in line.

Vendor tooling shortens phases one and two. Fortinet ships FortiConverter for ASA, Palo Alto and Check Point conversions. Cisco ships the Secure Firewall Migration Tool. AlgoSec and Tufin handle multi-vendor policy translation.

“Within the first week of Fusion’s onboarding, they found unpatched servers, no working backups and admin credentials that hadn’t been changed since 2019. It was genuinely alarming.”

Stale credentials are what step 7 of this plan exists to close. A migration surfaces them because somebody finally reads the configuration line by line.

Step 5: Cutover window and rollback plan

According to the Cyber Centre baseline, small and medium organizations should keep dedicated firewalls at every boundary to the internet. During a cutover that boundary is briefly held by two devices at once. Three controls decide whether the overlap works as a safety net or becomes the outage.

The cutover depends on a tested HA failover path, pre-staged DNS or default-route changes that flip in under five minutes, and a rollback path with a 15-minute return target. Without all three, plan a maintenance window instead of promising low downtime.

Step 6: Post-cutover validation and traffic monitoring

According to the Center for Internet Security (2024), the CIS Controls are a prioritized set of safeguards against the attacks that actually happen. Log review is one of them. The two weeks after a cutover are when a mistranslated rule shows up as a quiet application failure rather than an alert.

Validation runs on two checkpoints, T plus 24 hours and T plus 14 days. The 24-hour review reads logs for unexpected denies, decryption failures and HA-pair flaps. The 14-day review compares throughput, session count and IPS hit rate against baseline.

Centralise log review in FortiAnalyzer, Palo Alto Strata Logging, or Cisco Secure Cloud Analytics, with retention at 12 months or the regulator requirement, whichever is longer. Anything outside baseline gets a ticket before the legacy device leaves the rack, and network security testing closes the loop.

Step 7: Decommission and document

According to CIS Control 12, network devices have to be tracked, reported on and corrected throughout their life. That obligation does not end when an appliance leaves the traffic path. Fusion Computing operates the legacy device in monitored stand-by for 14 days, then wipes it and records the disposal.

Decommission retires the legacy device on a 14-day timer. Wipe the configuration, disable admin accounts, remove the device from monitoring, and record asset disposal. Archive the configuration baseline, audit report, lab report, change ticket and stabilisation report into the client evidence vault.

An auditor, a cyber insurer or a buy-side due diligence team will ask for that evidence pack. Building it during the project costs a fraction of reconstructing it 18 months later.

Firewall migration checklist: a 12-point guide to the change window

According to NIST SP 800-41 Revision 1, testing and documentation belong inside firewall management rather than beside it. The checklist below is what Fusion Computing works through before a change advisory board signs off. Twelve items, each a yes or no, with no partial credit.

1. Rule base, NAT, routes, VPN and IPS profiles exported and stored outside the appliance.
2. Minimum 30 days of hit counts captured, covering at least one month-end close.
3. Zero-hit and shadowed rules removed, with every survivor carrying a named owner.
4. IKE and IPsec parameters reviewed against current Cyber Centre crypto guidance.
5. Signed bill of materials and a license plan that covers the full support term.
6. Clean policy commit passed on an isolated lab build.
7. Parallel mirrored test run for a full 24 hours at production load.
8. TLS-decrypt headroom measured at peak, not at the vendor headline rate.
9. Rollback config exported, tested and timed against the 15-minute return target.
10. DNS TTLs lowered and the helpdesk briefed 24 hours ahead.
11. Smoke-test list agreed with the owners of Microsoft 365, ERP, VoIP and VPN.
12. Evidence pack location confirmed before the legacy device is wiped.

Items 7 and 8 are the two most often skipped, and between them they account for most of the cutovers we are called in to rescue.

What do PIPEDA, PCI-DSS, and Bill C-8 require from a firewall migration?

According to the Office of the Privacy Commissioner of Canada (2015), personal information must be protected by safeguards appropriate to its sensitivity. PIPEDA names no firewall model. It asks whether the control you chose matches the data behind it, and a migration is when that question gets a documented answer.

PCI-DSS is stricter for cardholder environments, because it wants documented change control and evidence that network security controls were reviewed. Archive the change ticket and the audit report together, with 12 months of logs behind them, and the migration produces both.

Bill C-8 (2026) received royal assent on June 15, 2026 and reaches federally regulated vital systems in telecommunications, finance, energy and transport. Most Canadian SMBs sit outside it and inherit the obligation through a contract with a covered customer.

Holding a questionnaire you cannot answer yet? Talk to our CISSP-led team and we will map what your current perimeter evidence covers against what the customer is actually asking for.

How much does a firewall migration cost in Canada?

According to a Fusion Computing benchmark drawn from single-site engagements, the appliance itself is rarely the largest number in the file. Licensing, the migration project and the ongoing operating line together outweigh the hardware over a five-year hold, which is why the cheapest box on the quote is often the expensive choice.

Budget in four parts rather than one.

• Appliance. Amortise the hardware over the 5-year replacement cycle.
• Support and subscriptions. Plan for 15 to 20 percent of appliance cost each year.
• Migration project. Fixed fee, sized by rule count, number of VPN tunnels, and site count.
• Ongoing operations. Fusion Computing prices managed cybersecurity from CA$180 to CA$250+ per user per month, with the firewall inside that line alongside monitoring, rule changes and log review.

Firms running the firewall without a managed line meet the cost later, when a routine rule change waits 3 weeks for someone with time.

Book a Consultation

Canadian-owned since 2012. CISSP-led oversight on every firewall engagement.

Common firewall migration mistakes

These 5 failure modes account for most of the migrations that go wrong. Each one leaves the perimeter weaker than the device it replaced.

1. Migrating the rule base blind. Carry-forward without an audit perpetuates years of NAT exceptions, shadow rules and stray VPN tunnels.
2. Skipping the parallel mirrored phase. Vendor conversion tools report clean configs that still fail under live TLS-decrypt load.
3. No tested rollback path. An untested rollback at 2 a.m. extends the outage instead of ending it.
4. Stopping monitoring at T plus 1 hour. Application-layer regressions surface across two weeks, not one hour.
5. Leaving the legacy device live. Active admin accounts on a retired appliance are an audit finding waiting to happen.

Firewall migration: frequently asked questions

How long does a firewall migration plan take for a Canadian SMB?

A single-site Canadian SMB with 15 to 200+ users should budget 5 to 7 weeks end to end, covering inventory, audit, platform pick, lab cutover, production cutover and a 14-day stabilisation period. PCI-DSS or PIPEDA evidence work adds 2 to 4 weeks.

What is the most common cause of a failed firewall cutover?

Migrating the rule base blind. Years of NAT exceptions, legacy ACLs, undocumented VPN tunnels and shadow rules carry forward without anyone confirming what each entry does. The new firewall then either blocks legitimate traffic or perpetuates a policy that fails a PIPEDA or PCI-DSS audit.

Can a firewall migration plan deliver zero downtime?

Low-downtime cutovers depend on a 24-hour parallel mirrored test, a tested HA failover path, and a rollback path with a 15-minute return target. With all three, most cutovers complete inside a 4-hour window with under 60 seconds of routing convergence. Without them, plan a maintenance window.

Should the destination platform be Fortinet, Palo Alto or Cisco?

FortiGate fits sub-100-seat single-site SMBs needing native SD-WAN and Canadian log residency on one license bundle. Palo Alto suits multi-site environments with PCI-DSS or PIPEDA evidence load. Cisco Secure Firewall fits Cisco-standardised sites. Cloud-native firewalls fit cloud-first workloads.

How does the firewall migration plan support PIPEDA?

PIPEDA requires safeguards appropriate to the sensitivity of the information held. The plan produces the evidence: identity-aware logs, 12-month log retention in a Canadian region, and documented change control on every rule modification. A migration is the right moment to retire retention shortcuts an OPC investigation would expose.

What goes into the rule audit step?

The audit pulls 30 days of hit counts, removes zero-hit and shadowed rules, and gives every survivor a business owner, ticket reference and written justification. Tufin, FireMon, AlgoSec, FortiGate Hit Count and Palo Alto Policy Optimizer all extract the data.

How much should a Canadian SMB budget for a managed firewall program?

Budget in four parts: the appliance amortised over 5 years, vendor support at 15 to 20 percent of appliance cost per year, a fixed-fee migration project, and the ongoing managed line. Fusion Computing prices managed cybersecurity from CA$180 to CA$250+ per user per month.

How much of the rule base usually survives the audit?

Expect the rule count to fall by 30 to 50 percent. In our practice, 38 percent of ACL rules in firewalls older than five years are unused or shadowed. A rule base that barely shrinks usually means the hit-count capture was too short to cover month-end.

When does the legacy device get decommissioned?

The legacy device stays powered for 4 hours post-cutover as a hot rollback, then sits in monitored stand-by for 14 days. After the stabilisation review at T plus 14 days it is wiped, admin accounts are removed, and the disposal record joins the evidence pack.

Should we run a penetration test after the firewall migration?

Yes, within 30 days of the cutover. A new perimeter policy is one of four triggers for an out-of-cycle test, alongside a directory consolidation, a merger and a customer questionnaire. The test confirms the migrated ruleset still denies what the old one denied.

Can Fusion Computing run the migration if the appliance is already purchased?

Yes. A good share of our firewall projects start with hardware a client already bought. The plan still picks up at step 1, and step 3 becomes a licensing and sizing review instead of a platform selection. Nothing in the 7-step runbook depends on who supplied the box.

Does Fusion Computing handle Fortinet and Cisco migrations across Ontario and BC?

Yes. Fusion Computing is Canadian-owned since 2012 with offices in Toronto, Hamilton and Vancouver, and CISSP-led oversight on every engagement. The practice covers FortiGate, Palo Alto PA-series, and Cisco Secure Firewall, including FortiConverter and Cisco migration-tool projects with Canadian-region logging.

Run an external scan before and after the cutover window. The network vulnerability assessment guide sets out the 7-step methodology and the retest evidence an underwriter expects.

Related Resources

• Managed cybersecurity services for Canadian SMBs.
• Next-generation firewall types, compared.
• IT infrastructure security checklist.
• Network security testing to validate the new policy.
• Network penetration testing for the 30-day check.
• Managed IT services for firms without a network lead.