Your ASA Is Out of Support. Moving to FTD Is Still a Migration

Cisco's last day of support for the ASA 5506-X, 5508-X and 5516-X was 31 August 2026. If those boxes still pass traffic, the migration ahead of you now runs without a vendor safety net, and choosing Cisco's own successor does not make it smaller. Moving from ASA to Firepower Threat Defense (FTD) means translating the whole rule base, just as moving to another vendor would. That puts FTD in a tender with everyone else.

Two things landed in the same fortnight. The support deadline passed. A week later, Gartner published its 2026 Magic Quadrant for Hybrid Mesh Firewall on 7 September, with Fortinet, Palo Alto Networks and Check Point as the only Leaders and Cisco placed as a Visionary. Neither fact, alone, tells an ASA shop what to do. Together they remove the assumption most renewal plans were quietly built on: that staying with Cisco is the low-change option.

Which ASA models are now out of support

The ASA 5500-X family has been leaving support in waves, and the wave that just broke is the last big one. Cisco's own end-of-life notices give the dates; third-party trackers do not always match them, so use Cisco's.

Model	End of sale	Last date of support	Cisco's named successor
ASA 5512-X, 5515-X	25 Aug 2017	31 Aug 2022	ASA 5506-X series (itself now out)
ASA 5525-X, 5545-X, 5555-X	4 Sep 2020	30 Sep 2025	Firepower 2100
ASA 5506-X	2 Aug 2021	31 Aug 2026	Firepower 1000
ASA 5508-X, 5516-X	2 Aug 2021	31 Aug 2026	Firepower 1000

Cisco's recommended migration for the 5512-X and 5515-X was the 5506-X series, and that path has now expired as well. A site that followed Cisco's advice to the letter in 2017 has done one migration already and owes another. The 5508-X and 5516-X notice also stopped service contract renewals on 28 October 2025, ten months before support itself ended.

Why a migration after the deadline is a different project

A migration planned before the last date of support has a fallback: if the cutover goes wrong, you roll back to a supported box and try again next window. A migration after that date has no supported state to return to. The old ASA is still there, but it is now a known end state, not a safe one. That changes three things in how the change has to be run.

• Rollback becomes a stopgap. Reverting to the ASA buys a night. Every rollback plan needs an expiry date, the same discipline an emergency change that reverts itself requires.
• Time pressure pushes toward lift-and-shift. Under a deadline, teams migrate the rule base as it stands, redundant and shadowed rules included, and promise to clean up afterwards. Cleaning up before the move is cheaper. The rule base optimisation and decommissioning work shrinks what has to be translated.
• The change board sees risk differently. A board that approved "replace the firewall" in 2025 approved a planned change. The same work now is closer to remediation, and the evidence it produces should say so: what ran unsupported, for how long, and why.

ASA to FTD is not an upgrade. It is a translation

The natural assumption in a Cisco shop is that staying with Cisco keeps the change small. For the rule base, it does not. FTD is a different operating system with a different policy model, typically managed through Firewall Management Center rather than the ASA command line. Cisco's own Secure Firewall Migration Tool guide is honest about what does not come across automatically:

• The system configuration is not migrated.
• Outbound ACLs are ignored, and access-list remarks are not supported.
• Dynamic routing is not migrated, and for route maps with several sequence numbers only the first is carried over.
• A single ACL applied to more than 50 interfaces is not supported.
• For remote access VPN, SSL settings are not migrated, LDAP servers arrive with encryption set to none, and the default group policy is left behind.

Each of those lines is manual work, and some of them are quiet security regressions if nobody catches them. An LDAP server that arrives with encryption set to none is exactly the sort of thing that passes a functional test and fails an audit. The tool also flags redundant and shadowed rules on the way through, and the list above is simply what the work consists of: a translation between two policy models, with items a human has to rebuild and verify.

The same Cisco tool accepts Check Point, Palo Alto Networks and Fortinet configurations as sources. Fortinet's FortiConverter lists Cisco ASA 7.x, 8.x and 9.x as a supported source, with ACLs, NAT, objects and VPN among the converted objects. Competitors build tooling to take ASA configurations in, and Cisco builds tooling to take theirs. The translation step exists whichever logo is on the new box.

