Cisco ASA End of Life: Migration Options for Berlin Enterprises (2026)
Cisco ASA End of Life: Migration Options for Berlin Enterprises (2026)
If your Berlin organisation is still running Cisco ASA hardware, you need a plan. Several ASA models have already reached end of sale, and end-of-support dates are arriving across the product range over the next few years. When support ends, you stop receiving security patches — and a firewall without security patches is not a firewall, it’s a liability.
This post lays out your options clearly, without pushing a particular path. The right migration depends on your environment, your budget, and how deeply invested you are in the Cisco ecosystem.
Which ASA models are affected and when
⚠️ All dates below are approximate and model-specific. Verify against Cisco’s official End-of-Life and End-of-Support notices at cisco.com/go/eos before making decisions. Different ASA hardware SKUs have different dates — check your exact model number.
Cisco has been phasing out the ASA product line progressively. The pattern is consistent: end-of-sale first (you can no longer buy new units), then end-of-software maintenance (no new code releases), then end-of-support (no TAC assistance, no security patches).
Some older ASA models reached end of support several years ago. Mid-range models from the mid-2010s are approaching or have recently passed end-of-software maintenance. The 5500-X series — widely deployed in European enterprises — has had staggered EoL dates across SKUs, with several reaching end of support in the 2024–2026 timeframe. Verify the exact status of your model against Cisco’s official EoL notices before acting on any general guidance.
If you don’t know the exact status of your hardware, pull the model number from your device (show version in the CLI) and cross-reference it against Cisco’s EoL notices. This is a 10-minute task and worth doing before reading any further.
Your three migration options
Once you’ve confirmed your ASA hardware is approaching end of support, you have three meaningful choices:
Option 1: ASA to Firepower Threat Defense (FTD) — stay on the Cisco stack
Cisco’s successor to ASA is Firepower Threat Defense (FTD) — a merged platform combining ASA’s stateful firewall capabilities with Cisco’s Firepower intrusion prevention and threat intelligence. FTD runs on Firepower hardware and is managed through Firepower Management Center (FMC) or, for smaller deployments, Firepower Device Manager (FDM).
This path makes sense if: you’re already invested in Cisco SmartNet support contracts; your team knows Cisco; you have Cisco TAC relationships you want to maintain; or you’re running Cisco switching and wireless infrastructure that benefits from integrated management.
The honest caveat: ASA-to-FTD migrations are non-trivial. The policy model is different, the management interface is different, and the migration tool (Cisco’s tool for converting ASA configurations to FTD) does the bulk conversion but requires careful review and testing — not a straight lift-and-shift. Plan for a proper migration project, not an appliance swap.
Option 2: Migrate to Azure Firewall — move to cloud-native
If your infrastructure has been moving to Azure and your on-premise footprint is shrinking, this is the right moment to ask whether you need an on-premise firewall at all. Azure Firewall — or Azure Firewall Premium for more advanced threat inspection — handles egress control and east-west traffic for cloud-native environments without hardware to manage.
This path makes sense if: a significant proportion of your workloads are already in Azure; you’re planning to reduce on-premise infrastructure over the next two to three years; or you want to reduce the operational overhead of hardware maintenance and firmware management.
The honest caveat: Azure Firewall is not a direct replacement for on-premise ASA in a hybrid or fully on-premise environment. It works for cloud-native traffic; it doesn’t replace the perimeter security function for offices, branch sites, or on-premise servers that aren’t migrating to the cloud.
Option 3: Switch platforms — FortiGate, Palo Alto, or Check Point
Some organisations use the ASA end-of-life as an opportunity to reassess the platform decision entirely. If you’ve been running ASA because it’s what was in place when you joined, or because the previous IT provider deployed it, EoL is a natural forcing function for a competitive review.
FortiGate is the most common alternative for SMB and mid-market deployments migrating off ASA — it’s well-priced, capable, and widely supported. Palo Alto and Check Point are the enterprise-tier alternatives for organisations where security depth and compliance tooling justify the cost premium. Read our Palo Alto vs Check Point comparison →
The case for staying on the Cisco stack
Cisco has invested significantly in FTD and the broader Cisco Security portfolio. If your organisation has Cisco networking throughout — Catalyst switches, Meraki access points, ISE for network access control — the Cisco-to-Cisco path has genuine integration advantages that aren’t available with a platform switch.
TAC support quality for Cisco products is well-regarded, and if your team already has Cisco knowledge (CCNA/CCNP-level), the FTD learning curve is manageable. For organisations with existing Cisco certification programmes or training budgets, this matters.
The case for switching platforms
ASA end-of-life removes the inertia argument for staying on Cisco. If the reason you’ve been running ASA is “it’s what we have,” that reason expires when the hardware is no longer supported.
The FTD management model is significantly different from ASA — the migration is not transparent, and for organisations without deep Cisco expertise, the FMC management interface is not simpler than alternatives. If you’re going to invest in a migration project regardless, evaluate the full market before defaulting to the Cisco successor.
For Berlin businesses with DSGVO obligations or regulated sector requirements, a platform review is also an opportunity to ensure your new firewall has the compliance tooling and logging capabilities your data protection obligations require.
What the migration actually involves
Regardless of which path you take, a firewall migration for a production environment involves more than replacing hardware. Budget time and attention for:
- Configuration audit. Before migrating, document and review your current ASA configuration. Many production ASA deployments accumulate years of undocumented rule additions. Migration is the right time to clean this up, not carry it forward.
- Policy translation. ASA ACLs, NAT rules, VPN configurations, and object definitions all need to be translated to the target platform’s model. Automated migration tools help with the bulk work but require careful review.
- VPN reconfiguration. Site-to-site and remote access VPN configurations typically require manual reconfiguration on the new platform. If you have multiple VPN peers, factor this into the project scope.
- Testing window. Never cut over production traffic to a new firewall without a testing phase. Run parallel configurations if possible, and test traffic flows before cutover.
- Timeline. For a mid-size deployment (50–300 users, 5–15 VPN tunnels), allow 3–8 weeks for planning, configuration, testing, and cutover. This is a general range — scope varies significantly by complexity and how clean the current ASA configuration is.
Making the decision
If your ASA hardware is approaching end of support, the decision timeline is now — not when the support date passes. Migrating a firewall under time pressure because support has already expired is harder and riskier than migrating on a planned schedule.
The right path depends on your specific environment: how much Cisco infrastructure you have elsewhere, how cloud-forward your workloads are, what your budget looks like, and whether your team has Cisco expertise worth preserving or is ready for a clean start on a different platform.
I’ve done ASA migrations to all three destination types — FTD, Azure Firewall, and alternative vendors. If you want an independent assessment of your options before committing, I’m happy to take a look. More on firewall migration services →