Migrating Cisco Secure Firewall ASA to Cisco Secure Firewall Threat Defense Using Firewall Migration Manager

PDF

Migrating Cisco Secure Firewall ASA to Cisco Secure Firewall Threat Defense Using Firewall Migration Manager

Migration guidelines and limitations

Updated: July 22, 2026

Want to summarize with AI?

Log in

Outlines migration guidelines and limitations for Firewall Migration Manager including configuration mapping, object handling, and device-specific considerations.

Migration object and rule handling

During migration, the Firewall Migration Manager creates a one-to-one mapping for all supported objects and rules, whether they are used in a rule or policy. The Firewall Migration Manager provides an optimization feature that allows you to exclude migration of unused objects (objects that are not referenced in any ACLs and NATs).

  • Unsupported objects and NAT rules are not migrated.

  • Unsupported ACL rules are migrated as disabled rules into the Firewall Management Center.

  • Outbound ACLs are unsupported and will not be migrated to Firewall Management Center. If the source firewall has outbound ACLs, it will be reported in the ignored section of the Pre-Migration Report.

  • All supported crypto map VPN will be migrated as Firewall Management Center point-to-point topology.

  • Unsupported or incomplete static crypto map VPN topologies are not migrated.

  • In an ASA multicontext to a single instance threat defense migration, the equal-cost multipath (ECMP) routing configurations are migrated to the corresponding virtual routing and forwarding (VRF) configurations:

    • Interfaces in two different security contexts with the same name are renamed by adding an underscore and the context name.

    • Security zones in two different security contexts with the same name are renamed by adding an underscore and the context name.

    • If ECMP routing configurations are present with VPN configurations, they are migrated to the global router (global VRF).

Configuration limitations

Migration of your source configuration has the following limitations:

  • The system configuration is not migrated.

  • The Firewall Migration Manager does not support migration of a single ACL policy that is applied to over 50 interfaces. Manually migrate ACL policies that are applied to 50 or more interfaces.

  • You cannot migrate some configurations, for example, dynamic routing to Firewall Threat Defense. Migrate these configurations manually.

  • You cannot migrate devices in routed mode with a bridge virtual interface (BVI), redundant interface, or tunneled interface. However, you can migrate devices in transparent mode with BVI.

  • Nested service object-groups or port groups are not supported on the Firewall Management Center. As part of conversion, the Firewall Migration Manager expands the content of the referenced nested object-group or port group.

  • The Firewall Migration Manager splits the extended service object or groups with source and destination ports that are in one line into different objects across multiple lines. References to such access control rules are converted into Firewall Management Center rules with the exact same meaning.

  • If the source configuration has access control rules that do not refer to specific tunneling protocols (like GRE, IP-in-IP and IPv6-in-IP), but these rules match unencrypted tunnel traffic on the , then, on migration to the Firewall Threat Defense, the corresponding rules will not behave in the same way they do on the . We recommend that you create specific tunnel rules for these in the Prefilter policy, on the Firewall Threat Defense.

  • Supported crypto map will be migrated as point-to-point topology.

  • If an AS-Path object with the same name in Firewall Management Center appears, then the migration stops with error message: "Conflicting AS-Path object name detected in Firewall Management Center, please resolve conflict in Firewall Management Center to proceed further"

  • Redistribution from OSPF and Routing Information Protocol (RIP) into EIGRP is not supported.

  • For PBR, ASA configuration has route-maps whereas management center does not use route-maps. The Firewall Migration Manager migrates the configuration inside a route-map applied to an interface.

  • For route-maps with multiple sequence numbers, only the first sequence number will be migrated. All other sequence numbers will be ignored and shown in the pre-migration report.

Limitations for RA VPN migration

Remote Access VPN migration is supported with the following limitations:

  • SSL settings migration is not supported due to API limitations.

  • LDAP server is migrated with encryption type as "none".

  • DfltGrpPolicy is not migrated as the policy is applicable for the entire Firewall Management Center. You can make the necessary changes directly on the Firewall Management Center.

  • For a RADIUS server, if dynamic authorization is enabled, the AAA server connectivity should be through an interface and not dynamic routing. If ASA configuration is found with AAA server with dynamic authorization enabled without interface, the Firewall Migration Manager ignores dynamic authorization. You must enable dynamic-authorization manually after selecting an interface on the management center.

  • ASA configuration can have an interface while calling address pool under tunnel-group. But the same is not supported on the management center. If there an interface is detected in the ASA configuration it is ignored by the Firewall Migration Manager and the address pool is migrated without the interface.

  • ASA configuration can have keyword link-selection/subnet-selection for DHCP-server under tunnel group. But the same is not supported on the management center. If a DHCP server is detected in the ASA configuration with these keywords, it is ignored by the Firewall Migration Manager and the DHCP-server is pushed without the keywords.

  • ASA configuration can have an interface while calling authentication server group, secondary authentication server group, authorization server group under tunnel group. But the same is not supported on the management center. If an interface is detected in the ASA configuration it is ignored by the Firewall Migration Manager and the commands are pushed without the interface.

  • ASA configuration does not map Redirect ACL to a RADIUS server. Thus, there is no way to retrieve it from the Firewall Migration Manager. If redirect ACL is used in the ASA, it is left empty, and you must add and map it manually on the management center.

  • ASA supports value from 0-720 for VPN-addr-assign local reuse delay. But the management center supports value from 0-480. If a value higher than 480 is found in the ASA configuration, it is set to maximum supported value 480 on the management center.

  • Configuring IPv4 pool and DHCP useSecondaryUsernameforSession settings to the connection profile is not supported due to API issues.

  • Bypass access control sysopt permit-VPN option is not enabled under RA VPN policy. However, if required, you can enable it from the management center.

  • AnyConnect client module and profile values can be updated under group policy only when the profiles are uploaded from Firewall Migration Manager to the management center.

  • You need to map the certificates directly on the management center.

  • IKEv2 parameters are not migrated by default. You must add them through the management center.

