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)
| Reason to migrate | Reason to stay on ASA software |
|---|---|
| You need next-gen IPS, URL filtering, AMP, or SSL decryption native in the firewall. | You have a stable ASA with all-static-policy that does exactly what it needs to do. |
| Your hardware is end-of-sale (ASA 5500-X) and the FTD-capable replacement is the natural successor. | You have heavy AnyConnect or custom MPF investment that does not migrate cleanly. |
| Your security org has standardized on FMC for centralized management and policy. | You are running multi-context (which has a counterpart in FTD called Multi-Instance, but the migration is non-trivial). |
| You are buying new firewalls anyway and want to land on Cisco's strategic platform. | You operate a small fleet that is a long way from the next refresh and the migration cost outweighs the upside. |
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:
- Export the ASA running-config (
more system:running-configoutput, saved to a text file). - Open the migration tool, select "Cisco ASA to Threat Defense."
- Upload the running-config and the show-tech output (some platform info comes from show-tech, not running-config).
- 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.
- You triage: accept clean translations, manually fix or skip items the tool flags as "needs review."
- 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).
- 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
| ASA feature | FTD equivalent | Migration status |
|---|---|---|
| Network and service objects, object-groups | Network and Port objects, Object Groups | Clean. The naming model is similar enough that the tool maps these directly. |
| Extended ACLs (interface-bound) | FTD Access Control Policy rules | Mostly clean. Each ACL line becomes one ACP rule; ordering preserved. |
| Auto NAT and Manual NAT | FTD NAT rules (with the same Section 1/2/3 model) | Mostly clean. The tool preserves order and section. |
| Interface IPs, security levels, subinterfaces | FTD Interface configuration | Clean for routed mode. Transparent has caveats. |
| Static routes, default route, AD, tracked routes | FTD Routing -> Static Route | Clean. |
| Site-to-site IKEv2 VPN with PSK | FTD Site-to-Site VPN policy | Mostly clean for IKEv2 + PSK. IKEv1 rarely. |
| AAA server-group definitions (RADIUS/LDAP/TACACS) | FTD AAA / Identity / Realm | Definitions move; the references on tunnel-groups need rework. |
| Default inspection (DNS, FTP, ICMP) | FTD default inspection | Clean - FTD has equivalent built-ins. |
| Logging destinations (host, severity) | FTD Platform Settings -> Syslog | Clean. |
| NTP, SNMPv3, banners | FTD Platform Settings | Clean. |
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)
| ASA feature | FTD equivalent | Migration friction |
|---|---|---|
| AnyConnect / Remote-Access VPN profiles | FTD RA VPN with AnyConnect profile XML | Heavy. Profile XMLs do not auto-migrate. Plan to rebuild. |
| Dynamic Access Policies (DAP) | FTD has identity / posture but the DAP record model is different | Manual rebuild against the new policy model. |
| Custom MPF inspection (HTTP, ESMTP custom maps) | FTD inspection / file policy / SSL policy | Conceptual rebuild. The capabilities are deeper but the config is different. |
| Multi-context | FTD Multi-Instance (different model) | The Cisco Migration Tool has limited support; large multi-context migrations are usually professional services engagements. |
| Transparent mode | FTD transparent / inline mode | Conceptually maps but requires manual setup. |
| Custom EtherType ACLs | Not all EtherType ACL features are present in FTD | Review case by case. |
| Cluster (chassis cluster) | FTD HA + cluster supported on Firepower 4100/9300 | Re-architecture rather than migration. |
| Platform-specific knobs (jumbo frames, custom TCP timeout overrides) | Some are exposed in FlexConfig only | FlexConfig is FTD's escape hatch for ASA-only commands; expect to use it. |
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:
- Interface IPs and zones. Every interface in FMC matches the ASA-side configuration. Security zones (FTD's equivalent of named interfaces) are assigned correctly.
- Routing. Default route present, static routes intact, ECMP working if you had multi-WAN.
- 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.
- ACL hit counters. Generate test traffic for each high-value rule. Watch the FTD ACP rule hit counter climb.
- S2S tunnels. Each VPN peer should re-establish.
show crypto ipsec saequivalent in FTD. Encaps/decaps counters climbing in both directions. - Logging. FMC's Connection Events table fills as traffic flows. Confirm syslog still flows to your SIEM.
- NTP. Both FMC and FTD synced; clock skew breaks cert validation.
- HA pair. If you migrated a failover pair, verify FTD HA peering, sync state, and fail-back behavior.
- 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.
- 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.
