Firewall Migration or Policy Cleanup? Why Changing Both at Once Can Destroy Your Troubleshooting Baseline

Published: October 14, 2026 | Last Technically Reviewed: October 14, 2026

Quick Conclusion

Firewall migration, policy cleanup, and network redesign should be treated as separate engineering decisions, even when they belong to the same project or maintenance window. A successful migration does not require copying every legacy rule literally. It requires preserving approved business and security behavior, documenting intentional changes, and collecting enough baseline evidence to identify why a service behaves differently after cutover. Confirmed unused objects may be removed before migration; uncertain dependencies and major architectural changes require stronger evidence, explicit authorization, and appropriate testing.

Replacing a firewall, rewriting its policies, redesigning VLANs, changing NAT, and enabling new inspection features in the same maintenance window may produce a cleaner network. It can also make a subsequent application failure much harder to diagnose.

Consider what happens when all these variables change together:

New Firewall Vendor
       +
New Software Platform
       +
New Interface Mapping
       +
New NAT Behavior
       +
Rewritten Security Policies
       +
New VLAN Segmentation
       +
New Inspection Profiles
       

Multiple Possible Causes for One Application Failure

If an ERP application stops connecting to its database the following morning, what actually caused the failure?

Was it an incorrect interface mapping? A missing route? NAT translation? A rewritten policy? A new segmentation boundary? TLS inspection? Or was the application already experiencing intermittent problems before the migration?

This is the practical problem raised in the June 21, 2026 r/networking discussion When migrating a client's firewall, do you copy the policies exactly as they are or make improvements too?.

The engineer was working on a customer migration from an older firewall, described in context as Sophos, to FortiGate. The project involved policies, address objects, IP addressing, VLANs, and a move from a flat network to a segmented architecture. Many existing rules appeared poorly organized, possibly unnecessary, or difficult to justify.

The replies revealed two legitimate but competing approaches. Some MSP engineers preferred preserving existing behavior first, then cleaning policies and implementing segmentation as controlled subsequent changes. Others argued that a properly scoped migration was an opportunity to remove accumulated legacy rules and rebuild a more maintainable policy structure.

Neither position is universally correct.

These are public practitioner experiences, not Network-Switch.com customer cases. Their value is in identifying the operational problem and showing that experienced engineers may choose different change sequences depending on the project's scope and available evidence.

Quick Answer: Do not confuse configuration translation with policy cleanup or security redesign. Before cutover, audit existing behavior and remove items only where sufficient evidence and authorization support the decision. Translate required traffic behavior into the new platform, record deliberate deviations, and verify both allowed and prohibited flows. Then perform broader cleanup, segmentation, and hardening in separate controlled phases-or within the same approved change plan when dependencies, testing, and rollback are sufficiently understood.

The objective is not literal 1:1 configuration. Different firewall platforms may implement NAT, policy objects, inspection, and interfaces differently.

The objective is functional equivalence, with intentional improvements clearly identified.

Firewall Migration and Firewall Redesign Are Two Different Changes

An old firewall configuration can be operationally functional and still contain years of unnecessary objects, unclear rule names, duplicated services, and overly broad permissions.

There are valid reasons to clean that up during a migration.

However, the risk changes when cleanup alters traffic behavior while migration changes the underlying security platform.

Consider the difference between removing an address object that is demonstrably unreferenced and rewriting an established application policy because it appears too permissive.

The first may have no operational effect. The second can change which sessions are accepted, inspected, translated, or rejected.

That distinction explains why the community discussion produced different recommendations.

Some engineers favored separating migration, cleanup, and segmentation into successive changes. Others described reviewing hit counters and rebuilding policy groups during the migration itself to avoid carrying forward a large collection of poorly maintained rules.

Fortinet's FortiOS 7.6 migration best practices provide an important third perspective. They recommend auditing the existing configuration, removing unused objects or policies, analyzing traffic flows, mapping the old firewall to the new platform, and preparing an acceptance test plan for cutover.