ASA migration guidelines

The migration of the ACL log option follows the best practices for Firewall Threat Defense. The log option for a rule is enabled or disabled based on the source ASA configuration. For rules with an action of deny, the Firewall Migration Manager configures logging at the beginning of the connection. If the action is permit, the Firewall Migration Manager configures logging at the end of the connection.

Object migration guidelines

The Firewall Migration Manager and Firewall Threat Defense have different configuration guidelines for objects. For example, one or more objects can have the same name in with one object name in lowercase and the other object name in uppercase, but each object must have a unique name, regardless of case, in Firewall Threat Defense. To accommodate such differences, the Firewall Migration Manager analyzes all objects and handles their migration in one of the following ways:

  • Each object has a unique name and configuration—The Firewall Migration Manager migrates the objects successfully without changes.

  • The name of an object includes one or more special characters that are not supported by the Firewall Management Center—The Firewall Migration Manager renames the special characters in the object name with a "_" character to meet the Management Center object naming criteria.

  • An object has the same name and configuration as an existing object in the Firewall Management Center—The Firewall Migration Manager reuses the Secure Firewall Management Center object for the Secure Firewall Threat Defense configuration and does not migrate the object.

  • An object has the same name but a different configuration than an existing object in Secure Firewall Management Center—The Firewall Migration Manager reports object conflict and allows you to resolve the conflict by adding a unique suffix to the name of the object for migration purposes.

  • Multiple objects have the same name but in different cases—The Firewall Migration Manager renames such objects to meet the Secure Firewall Threat Defense object naming criteria.

The Firewall Migration Manager analyzes both name and configuration of all objects and object groups. However, XML profiles in remote-access VPN configurations are analyzed only using the name.

The Firewall Migration Manager supports discontiguous network mask (Wildcard mask) objects migration if the destination Firewall Management Center is 7.1 or later.

ASA example: 
object network wildcard2
subnet 2.0.0.2 255.0.0.255

Guidelines and limitations for ASA WebVPN to ZTA migration

Before attempting an ASA WebVPN to ZTA migration, make sure you read these points thoroughly:

  • The target management center and threat defense device must be running Version 7.4 or later.

  • The target threat defense device must be using Snort3 as the detection engine.

  • The ASA trustpoint certificates (IdP and pre-authentication) must be manually uploaded to the target management center before migration.

  • The application SSL certificates, along with their private keys, must be uploaded to the target management center before migration.

  • Local, RADIUS, and LDAP authentication methods are not supported.

  • You can assign only one ZTA policy to a threat defense device.

Guidelines and limitations for firewall threat defense devices

As you plan to migrate your ASA configuration to Firewall Threat Defense, consider these guidelines and limitations:

  • If there are any existing device-specific configurations on the Firewall Threat Defense such as routes, interfaces, and so on, during the push migration, the Firewall Migration Manager cleans the device automatically and overwrites from the ASA configuration.

    Note

    To prevent any undesirable loss of device (target Firewall Threat Defense) configuration data, we recommend you to manually clean the device before migration.

  • The Firewall Migration Manager can create subinterfaces on the native instance of the Firewall Threat Defense device based on the ASA configuration. Manually create interfaces and port channel interfaces on the target Firewall Threat Defense device before starting migration. For example, if your ASA configuration is assigned with specific interfaces and port channels, you must create them on the target Firewall Threat Defense device before the migration:

    Note

    Manual creation of sub-interfaces or port-channels applies only to chassis-managed devices. For other devices, Firewall Migration Manager creates sub-interfaces or port-channels based on the source configuration structure.

    • Five physical interfaces

    • Five port channels

    • Two management-only interfaces

    Note

    For container instances of Firewall Threat Defense devices, subinterfaces are not created by the Firewall Migration Manager, only interface mapping is allowed.

  • The Firewall Migration Manager can create subinterfaces and Bridge-Group Virtual Interfaces (transparent mode) on the native instance of the Firewall Threat Defense device that is based on the ASA configuration. Manually create interfaces and port channel interfaces on the target Firewall Threat Defense device before starting migration. For example, if your ASA configuration is assigned with specific interfaces and port channels, you must create them on the target Firewall Threat Defense device before the migration:

    • Five physical interfaces

    • Five port channels

    • Two management-only interfaces