Firewall migration · Fortinet partner
Every firewall migration tool will translate your objects and rules into the new vendor’s syntax, and most of them do it well. What no tool will do is tell you that four hundred of those rules have not passed a packet since 2021, or that the one everybody is afraid to touch is the one carrying your payment integration. That judgement is the job.
Cisco ASA · Firepower · Sophos XG · Check Point · Palo Alto · SonicWall · Juniper SRX
The method
How we run a migration
The shape below exists for one reason: it keeps a working position available at every point, so that a bad discovery on cutover night is an inconvenience rather than an outage.
The rollback position is held until the new estate has survived a full business cycle.
Collect the real configuration, not the documented one
We work from the running config and a log sample. The documented policy and the running policy diverged years ago on most estates, and migrating the documentation produces a firewall that blocks production traffic on day one.
Convert, then argue about what survives
Automated conversion gives a baseline in hours. The valuable part is the review that follows: every shadowed, zero-hit and any-any rule is a candidate for retirement, and a migration is the cheapest moment you will ever get to retire one.
Run both estates in parallel
The new firewall sees production traffic and logs what it would have done, while the old one is still deciding. Discrepancies surface as log entries instead of as incidents. This is the stage most migrations skip and most failed migrations needed.
Cut over with the rollback still available
Cutover is a scheduled change with a tested reverse. We keep the old estate recoverable until the new one has been through a month-end, a payroll run, a backup window and whatever else your calendar considers load.
The real costs
What a migration is really costing you
Migration quotes tend to compare licence and hardware prices, which are the two numbers easiest to obtain and the two least likely to determine the outcome. The costs that actually bite are below.
| Cost | Where it hides | How we handle it |
|---|---|---|
| Carried-over cruft | Every dead rule you convert is a rule you pay to translate, test, document and then live with for another five years. | Audit-first scoping so the conversion set is smaller than the source |
| Undocumented dependencies | The rule with no ticket, no owner and no comment that turns out to be load-bearing. | Parallel run surfaces it as a log line, not an outage |
| Subscription ownership | Entitlements registered in someone else’s account do not travel with the hardware. | Checked before cutover, not after |
| The rollback you did not keep | Decommissioning the old estate on cutover night saves a week of rack space and costs you every option you had. | Old estate stays recoverable through a full business cycle |
Scroll the table sideways on a narrow screen.
If the rule base turns out to be beyond salvage, that is a legitimate finding and it changes the plan: a clean policy rebuild against documented requirements is sometimes cheaper than converting a decade of exceptions. We would rather tell you that at scoping than halfway through.
Questions
Firewall migration, answered
Can you migrate a Cisco ASA rule base to FortiGate?
Yes, and it is the migration we are asked for most often. Automated conversion handles the mechanical translation of objects and rules; the work that decides whether the cutover goes well is what happens after that — deciding which rules deserve to survive, and proving the converted policy behaves the same way before anyone depends on it.
Do you migrate from Sophos or Check Point too?
Yes. Sophos XG, Check Point, Palo Alto, SonicWall and Juniper SRX all convert to FortiGate, and we also migrate between generations of the same vendor. The source platform changes the tooling; it does not change the method.
Will there be downtime?
There is a cutover, so there is a window — but it is planned, short, and it is not the risky part. The risky part is discovering three days later that a rule nobody documented was carrying a payment integration. That is why we run both estates in parallel before cutting over, and hold the rollback position until the new one has survived a full business cycle.
Should we migrate the rules as they are, or clean them up first?
Cleaning up first is almost always cheaper, because you are paying to convert, test and then live with every rule you carry across. A migration is the one moment when removing a rule has an obvious owner and an obvious window. A firewall audit before the migration usually pays for itself in reduced conversion scope.
What happens to our existing subscriptions and support?
That depends on whose account they sit in, and it is worth checking before the migration rather than after. Subscriptions registered against a serial number in a provider’s account do not follow you. We cover this in licence and subscription renewal.
How long does a firewall migration take?
A single-site migration with a moderate rule base is usually a few weeks end to end, most of which is parallel running rather than engineering. Multi-site estates are scheduled site by site. We would rather quote a date after reading the config than before.
Next step
Send us the config, not the user count
A sanitised export from the source firewall tells us more in ten minutes than a requirements call does in an hour. We will come back with a scope, a sequence and an honest view of what should not come across.