Migrating from a Legacy Firewall to FortiGate: A Step-by-Step Plan

Firewall migration is the planned transfer of rules, NAT definitions, VPN tunnels and objects from an existing firewall to a new FortiGate. A successful migration moves through eight stages: inventory, rule analysis, target design, FortiConverter or manual conversion, parallel run, cutover window, rollback plan and validation. This guide covers each stage with its deliverable and typical duration.

Why Should a Firewall Migration Be Planned as a Separate Project?

Firewall migration deserves its own project plan because the firewall is the single gate between the company and the internet, its branches, its VPN users and its servers. Plugging in the cable and pasting the configuration carries years of accumulated rule errors and undocumented dependencies onto the new device, and the outage shows up during business hours.

In our field experience, most migration projects run into trouble for three reasons. First, the old device holds rules nobody can explain, and they are copied as-is "so nothing breaks". Second, the dependencies of systems such as the ERP, point-of-sale integrations or the CCTV recording server on the firewall are not documented; everything works on cutover night and accounting cannot work the next morning. Third, the rollback plan consists of the sentence "we will plug the old box back in", and nobody has timed how long that actually takes.

That is why we split the migration into stages that each produce a concrete deliverable. The table below shows the typical durations we see in projects for a single-site SMB; multi-branch environments or organizations publishing many services take longer.

Inventory and Rule Analysis: What Actually Needs to Move?

The inventory puts every configuration item on the old firewall, and every business system that depends on it, into writing; rule analysis then filters out which rules actually see traffic and which are shadowed or duplicated. What moves to the FortiGate is not the entire existing configuration but the clean subset that survives this analysis.

Looking at the rule base alone is not enough. Our inventory checklist covers:

• Interfaces and VLANs: physical ports, subinterfaces, IP addresses, MTU and management access settings.
• Routing: static routes, default gateway, multiple WAN links and policy-based routing.
• NAT: source NAT, destination NAT / port forwarding (VIPs in FortiOS) and the owner of every published service.
• Objects: address, address group, service, schedule and FQDN objects.
• VPN: site-to-site IPsec tunnels, remote access profiles, pre-shared keys and certificates.
• Authentication: LDAP/Active Directory, RADIUS, local users and groups.
• Services: DHCP scopes, DNS forwarding, NTP, SNMP and syslog targets.
• Security profiles: IPS, antivirus, web filtering and application control profiles, and which rules they are attached to.

The dependency map is the most frequently skipped part of the inventory. For every published service and every VPN tunnel, write down the answer to "which department stops working if this goes down?". That list becomes the source of the cutover test matrix and of the rollback triggers.

In rule analysis we look for three classes of problems: unused rules that never produce a hit count, shadowed rules that never fire because an earlier rule catches their traffic, and duplicate rules whose removal changes nothing. Add "any-any" permits and test rules that were opened temporarily and forgotten. In its FortiOS 7.6 best practices, Fortinet recommends removing unused objects and policies before migration and assessing traffic flow to decide whether existing policies can be combined (Fortinet Document Library, Migration). We describe the method in detail in our article on firewall rule cleanup and policy auditing; for the FortiOS side of rule logic, our FortiGate policy management guide is a good starting point.

IT should not make cleanup decisions alone. A rule with a zero hit count may belong to a fiscal year-end transfer that runs once a year. The removal list is therefore shared with business units, and disputed rules are carried over to the new device as "disabled" and monitored.

Target Design: Model, Interface Map and Segmentation

Target design decides in advance how the cleaned rule set will sit on the new FortiGate: which model, which physical port replaces which old port, which VLANs belong to which security zone and which security profiles are attached to which rules. Conversion does not start until the design is finished.

Model selection follows the characteristics of the target traffic, not the size of the current box. If IPS, SSL inspection or web filtering was off on the old device and will be switched on, size against the throughput values measured with security profiles enabled rather than the headline firewall throughput on the datasheet. We compare the SMB options in our FortiGate 40F, 60F, 70G and 90G comparison, and the overall decision framework is in our SMB firewall selection guide. The full product family is listed on our FortiGate solutions page.

The interface map is a simple but critical document, also emphasized in Fortinet's migration best practices: port1 on the old device may correspond to port2 on the new one, and besides WAN and LAN, the management port, HA link and DMZ ports belong in the table.

