Network & Security Infrastructure Migration Services

The migrations we deliver

Why firewall migration deserves particular care

Firewall migration between vendors is the migration most likely to go wrong, because policy does not translate cleanly. Vendors differ in how they evaluate rule order, how they treat implicit behaviours, how application and user identity are expressed, and how NAT interacts with policy. A rule base that has been mechanically converted will frequently be either more permissive than the original — which is a security regression nobody notices — or more restrictive, which produces application failures that are blamed on the new platform.

There is also the question of what the rule base has accumulated. A firewall policy that has grown over eight years typically contains rules for decommissioned systems, rules nobody can explain, duplicated entries and objects referencing addresses that no longer exist. Migration is the natural point to rationalise this, using traffic-hit analysis to establish what is genuinely in use before deciding what carries forward.

Our approach is to translate deliberately rather than mechanically: convert, review against the traffic evidence, validate rule by rule for the critical flows, then cut over in stages with the old platform available for rollback until the new one has demonstrably handled a full business cycle.

How we run a migration

1. DiscoverCurrent-state documentation — configuration, policy, dependencies, traffic flows and the undocumented behaviours the environment has come to rely on.
2. DesignTarget-state design with an explicit mapping of how each element of the current configuration is represented on the new platform.
3. TranslateConfiguration and policy conversion with rationalisation, reviewed against traffic evidence rather than converted blindly.
4. StageNew platform built and tested out of band, with critical flows validated in a lab or pilot context before any production traffic depends on it.
5. Cut overPhased traffic migration in agreed windows, with the previous platform retained and reversible until confidence is established.
6. StabiliseHypercare period with elevated monitoring and rapid response, followed by decommissioning of the legacy platform once the new one has proved itself.

Frequently asked questions

Can you migrate firewall policies between vendors?

Yes. Vendor tooling can perform a mechanical conversion, but the output always requires review — the semantics of rule evaluation, NAT interaction and implicit behaviour differ enough between platforms that a converted rule base is a starting point rather than a finished policy. We treat migration as an opportunity to rationalise the rule base against actual traffic evidence rather than carrying forward years of accumulated cruft.

How long does a migration take?

A single-site firewall replacement is typically a few weeks from discovery to decommissioning of the old platform. A multi-site switching refresh or a data centre migration runs to months, driven mainly by how many maintenance windows the business will grant and how much change it can absorb concurrently. Discovery and design are usually the longest phases; the cutover itself is short by comparison.

What happens if the cutover fails?

The rollback position is maintained until the new platform has demonstrably handled a full business cycle. That means the legacy platform stays in place and reversible rather than being decommissioned at cutover. The decision point for rolling back is agreed before the window and made against defined criteria rather than in the moment.

Do you migrate to cloud-managed platforms?

Yes. Migrations from on-premises controller architectures to cloud-managed platforms are common, particularly in wireless. They carry their own considerations — WAN dependency, licensing model changes, and the operational shift from local control to vendor-managed release trains — which we set out during design so the decision is made with the trade-offs visible.

Can you migrate an estate you did not deploy?

Yes, and that is the normal case. Discovery exists precisely because we do not assume prior knowledge, and because the environment's undocumented behaviours are usually the ones that cause migration problems. We would rather spend time in discovery than encounter surprises during cutover.

Related services

• EOL / EOS Management
• Network & Security Lifecycle Management
• Core Network Design & Deployment
• Data Center Networking
• Request an Upgrade Assessment