Migration Considerations from ASA to Secure Firewall (FTD)

If you are managing Cisco ASA hardware in 2026, you are managing inherited gear. Cisco's strategic firewall is now Secure Firewall Threat Defense (FTD, formerly known as Firepower Threat Defense). The platform is not just a UI rebrand: FTD runs a different management model (FMC or FDM), a different config plane (object-driven, GUI-first), and a different feature posture (next-gen IPS, URL filtering, SSL decryption native). This article covers the practical question every team running ASA hits eventually: when do we migrate, what tooling does the migration well, what does the migration not move automatically, and what do we verify on the FTD side before declaring the migration done. The answer length here is 1,000-1,500 words because there is no live lab walkthrough; the procedural steps are the value.

This is the Migration article in the Cisco ASA cluster reading order.

When to Migrate (and When to Stay)

Most enterprises migrate when they refresh hardware. That gives you fresh boxes that are FTD-capable from day one and removes the awkward "convert in place" path. If your existing ASA hardware is FTD-capable (most ASA 5500-X models are), in-place reimaging is supported but is operationally messy: it is a wipe-and-reload, the device is offline during the install, and the new image needs FMC registration before policy can be pushed. Hard to do without a maintenance window and a proven backup.

The Cisco Firewall Migration Tool

Cisco publishes a free tool called the Cisco Secure Firewall Migration Tool (formerly the Firepower Migration Tool) that takes an ASA running-config and converts it into an FTD policy plus an upload to FMC. The tool runs as a Windows or macOS application; the workflow is approximately:

1. Export the ASA running-config (more system:running-config output, saved to a text file).
2. Open the migration tool, select "Cisco ASA to Threat Defense."
3. Upload the running-config and the show-tech output (some platform info comes from show-tech, not running-config).
4. The tool parses ACLs, NAT rules, network and service objects, interface IPs, static routes, NAT pools, and AAA references. It surfaces a per-object review screen.
5. You triage: accept clean translations, manually fix or skip items the tool flags as "needs review."
6. The tool can either generate a policy file you push to FMC manually, or push directly to a target FMC (and then to a target FTD device).
7. You bring up the FTD on the same network position, fail traffic over, and verify.

The tool's parser has been refined over many releases and is reliable for straightforward ASA configs. Where it struggles is custom MPF, AnyConnect profiles, multi-context, and any feature that has no direct FTD equivalent.

What Migrates Cleanly

For the 80%-case ASA (perimeter firewall doing routed-mode NAT, ACL, a couple of S2S tunnels, syslog, NTP, AAA), the migration tool produces a usable FTD config that needs only minor cleanup.

What Does Not Migrate (Or Migrates Painfully)

The single biggest migration pain is AnyConnect. The ASA's tunnel-group + group-policy + DAP + AAA + cert-trustpoint model is intricate, and FTD reimplements the same outcomes with a different config shape. Plan for a side-by-side build of the new RA VPN on the FTD, a pilot user group, and a phased cutover rather than a flag-day switch.

Post-Migration Verification Checklist

After the FTD goes live in the same network position, verify:

1. Interface IPs and zones. Every interface in FMC matches the ASA-side configuration. Security zones (FTD's equivalent of named interfaces) are assigned correctly.
2. Routing. Default route present, static routes intact, ECMP working if you had multi-WAN.
3. NAT rules. Run packet-tracer (FTD has a similar tool) for representative outbound and inbound flows. Verify the same source IP gets PATed to the same outside IP, and that the DMZ static NAT publishes the correct public IP.
4. ACL hit counters. Generate test traffic for each high-value rule. Watch the FTD ACP rule hit counter climb.
5. S2S tunnels. Each VPN peer should re-establish. show crypto ipsec sa equivalent in FTD. Encaps/decaps counters climbing in both directions.
6. Logging. FMC's Connection Events table fills as traffic flows. Confirm syslog still flows to your SIEM.
7. NTP. Both FMC and FTD synced; clock skew breaks cert validation.
8. HA pair. If you migrated a failover pair, verify FTD HA peering, sync state, and fail-back behavior.
9. Performance. Connection table size and CPU under load. FTD with all features on uses more CPU than ASA software with the same throughput; size accordingly.
10. Rollback path. Keep the ASA available as a hot spare for at least one to two weeks. Document the rollback procedure (restore config, re-IP, redirect upstream) before you need it.

Hidden Costs to Plan For

Migrations always cost more than the engineering scope predicts. Three line items that consistently get under-budgeted:

• FMC is its own platform. If you do not already operate Firepower Management Center, you need an FMC instance (virtual or hardware), licensing, integration into your monitoring, and an admin learning curve.
• License rework. ASA Smart Licensing is different from FTD Smart Licensing. Bulk migration generally needs a license-conversion exercise with your Cisco partner.
• Operational learning. Your NOC and SecOps teams need to learn FMC's policy model, which is more object-and-rule-driven than the ASA CLI they have been writing for years. Budget training, not just deployment time.

Key Takeaways

The Cisco Secure Firewall Migration Tool covers the 80% case (objects, ACLs, NAT, interfaces, static routes, basic S2S VPN) cleanly. The remaining 20% (AnyConnect profiles, custom MPF inspection, multi-context, DAP, cluster) is where the real migration time goes. Plan for a side-by-side build of those features on FTD, not a one-click migration.

Most teams migrate during a hardware refresh because that gives the cleanest cutover - new FTD-capable boxes, a parallel build, a planned switchover. In-place reimage of FTD-capable ASA hardware works but requires a real maintenance window and a proven backup. Either path, plan for FMC, license rework, and a learning curve as fixed costs that are independent of the technical migration.

For the rest of the cluster, the Cisco ASA pillar has the full reading order, including the comparison article ASA vs FTD vs Firepower for a more direct feature-by-feature look at the two platforms.