Directory › Guides › Cisco ASA to FortiGate migration checklist

Cisco ASA to FortiGate Migration Checklist (2026): A Step-by-Step Plan for IT Leaders

Last reviewed: October 19, 2026 · Published October 19, 2026 · By RackGuide

Most Cisco ASA 5500-X firewalls are now past Cisco's end-of-support dates, so plenty of IT teams are planning a move to Fortinet FortiGate. The configuration conversion is the easy part. The work that decides whether cutover night goes smoothly is everything around it: cleaning up the rulebase, translating NAT and VPN designs that don't map one-to-one, and testing the traffic the old box allowed without anyone writing it down.

This checklist is written from the perspective of someone who has led Cisco ASA to FortiGate migrations as part of network and firewall refreshes. It's organized in the order the work actually happens.

Why ASA migrations are happening now

Cisco's own support pages list these lifecycle dates for the ASA 5500-X family:

• ASA 5525-X, 5545-X, and 5555-X: end of sale September 4, 2020, and end of support September 30, 2025, per Cisco's ASA 5500-X Series support page.
• ASA 5500-X with FirePOWER Services (including the 5508-X and 5516-X): end of sale August 2, 2021, and end of support August 31, 2026, per Cisco's ASA 5500-X with FirePOWER Services support page.

Past those dates, the hardware no longer gets support from Cisco. If an end-of-support ASA still sits at your perimeter, that's usually the trigger for a refresh, and it's a natural time to compare platforms. Cisco's current line is listed alongside FortiGate, Palo Alto Networks, and Sophos in RackGuide's Firewalls & Network Security category.

What changes between ASA and FortiGate

The two platforms think about traffic differently, and most migration surprises come from these differences rather than from the conversion tool.

The default-behavior row matters most. On an ASA, an inside interface without an ACL quietly lets users reach anything at a lower security level. Cisco's ASA access rules documentation calls this an implicit permit. A FortiGate has no equivalent, so every flow the ASA allowed implicitly needs an explicit policy, or it breaks at cutover.

Using FortiConverter

Fortinet's FortiConverter translates third-party configurations into FortiOS. According to Fortinet's supported conversions list, it handles Cisco ASA 7.x and later, including ACLs, address and service objects and groups, interfaces, static routes, local users and groups, RADIUS/TACACS+/LDAP servers, DHCP and DNS servers, IP pools, VPN, and NAT, which it outputs in central NAT mode.

Fortinet's Cisco conversion notes list the gaps you need to handle by hand:

• Identity NAT and NAT exemption aren't supported. Rules you built to exempt VPN traffic from NAT have to be rebuilt deliberately.
• Static NAT rules where the source and mapped IPs are the same aren't converted, on purpose, to keep the policy count down.
• Wildcard netmasks in access lists and object groups aren't supported.
• All management services are enabled on converted interfaces, because FortiGate requires an allowaccess setting that ASA doesn't have. Tighten these before the box goes anywhere near the internet.
• IPsec Phase 1 authentication has to be assigned per VPN, because FortiGate supports only pre-shared key and RSA signature methods.
• Cisco FTD: only the LINA (layer 4) policy converts; Snort IPS rules don't.

Fortinet also offers a managed FortiConverter Service. Its FAQ says third-party-to-FortiGate conversion is a paid add-on priced from $50 to $5,000 depending on the target model, that it's included in the FortiGuard Enterprise Protection Bundle, and that third-party conversions take an average of four to six business days after Fortinet has all the required information. The free conversion offer covers FortiGate-to-FortiGate upgrades only.

The migration checklist

1. Inventory every ASA and what it does. List each unit, its software version, failover pairs, contexts, interfaces and VLANs, site-to-site tunnels, remote-access VPN profiles, and anything else that terminates on it, such as DHCP relay, syslog, SNMP, and NTP.
2. Export a clean configuration. Fortinet's instructions are to run terminal length 0 and show running-config and save the output as plain text. Keep a dated copy as your rollback reference.
3. Clean up before you convert. Remove unused objects, disabled and shadowed rules, and ACL entries with zero hit counts over a meaningful period. Every dead rule you convert becomes a FortiGate policy someone has to understand later.
4. Document the implicit permits. For each interface without an inbound ACL, write down what traffic it currently passes to lower-security interfaces. Those flows need explicit FortiGate policies.
5. Design zones and interface mapping. Decide how ASA interfaces map to FortiGate ports, VLANs, and zones. Grouping interfaces into zones keeps the policy table readable.
6. Pick a NAT mode on purpose. FortiConverter's Cisco output uses central NAT. If your team prefers policy NAT, decide before conversion, not after.
7. Convert, then review line by line. Treat the converter output as a first draft. Check NAT, VPN, interface management access, object names with the "_conflict" suffix, and anything listed as unsupported.
8. Rebuild the remote-access VPN. Plan it as an IPsec design on FortiClient (see the VPN section), and test it with real users before cutover.
9. Coordinate site-to-site peers. Every partner, branch, and cloud tunnel needs matching Phase 1 and Phase 2 settings and the same peer IP. Schedule changes with the people on the other end.
10. Stage and test. Load the configuration on the FortiGate in a lab or off-hours staging network and test representative flows: user internet access, published servers, VPNs, DNS, authentication, and monitoring.
11. Plan cutover and rollback. Write the cutover steps, the test list, a go/no-go owner, and a rollback plan that puts the ASA back in path within your maintenance window. If the new firewall's MAC addresses differ, plan for upstream ARP caches (clear them or have your ISP contact ready).
12. Cut over and watch the deny logs. After cutover, review traffic the implicit deny is dropping. Most post-cutover tickets are a missing policy for something the ASA allowed implicitly.
13. Close it out. Update diagrams, runbooks, monitoring, and backups for the FortiGate. Then decommission the ASA, wipe its configuration, and retire its support contract.

Remote-access and site-to-site VPN

Remote access deserves its own workstream. Starting in FortiOS 7.6.3, Fortinet removed SSL VPN tunnel mode from all FortiGate models and replaced it with IPsec VPN, which can be configured to run over TCP port 443. If your ASA users connect over SSL today, the FortiGate design should be an IPsec dial-up VPN from the start.

Fortinet's SSL VPN to IPsec VPN migration guide generally recommends IKEv2, since it supports TCP port 443, and notes that FortiClient no longer supports IKEv1 starting with version 7.4.4. Plan the client rollout, your MFA and identity integration, split-tunnel settings, and user communication together.

For site-to-site tunnels, list every peer, its encryption and authentication settings, and its protected networks. The cutover goes fastest when each peer's owner knows the window and the exact settings ahead of time.

Common pitfalls

• Missing the implicit permits. The single most common cause of post-cutover tickets. Traffic the ASA allowed by security level needs an explicit FortiGate policy.
• Trusting converted management access. Converted interfaces come up with every management service enabled. Lock down allowaccess on internet-facing ports before cutover.
• Breaking VPNs through NAT. NAT exemption rules don't convert. If VPN traffic gets translated after cutover, tunnels come up but nothing passes.
• Converting the mess. Migrating years of unused rules and objects as-is carries the clutter forward onto a new platform. Clean up first.
• Treating remote access as a config item. Moving users to a new VPN client touches every remote worker. Pilot it before the firewall cutover.
• No rollback window. Keep the ASA racked, configured, and ready to swap back until the FortiGate has run cleanly through normal business traffic.