Fortinet also recommends mapping physical ports between the old and new devices, having representatives from affected business functions participate in testing, considering a limited-user cutover where feasible, and preparing a backup plan.

Therefore, "always migrate first and clean later" is not a universal vendor recommendation.

The better distinction is between evidence-based cleanup and speculative redesign.

Translation vs Cleanup vs Redesign

A migration project can include all these activities. They should not be treated as one technical operation.

Evidence-based cleanup means the team can explain why an object is no longer required and demonstrate that removing it should not change approved behavior.

Speculative redesign means changing traffic behavior because the existing configuration looks untidy, without sufficient knowledge of the applications and dependencies it supports.

The problem is not cleanup itself.

That is the central difference between a controlled modernization project and an untraceable collection of simultaneous modifications.

"Migrate 1:1" Should Mean Functional Equivalence, Not Literal Copying

A literal line-for-line migration between firewall vendors is frequently unrealistic.

Different platforms can implement the same business requirement using different combinations of interfaces, zones, objects, NAT rules, security profiles, authentication controls, and policy evaluation logic.

An old policy numbered 37 does not necessarily need to become policy 37 on the new device.

What matters is the resulting network behavior.

Three Different Types of Equivalence

1. Literal configuration equivalence

Configuration structures, commands, rule numbers, and objects appear identical.

This is rarely an appropriate cross-vendor acceptance criterion.

2. Functional equivalence

Required business traffic continues to work, prohibited traffic remains blocked, and expected routing, NAT, VPN, and inspection behavior is maintained.

This is generally the more useful migration objective.

3. Intentional improvement

The new environment deliberately behaves differently because the business has approved a security or architecture change.

That improvement needs an owner, technical rationale, test criteria, and recovery plan.

The migration target should therefore be:

What a Conversion Tool Can-and Cannot-Establish

Fortinet describes FortiConverter's general limitations particularly clearly. It is a migration tool rather than a complete migration service. Fortinet states that its output requires review and auditing, while its tuning capabilities are not intended for significant configuration redesign.

This is a useful boundary.

A tool may translate a supported address group or policy object correctly without knowing whether the related application is still required.

It may convert syntax without reproducing every security behavior.

And it cannot authorize the deletion of a business-critical access path merely because that path appears old or rarely used.

Sophos-to-FortiGate migration demonstrates why feature-level review matters. The Sophos conversion reference for FortiConverter 7.4.0 lists support for several object types, including interfaces, zones, addresses, services, users, and policies. However, the same documentation also identifies limitations involving VPNs, routing, and NAT conversion.

The page contains an internal inconsistency: it lists routes among supported objects while also stating that route conversion is not currently supported. That ambiguity should be resolved against the exact source platform, converter release, and target FortiOS version before a project commits to automated conversion.

Do not assume that a successful object-conversion process means every source NAT rule, VPN configuration, or route has been reproduced correctly.

FortiConverter also provides reports for supported third-party conversions, including Sophos. These reports can help identify conversion outcomes, but their definitions must be read carefully.

In the documented reporting feature, the Unconverted Report lists objects excluded through the unreferenced-object discard feature. It should not be treated as a comprehensive list of every unsupported source feature.

The engineering conclusion is:

Build the Baseline Before You Decide What to Remove

A configuration backup is necessary, but it is not a sufficient troubleshooting baseline.

If an application fails after cutover, the team needs to know what its previous traffic path looked like-not merely which rules existed in the old configuration export.

A useful migration baseline has several layers.

Migration Baseline Checklist

The checklist should be adapted to the environment.

A branch firewall with static routes and one site-to-site tunnel needs a different baseline from a data-center security gateway with multiple routing adjacencies and published applications.

Use the Source Firewall's Available Evidence

Sophos Firewall 22.0 provides several useful sources of pre-migration information.

Its Log Viewer documentation describes event filtering, detailed log inspection, and CSV export.

However, logging is not necessarily complete. The documentation identifies circumstances in which sessions are not logged, including connections closed without the firewall receiving the expected session-destroy event.

