NexusSec.Why migrations go wrong
Almost every failed firewall cutover we are called in to rescue has the same root cause: the old rule base was copied without understanding what it permitted. Either broad legacy rules were carried across, recreating the same weaknesses on new hardware, or rules were tightened without knowing which were load-bearing — and something critical broke at 9am on Monday.
A migration is the single best opportunity you will get to clean up years of accumulated policy. Wasting it by copying blindly is the most common mistake.
Our migration method
- Discovery. We analyse the existing configuration and actual traffic logs. Hit counts tell us which rules are genuinely used; logs reveal flows the rule base does not explain.
- Rationalisation. Before translating anything, we identify rules to drop, consolidate or tighten — with your input on business context.
- Design. Zones, interfaces, routing, HA, VPN topology and the new policy structure, designed around segmentation rather than replicating a flat legacy design.
- Build. The new firewall is configured, hardened and tested offline. Security features are enabled deliberately — IPS in blocking mode, TLS inspection where appropriate, logging configured.
- Parallel running. Where the topology allows, the new firewall runs alongside the old one, permitting validation with real traffic before it becomes authoritative.
- Pilot cutover. A limited group or segment moves first, so issues surface at small scale.
- Full cutover. Executed in an agreed maintenance window, with a documented and tested rollback path.
- Hypercare. We remain closely engaged for the following days, when subtle issues typically surface.
What we migrate between
| Common migrations | Typical driver |
|---|---|
| Legacy/EOL appliance to modern NGFW | End of support, no security updates |
| Sophos to Fortinet, or Fortinet to Sophos | Cost, SD-WAN requirements, endpoint alignment |
| To WatchGuard | Bundled security including MFA |
| Consumer router or ISP box to a proper firewall | Growth, compliance, first real security requirement |
| pfSense/OPNsense to commercial NGFW | Need for vendor support and threat intelligence |
| Hardware refresh, same vendor | Capacity, performance, warranty |
The dependencies people forget
Minimising downtime
Complete zero downtime is achievable in some topologies — particularly with HA pairs or where the new firewall can be introduced in parallel and traffic shifted gradually. In others, a short planned window is unavoidable and far preferable to an unplanned outage. We tell you honestly which applies to your environment during design, rather than promising zero downtime and improvising.
What you receive
- A documented, rationalised policy — with the reasoning recorded
- Updated network documentation reflecting reality
- Configuration backups and a tested rollback procedure
- Handover and training for your team
- Optional ongoing management and monitoring