Migration is the best moment to rethink segmentation. In flat-LAN environments, moving users, servers, guest Wi-Fi, printers and IoT/camera networks into separate VLANs and zones makes the rule base easier to read and more resilient against ransomware. We do, however, recommend not changing segmentation and the firewall on the same night: migrate with the existing segmentation first, then introduce the new zones gradually.

The design should also record these decisions: whether high availability is required, with a second unit and a FortiGate HA configuration; the remote access method (if the target release is FortiOS 7.6, the removal of SSL VPN and the move to IPsec/ZTNA must be part of the design); the log destination (local disk, syslog or FortiAnalyzer); and management access restrictions.

FortiConverter or Manual Conversion?

FortiConverter is Fortinet's tool for translating third-party firewall configurations into FortiOS format; with a large rule base and a supported source vendor it shortens conversion time considerably. Manual conversion gives a cleaner result for small rule sets, unsupported sources or projects where the design changes from scratch. Either way, the output is reviewed line by line.

According to Fortinet's product page, FortiConverter supports a broad list of sources including Cisco, Cisco Meraki, Check Point, Palo Alto Networks, Juniper, Forcepoint, SonicWall, Sophos, WatchGuard, Barracuda, Huawei and MikroTik, and migrates interface configuration, firewall policies, NAT rules, address objects and static routes to FortiOS (Fortinet FortiConverter). Fortinet's documentation also notes that some parts of a configuration may not translate because of dependencies or unsupported syntax and must be converted manually. Check current Fortinet documentation for supported target releases and the licensing model.

In our projects the tool adds the most value on address and service objects and long rule bases; the areas that need the most manual work are VPN tunnels, authentication integration, security profiles and vendor-specific features of the source platform.

If the source device is already a FortiGate (for example, an end-of-life model being replaced by a new 70G or 90G), Fortinet still recommends FortiConverter; without a license, it documents editing the configuration file, loading it onto the new unit and reviewing the error log after reboot with diagnose debug config-error-log read (Fortinet, Migrating a FortiGate configuration manually).

Whichever method you choose, load the conversion output onto the device in the parallel test environment first, never straight into production. For the initial configuration steps during installation, our FortiGate installation and initial configuration guide is a useful companion.

Parallel Run and Test Matrix

A parallel run validates the new FortiGate by operating it alongside the old firewall with part of the real traffic or a copy of it. The goal is to push the number of surprises first seen on cutover night close to zero. The test matrix is generated from the dependency map in the inventory, and each row is closed with a business unit's sign-off.

In practice we use three levels of parallel run. First, the new device is set up on a separate test VLAN with a temporary WAN link, and a pilot user group reaches the internet through it. Second, published services are tested through the new device on a temporary second public IP. Third, site-to-site VPNs are brought up from the new device using a second tunnel definition on the remote end.

The test matrix includes at least the following:

• Internet access, DNS resolution and web filtering behavior from every user VLAN.
• External access to every published service (VIP / port forwarding) and correct source IP restrictions.
• Site-to-site VPN tunnels coming up, matching phase 1 and phase 2 parameters and branch applications working.
• Remote access: authentication, group-based authorization and split tunnel behavior.
• LDAP/Active Directory and RADIUS integration; user-based rules matching correctly.
• DHCP, NTP, SNMP and log forwarding; logs arriving at FortiAnalyzer or syslog.
• Management access restrictions and multi-factor authentication for administrator accounts.
• If HA is planned, sessions surviving a member failover.

FortiOS policy lookup and packet capture tools answer the question "which rule will this packet hit?" before cutover. Test results feed back into the configuration, and migrated rules whose hit count is still zero are questioned once more at this stage.

How Do You Run the Cutover Window?

The cutover window is the planned maintenance interval in which production traffic moves from the old firewall to the new FortiGate. A successful window is run with a written step-by-step method of procedure (MOP), verified backups taken in advance, time-boxed go/no-go checkpoints and a single decision maker. It opens when business impact is lowest, and its length is based on timings measured in the parallel tests.

Before the window opens, these preconditions must be met:

1. Full configuration backups of both the old and the new device are taken, and a restore from backup has been tested once.
2. Business units have been told in writing about the outage time and duration; contacts are named for branches and for external suppliers on the far end of VPN tunnels.
3. ISP-side issues are clarified: static IPs, MAC-bound contracts and the ARP cache on modems/routers; if the public IP changes, DNS TTL values have been lowered in advance.
4. Cabling is labeled and a printed copy of the interface map is on the desk.
5. The rollback plan is written, with its triggers and decision maker defined.

The procedure itself is short and sequential: final backup on the old device, move the WAN cable to the new device, move the LAN/VLAN uplinks, check interface and routing status on the new device, test published services from an external point, bring up the VPN tunnels and run the critical rows of the test matrix. Each step lists its expected result and estimated duration.

We set go/no-go checkpoints on the clock: for example, basic connectivity and NAT at minute 30 of the window, VPN and authentication at minute 60, business applications at minute 90. If a checkpoint is not passed on time, the decision maker starts the rollback.

Rollback Plan and Post-Migration Validation

A rollback plan is the written procedure for returning production to the old firewall within a known time if cutover fails; its triggers, decision maker and step order are defined in advance. Post-migration validation proves, through 24-hour, one-week and 30-day checklists, that the new FortiGate carries every business process in full.

Rollback triggers must be concrete: "critical application X is unreachable at the checkpoint", "the branch VPN has not come up within the agreed time", "the published service does not respond from outside". When a trigger fires, the decision maker does not open a debate but starts the procedure. The procedure is written in reverse order: disconnect the new device, power on the old one, check interfaces and routing, re-establish the VPNs and run a short validation. Rehearsing this sequence at least once during the parallel run keeps the plan from staying on paper.

In our projects the old device stays cabled but powered off for two to four weeks; it is not removed until low-frequency processes such as month-end close, payroll or periodic reporting have run through that window.

Validation happens in three waves:

Once validation is complete, the configuration is backed up as the baseline, a change procedure is applied to the rule base and a regular audit schedule is set. For organizations that cannot sustain this operation with their own team, our article on managed firewall services explains the scope and decision criteria.

Frequently Asked Questions

How long does a firewall migration take?

For a single-site SMB, the project typically takes four to eight weeks from inventory to the end of validation, while the cutover window itself is usually two to four hours. The number of branches, published services and the size of the rule base directly determine the timeline.

Does FortiConverter convert every firewall brand?

No. According to Fortinet's product page, a broad list is supported, including Cisco, Check Point, Palo Alto Networks, Juniper, SonicWall, Sophos, WatchGuard, Forcepoint, Barracuda, Huawei and MikroTik; confirm your source vendor and version in current Fortinet documentation. Unsupported sources are converted manually.

Why is it risky to move old rules as they are?

Unused, shadowed and duplicate rules, along with temporary permits nobody closed, arrive on the new device unchanged. The attack surface does not shrink, the rule base stays unreadable and the new security profiles are layered on top of old, flawed rules. Migration is the cheapest moment to clean up.

Will there be an internet outage during migration?

A short outage during the cutover window is unavoidable; with a migration prepared through a parallel run, it is limited to moving cables and re-establishing tunnels. The window opens when business impact is lowest and is announced to business units in advance.

When should we switch off the old firewall?

It is switched off at the end of cutover but not removed. In our projects it stays cabled and ready for rollback for two to four weeks, until low-frequency processes such as month-end close have run without issues; its configuration backup is kept indefinitely.

Is FortiConverter needed when moving from one FortiGate to a newer FortiGate?

It is not mandatory. Fortinet recommends FortiConverter here too; without a license, it documents editing the configuration file, loading it onto the new unit and checking the error log. Port names and release differences are the main risks; rule cleanup and validation still apply.

Conclusion

Moving from a legacy firewall to FortiGate is less a hardware swap than a project that revisits the rule base and business dependencies. Inventory and rule analysis decide what moves, target design decides where it goes, and FortiConverter or manual conversion decides how it gets there. The parallel run catches surprises before cutover, a written rollback plan removes decision pressure on the night, and 30 days of validation prove the work is really done.

As an independent solution partner, Sora Yazılım provides FortiGate procurement, migration planning, installation and ongoing managed services. If you would like to map your current firewall together and receive a proposal for the migration plan, you can request a free discovery call.