This matters when interpreting an apparent absence of traffic.

A missing log entry does not automatically prove the corresponding connection never existed.

Where necessary, combine logs with application-side evidence, session inspection, traffic observation, and business-owner confirmation.

Version and Platform Boundary

The Log Viewer and Active firewall rule statistics discussed in this article refer specifically to Sophos Firewall 22.0.

The source device in the public MSP discussion was described as an older firewall, but its exact software version and source-platform type were not established.

Older SFOS releases, Sophos SG/UTM, and other source platforms may expose different logging controls, usage statistics, and configuration structures.

Therefore, do not assume the legacy device provides Sophos Firewall 22.0's interface features, reporting windows, or policy statistics.

Verify the actual source platform and software version before defining the migration baseline or selecting a conversion method.

The Known-Broken Baseline

One of the most easily overlooked migration records is the list of functions that already do not work.

The goal is not to defend those problems.

It is to prevent incorrectly attributing every post-cutover failure to the replacement firewall.

Consider this illustrative baseline:

Illustrative planning records-not actual customer test results.

Suppose someone reports the following morning:

Without a known-broken baseline, the team may spend hours investigating a service that was not functioning before the cutover.

That creates an attribution problem rather than necessarily a new technical problem.

A strong baseline therefore records what works, what is blocked by design, what is intermittently degraded, and what is already broken.

A migration should not be declared unsuccessful merely because an explicitly documented pre-existing fault remains. Conversely, that exception should not be used to ignore new failures introduced by the change.

Baseline Differential

Once the new firewall is live, compare the important before-and-after states:

BEFORE MIGRATION

ERP reaches database
VPN A established
Guest  Management blocked
NAT publication behaves as documented
Expected routes present
Known faults recorded

             

AFTER CUTOVER

Compare the same conditions

             

EQUIVALENT
      /
APPROVED DIFFERENCE
      /
UNEXPLAINED REGRESSION

A difference is not always a defect.

But every meaningful difference should be classifiable.

A Zero-Hit Rule Is Evidence-not Proof That the Rule Is Obsolete

A zero-hit firewall policy is a legitimate cleanup candidate.

It is not automatically safe to delete.

The observation may mean that the rule is no longer needed.

It may also mean that the observation period did not include the relevant workload.

Examples include quarterly reporting, annual financial processing, scheduled maintenance, disaster-recovery activation, emergency vendor access, or failover-only traffic.

What Do Policy Counters Actually Tell You?

Sophos Firewall 22.0's Active firewall rules widget shows recent policy usage information.

Its Unused status identifies rules whose criteria did not match traffic during the preceding 12 hours at the usage check. The documentation also explains that rule statuses are maintained for 24 hours and checked daily.

That is useful operational visibility.

It is not an application-lifecycle inventory.

FortiOS also provides policy usage statistics. For example, the seven-day rolling counter documented for FortiOS 7.6.6 maintains daily counters for the previous seven days and the current day.

The feature is documented for firewall and multicast policies, not every security-policy category.

That additional history improves usage analysis.

It does not establish whether a rule will be needed next month or during a disaster-recovery event.

One participant in the June community discussion suggested observing counters for 30 days before reviewing zero-hit policies with the customer.

That is an individual operating approach-not a universal safe observation period.

Quarterly, annual, or emergency dependencies can fall outside it.

Policy Evidence Matrix

No single column determines deletion.

A stronger decision combines usage evidence, ownership, application dependencies, technical testing, and explicit change approval.

For example, a zero-hit vendor rule with an unknown owner should normally be treated differently from a rule whose owner has confirmed that the vendor contract ended and whose related systems have been decommissioned.

Clean It Now or Defer It?

This matrix is an editorial engineering framework, not a Fortinet or Sophos vendor policy.

The central distinction is:

How Many Variables Should Change During One Firewall Cutover?

A migration may need to change more than the firewall vendor.

Replacing an end-of-life device may require new interface mappings. Moving a Layer 3 gateway can affect routing. Segmenting a previously flat network necessarily changes how some traffic crosses security boundaries.