The option most plans skip: ASA software on new hardware

There is a third path, and it is the only one that genuinely keeps the change small. Cisco's current appliances run either application. The ASA and threat defense reimage guide lists the Firepower 1000, Secure Firewall 1200, Firepower 2100, Secure Firewall 3100 and 4200 among the models that support either ASA software or FTD. An ASA estate can move to supported hardware and keep the ASA configuration language, the ASA command line and the operational knowledge that goes with it.

That path has a real cost, and it should be written down rather than discovered. It postpones the policy-model migration instead of avoiding it, so the organisation will pay for the translation later, on its own schedule instead of Cisco's. Switching the same box between ASA and FTD later is a reimage, and the guide is blunt about what that means: "All existing configuration will be lost and the default configuration applied." For a team under deadline pressure, that trade can be the right one. It should be a written decision.

Three options, compared on the change itself

Option	Rule base work	Operational change	What it defers
ASA software on new Cisco hardware	Lowest: same configuration language	Low: same CLI and tooling	The move to a new policy model
FTD with the Cisco migration tool	Full translation, documented manual gaps	High: new manager, new policy model	Nothing, but the vendor choice is made by default
Another vendor with its converter	Full translation, vendor-specific gaps	High: new manager, new platform, retraining	Nothing; exit costs are paid now

Read the table by columns, not rows. The middle and bottom options carry the same class of rule base work. Across hundreds of migrations, the pattern holds: the effort sits in the translation and the verification of what the tool could not carry, not in unboxing hardware. The failure taxonomy is the same for a same-vendor move as for a cross-vendor one, because the failures live in the policy model.

What the Magic Quadrant does and does not change

Gartner's placement says nothing about whether an FTD migration works. It signals where the market is going, and the signal is a year old. In the inaugural edition in August 2025, Cisco was already placed as a Visionary, with Gartner noting one of the lowest new-customer acquisition volumes in the market. In the 2026 edition, as reported by SDxCentral, Gartner does not see Cisco's hybrid mesh firewall offering being frequently shortlisted for newer customer deployments, and some clients "continue to report issues related to bugs, unstable firmware, and frequent patching."

For an ASA shop, the useful reading is narrower than "leave Cisco". In both editions of the report so far, the analyst that most procurement teams cite has placed Cisco outside the Leaders. That is enough to make a competitive tender defensible to a finance department that would otherwise ask why you did not simply renew. It is not enough to pick the winner. The tender does that.

How to run the decision as a tender

An ASA replacement tender that compares datasheets will be won by whichever vendor has the best throughput number on page one. A tender that compares the change will be decided by what actually costs money. Four questions do most of the work.

• Ask every bidder, Cisco included, to run their converter on your real configuration and return the list of objects that did not convert. The length and content of that list is the most honest pricing signal in the process.
• Price the operations change, not just the licence. A new manager, a new policy model and retraining cost the same order of effort whether the new platform is FTD or not. The earlier Palo Alto to Fortinet and Check Point to Palo Alto write-ups show where that effort actually lands.
• Decide the cleanup scope before the tender. Every rule you retire first is a rule no bidder has to translate, and no one has to verify.
• Write the interim risk into the record. If ASAs run past the last date of support while the tender runs, the change record should say which ones, behind what, and until when. That is the document someone will ask for later.

If the estate is already mixed, the multi-vendor management question is part of the tender as well: a second platform added for convenience becomes a permanent operating cost.

Why it matters

The last date of support is often treated as a hardware event, and budgets follow that framing: replace the box, keep the vendor, minimise the change. For the ASA it was a policy event. Every realistic path except one involves translating the rule base into a new model, and that one path only postpones the translation. Once that is clear, the question stops being "which box replaces the ASA" and becomes "which policy model do we want to live in for the next decade, and what does it cost to get there cleanly". That question needs a tender and a cleaned-up rule base to answer it.

Would your change records show which ASAs ran past 31 August, and why? The free NIS2 Readiness Check walks through the evidence a firewall change process has to produce.