The goal is not to forbid multiple changes.

The goal is to preserve enough evidence to diagnose each one.

The Change-Variable Budget

Consider this conceptual stack:

Firewall Vendor
      +
Software Platform
      +
Interface Mapping
      +
Routing
      +
NAT
      +
Security Policies
      +
VLAN Segmentation
      +
Inspection Profiles
      +
Authentication
      
Diagnostic Complexity

This is not a numerical formula.

It is a way to ask whether the project has enough documentation, ownership, testing, and recovery capability for the number of behavior-changing variables being introduced.

A small, well-documented environment may support firewall replacement and segmentation during one planned cutover.

A network with hundreds of poorly understood policies, undocumented applications, multiple VPNs, extensive NAT, and a narrow maintenance window presents a different risk.

When Can Segmentation Happen During Migration?

Combining changes becomes more defensible when business flows are mapped, the customer explicitly authorizes the new security boundaries, testing covers representative applications and prohibited traffic, and rollback is feasible.

Separating the changes becomes more valuable when application owners cannot describe their dependencies, logs are incomplete, or multiple unknown legacy policies might be carrying production traffic.

The principle is not:

It is:

Critical Security Exceptions

Preserving existing behavior must not become a blanket justification for carrying forward a clearly unacceptable security exposure.

Suppose the old firewall contains an unauthorized publicly reachable management service, a confirmed compromised access path, or a rule exposing a known critical vulnerability.

Mechanically preserving it would be the wrong interpretation of functional equivalence.

Such findings need a separate exception process:

1. Record the existing state and evidence.

2. Establish the severity and business impact.

3. Identify an authorized decision-maker.

4. Define the intended behavioral deviation.

5. Test both expected access and expected denial.

6. Document approval, implementation, and recovery options.

For an actively exploited exposure, urgent containment may be required under the organization's incident-response procedures rather than waiting for an ordinary migration schedule.

The Statement of Work Is Also a Change Boundary

For MSPs and systems integrators, an engineering improvement can still be an unauthorized change.

If the agreed scope covers replacement and migration but not a complete security redesign, broad policy hardening should not be silently included without authorization.

The same public MSP discussion included practitioners explicitly distinguishing migration scope from security assessment or redesign work.

This affects operational responsibility as well as commercial scope: who approves changed access, who accepts the risk, who signs off on the result, and who owns rollback.

Preserve the Rollback Point

When hardware migration, VLAN reassignment, policy cleanup, and NAT redesign happen simultaneously, rollback can become ambiguous.

Does rollback mean restoring the previous firewall, previous rules, old VLAN gateways, original public-IP mapping, or all of them?

A rollback plan needs a clearly defined last-known-good architecture.

A rollback is a planned recovery procedure-not an assumption that reconnecting the old device will always restore everything.

Positive and Negative Tests Define Whether the Migration Worked

A migration is not validated merely because a browser opens a public website.

That test proves one permitted path works.

It does not verify routing, NAT, VPNs, published applications, authentication, segmentation, or prohibited access.

Positive Acceptance Testing

Positive tests establish that required traffic still succeeds.

Examples include employee Internet access, ERP-to-database traffic, DNS, email delivery, published HTTPS services, site-to-site VPNs, and remote-access authentication.

Negative Acceptance Testing

Negative tests establish that access intended to be prohibited remains blocked.

Examples include guest access to management subnets, Internet access to internal administrative services, unapproved user-to-server connections, and unauthorized inter-VLAN traffic.

Negative testing should also cover newly approved restrictions where the redesign intentionally strengthens access controls.

The same Fortinet migration guidance discussed earlier specifically calls for an acceptance test plan during the cutover window, participation from affected business functions, and a backup plan.

Migration Acceptance Matrix

Illustrative planning template-not real customer test results.

A result should be recorded with the testing source, destination, application, expected outcome, observed outcome, and responsible reviewer.

A successful ping does not substitute for application testing when the business requirement involves authentication, application-layer communication, or session persistence.

The Old-to-New Policy Translation Ledger

Rule-number equivalence is often meaningless across vendors.

The useful comparison is the original rule's purpose and the resulting behavior of its replacement.

Illustrative ledger only. Rule numbers, owners, and outcomes are examples.

Add references to NAT dependencies, interface mappings, security profiles, exceptions, and change approvals where needed.

The ledger should allow an engineer to answer:

That question is substantially more useful than comparing policy counts between two vendors.

Test Intentional Deviations Separately

If the new firewall deliberately blocks a previously allowed application flow, that result may be correct.

But the test record must classify it as an authorized change rather than mistakenly reporting it as a migration defect.

Likewise, if a service that previously worked suddenly fails without an approved behavioral change, it is a regression requiring investigation.

The acceptance framework therefore needs three possible classifications:

• Equivalent: Approved behavior remains unchanged.

• Approved Difference: Behavior changed intentionally, with authorization and tests.

• Unexplained Regression: Actual behavior differs from the approved baseline without an accepted reason.

This prevents the team from treating every difference as failure while also preventing unexpected changes from disappearing inside a broad "migration passed" status.

Stabilize the Migration, Then Make Security Improvements Deliberately

A firewall migration is not finished simply because the replacement appliance has been online for a predetermined number of minutes.

Completion should be based on expected network behavior, acceptance criteria, known exceptions, and the business's ability to operate normally.

Preserve Causality During Firewall Migration

OLD FIREWALL
      
Capture Configuration and
Functional Baseline
      
Audit Policies and Dependencies
      
Translate / Rebuild
      
Document Intentional Deviations
      
CUTOVER
      
Positive + Negative Testing
      
Functional Baseline Achieved?
      
       NO
          
        Diagnose / Recover / Roll Back
      
       YES
           
        Stabilize
           
        Baseline Sign-Off
           
        Policy Cleanup
           
        Segmentation / Hardening
           
        Post-Change Validation

The ordering represents logical control phases, not a mandatory number of separate maintenance windows.

Some projects can combine phases after appropriate review and testing. Others need independent change windows because their failure risks and rollback requirements differ.

What Does Stabilization Actually Mean?

Stabilization should provide evidence that key business flows are functioning and that no unexplained operational regressions remain.

That may include reviewing application-owner feedback, VPN status, policy logs, interface utilization, routing state, authentication, and any migration exceptions.

The duration should reflect the business's operating cycle.

A system used only during monthly accounting, for example, may not be fully validated by one ordinary business day.

Once the approved functional baseline is signed off, broader cleanup can proceed against a known reference.

That is when improvements become easier to evaluate.

If a later segmentation change breaks the ERP connection, the team can compare against the already functioning new firewall rather than simultaneously questioning whether the vendor migration itself was correct.

A Practical Decision Framework

Before combining cleanup or redesign with cutover, ask:

Is the change required for migration compatibility?

If yes, document and test it as part of translation.

Is the object demonstrably unused?

If yes, consider evidence-based cleanup with approval.

Does the change deliberately alter access or inspection behavior?

Treat it as an intentional security change with separate acceptance criteria.

Are application dependencies uncertain?

Preserve behavior where safely possible, record the uncertainty, and defer broader redesign.

Is there a critical security exposure?

Use the controlled exception or incident-response process rather than mechanically carrying it forward.

Can the team clearly reverse the change?

If not, reconsider the migration scope, sequence, and recovery strategy.

Before a firewall refresh, review the target appliance, interface mapping, HA architecture, routing, NAT, VPNs, VLANs, security policies, and application dependencies together.

Network-Switch's Business Network Readiness & Modernization provides a starting point for reviewing network segmentation, hardware lifecycle, compatibility, and project requirements before equipment procurement or network changes.

Related technical analysis is available in the Engineer Lab.

The central point is not that security improvement must always wait until after migration.

It is that every behavior-changing decision must remain attributable.

Three principles summarize the approach:

Current Official Sources