Step 1

On your computer, create a folder for the Secure Firewall migration tool.

Step 2

Browse to https://software.cisco.com/download/home/286306503/type and click Firewall Migration Tool.

Step 3

Download the most recent version of the Secure Firewall migration tool into the folder that you created.

Step 1

Use the following command to export the PKI certificate through the CLI from the source ASA config with the keys to a PKCS12 file:

ASA(config)#crypto ca export <trust-point-name> pkcs12 <passphrase>

Step 2

Import the PKI certificate into a management center (Object Management PKI Objects).

Step 1

Use the following command to copy the required package from the source ASA to an FTP or TFTP server:

Copy <source file location:/source file name> <destination> 
ASA# copy disk0:/anyconnect-win-4.10.02086-webdeploy-k9.pkg tftp://1.1.1.1 <----- Example of copying Anyconnect Package. 
ASA# copy disk0:/ external-sso- 4.10.04071-webdeploy-k9.zip tftp://1.1.1.1 <----- Example of copying External Browser Package. 
ASA# copy disk0:/ hostscan_4.10.04071-k9.pkg tftp://1.1.1.1 <----- Example of copying Hostscan Package. 
ASA# copy disk0:/ dap.xml tftp://1.1.1.1. <----- Example of copying Dap.xml 
ASA# copy disk0:/ sdesktop/data.xml tftp://1.1.1.1 <----- Example of copying Data.xml 
ASA# copy disk0:/ VPN_Profile.xml tftp://1.1.1.1 <----- Example of copying Anyconnect Profile.

Step 2

Import the downloaded packages to management center (Object Management > VPN > AnyConnect File).

Step 1

On your computer, navigate to the folder where you downloaded the Secure Firewall migration tool.

Step 2

Do one of the following:

• On your Windows machine, double-click the Secure Firewall migration tool executable to launch it in a Google Chrome browser.

  If prompted, click Yes to allow the Secure Firewall migration tool to make changes to your system.

  The Secure Firewall migration tool creates and stores all related files in the folder where it resides, including the log and resources folders.

• On your Mac move, the Secure Firewall migration tool *.command file to the desired folder, launch the Terminal application, browse to the folder where the Secure Firewall migration tool is installed and run the following commands:

  # chmod 750 Firewall_Migration_Tool-version_number.command

  # ./Firewall_Migration_Tool-version_number.command

  The Secure Firewall migration tool creates and stores all related files in the folder where it resides, including the log and resources folders.

  Tip

  When you try to open the Secure Firewall migration tool, you get a warning dialog because the Secure Firewall migration tool is not registered with Apple by an identified developer. For information on opening an application from an unidentified developer, see Open an app from an unidentified developer.

  Note	Use MAC terminal zip method.

Step 3

On the End User License Agreement page, click I agree to share data with Cisco Success Network if you want to share telemetry information with Cisco, else click I'll do later.

Step 4

On the Secure Firewall migration tool's login page, do one of the following:

• To share statistics with Cisco Success Network, click the Login with CCO link to log in to your Cisco.com account using your single sign-on credentials. If you do not have a Cisco.com account, create it on the Cisco.com login page.

  Proceed to step 8, if you have used your Cisco.com account to log in.

• If you have deployed your firewall in an air-gapped network that does not have internet access, contact Cisco TAC to receive a build that works with administrator credentials. Note that this build does not send usage statistics to Cisco, and TAC can provide you the credentials.

Step 5

On the Reset Password page, enter the old password, your new password, and confirm the new password.

Step 6

Click Reset.

Step 7

Log in with the new password.

Step 8

Review the pre-migration checklist and make sure you have completed all the items listed.

Step 9

Click New Migration.

Step 10

On the Software Update Check screen, if you are not sure you are running the most recent version of the Secure Firewall migration tool, click the link to verify the version on Cisco.com.

Step 11

Click Proceed.

Step 1

On the Extract ASA Information page, in the Manual Upload section, click Upload to upload an ASA configuration file.

Step 2

Browse to where the ASA configuration file is located and click Open.

Step 3

Review the Context Selection section and select the ASA context that you want to migrate.

Step 1

On the Extract ASA Information screen, in the Connect to ASA section, click Connect to connect to the ASA device that you want to migrate.

Step 2

On the ASA Login screen, enter the following information:

Step 3

Select the ASA context that you want to migrate from the Context drop-down list.

Step 4

(Optional) Select Collect Hitcounts.

Step 5

Click Start Extraction.

Step 1

Upload your ASA configuration file; if your configuration file contains contexts, the migration tool displays the names of all the security contexts.

Step 2

(Optional) To migrate configurations from one of your contexts, click the Context Migration (One at a time) radio button and choose a context to proceed with migration.

Step 3

(Optional) To merge configurations from multiple contexts into a single instance and migrate them, click the Merge Multi-Context to Single Instance radio button. When you opt for multicontext merging, you can see context information such as the number of configuration lines, ACLs, objects, routes including static routes, PBR, and ECMP, and interfaces. Note that merging multiple contexts into a single instance is supported for both transparent and routed firewall-mode contexts. However, ensure that you select contexts of the same type to be merged; you cannot merge a transparent mode context with a routed-mode context. The system and admin contexts are not supported, and the migration tool does not detect them.

Step 4

Click Start Parsing. Once you select a context and start to parse, the migration tool merges the configurations from all the contexts, parses them, and displays the Parsed Summary. If you are performing a merged-context migration, note that the number of contexts you selected to migrate is the same as the number of VRFs in the parsed summary. However, if you have a context with VPN configuration, the parsed summary displays one VRF less, because the VRF that has the VPN configuration gets pushed to the global router directly.

Step 5

Review the summary of the elements in the uploaded configuration file that the Secure Firewall migration tool detected and parsed.

Step 6

Click Next to select the target parameters.

Step 1

On the Select Target screen, in the Firewall Management section, do the following: you can choose to migrate to an On-Prem Firewall Management Center or Cloud-delivered Firewall Management Center:

1. Click the On-Prem FMC radio button.

2. Enter the IP address or Fully-Qualified Domain Name (FQDN) for the management center.

3. In the Domain drop-down list, select the domain to which you are migrating.

   If you want to migrate to a threat defense device, you can only migrate to the threat defense devices available in the selected domain.

4. Click Connect and proceed to Step 2.

1. Click the Cloud-delivered FMC radio button.

2. Choose the region and paste the Security Cloud Control API token. For generating the API token. from Security Cloud Control, follow the below steps:

   1. Log in to Security Cloud Control.

   2. From the top-right corner, navigate to Preferences > General Preferences and copy the API Token from My Tokens section.

3. Click Connect and proceed to Step 2.

Step 2

In the Firewall Management Center Login dialog box, enter the username and password of the dedicated account for the Secure Firewall migration tool, and click Login.

Step 3

Click Proceed.

Step 4

In the Choose FTD section, do one of the following:

• Click the Select FTD DeviceSelect FTD Device (Includes FTD - Standalone/HA Pair) drop-down list and check the device where you want to migrate the ASA configuration.

  Note	This list includes both standalone threat defense devices and devices that are part of a high availability (HA) pair on the target management center.

  The devices in the selected management center domain are listed by IP Address, Name, Device Model, and Mode (routed or transparent).

  Note

  At minimum, the native threat defense device you choose must have the same number of physical or port channel interfaces as the ASA configuration that you are migrating. At minimum, the container instance of the threat defense device must have the same number of physical or port channel interfaces and subinterfaces. You must configure the device with the same firewall mode as the ASA configuration. However, these interfaces do not have to have the same names on both devices.

  Note

  Only when the supported target threat defense platform is Firewall 1010 with management center version 6.5 or later.6.5, FDM 5505 migration support is applicable for shared policies and not for device specific policies. When you proceed without threat defense, the Secure Firewall migration tool will not push any configurations or the policies to the threat defense. Thus, interfaces and routes, and site-to-site VPN which are threat defense device-specific configurations will not be migrated. However, all the other supported configurations (shared policies and objects) such as NAT, ACLs, and port objects will be migrated. Remote Access VPN is a shared policy and can be migrated even without threat defense.

  Table 1. ASA Firewall Features and Supported Management Center or Threat Defense Versions

  Firewall Features	Supported Management Center or Threat Defense Version
  ASA with remote deployment	6.7 or later
  Crypto Map Site-to-Site VPN	6.6 or later
  Virtual Tunnel Interface (VTI) and Route-based (VTI)	6.7 or later
  Dynamic-Route Objects and BGP	7.1 or later
  Remote Access VPN	Management Center 7.2 or later Threat Defense 7.0 or later.
  EIGRP	Management Center 7.2 or later Threat Defense 7.0 or later.
  PBR	Management Center 7.3 or later Threat Defense 7.3 or later.
  ECMP	Management Center 7.1 or later Threat Defense 6.5 or later.
  WebVPN	Management Center 7.4 or later Threat Defense 7.4 or later
  SNMP	Management Center 7.4 or later Threat Defense 7.4 or later
  DHCP Relay, Server, and DDNS	Management Center 7.4 or later Threat Defense 7.4 or later

  Note	To migrate Site-to-Site VPN, VTI, and Route-based (VTI) interfaces, threat defense must be configured on management center.

• For ASA 5505, the device-specific configs (Interface and routes) and shared policies (NAT, ACLs, and Objects) can be migrated only when the supported target threat defense platform is Firewall 1010 with management center version 6.5 or later.

  Note

  If the target threat defense is not FPR-1010 or the target management center is earlier than 6.5, ASA 5505 migration support is applicable for shared policies only. Device specifics will not be migrated. You can select only FPR-1010 in the Select Device drop-down list as the source config is ASA 5505. ASA-SM migration support is for shared policies only. Device specifics will not be migrated.

• Click Proceed without FTD to migrate the configuration to the management center.

  When you proceed without threat defense, the Secure Firewall migration tool will not push any configurations or the policies to threat defense. Thus, interfaces and routes, and site-to-site VPN which are threat defense device-specific configurations will not be migrated and need to be manually configured on management center. However, all the other supported configurations (shared policies and objects) such as NAT, ACLs, and port objects will be migrated. Remote Access VPN is a shared policy and can be migrated even without threat defense.

• This option displays only if the source ASA device is in an HA pair.

  Click Proceed with FTD HA Pair Configuration to select active and standby threat defense devices for your HA pair. When you select the active device, ensure that there is an identical device on the target management center for FMT to be able to show up the idential device as the standby device option and the HA pair creation to be successful.

  Note	You cannot proceed to the further steps of migration if there is no identical device on the target management center to be selected as the standby device or if you do not select a standby threat defense device.

  

  Click Setup FTD HA Pair and configure the following on the Configure Target FTDs in High Availability Pair window:

  1. Specify a name for the HA pair in the HA Pair Name filed.

  2. Under High Availability Link, choose an Interface which has enough bandwidth to reserve when failover communications need to happen.

     Note	The Interface drop-down lists only the interfaces which do not have a logical name and are not part of any security zones.

  3. Specify a Logical Name for the interface.

  4. Specify a Primary IP address for the high availability link on the active device unit. Ensure that the IP address is on an unused subnet.

  5. Specify a Secondary IP address for the high availability link on the standby device unit. Ensure that the secondary IP address is on the same subnet as the primary IP address.

  6. Specify a Subnet Mask that applies to both the primary and secondary IP addresses.

  7. Under State Link, choose Same as LAN Failover Link or a different Interface. Selecting the Same as LAN Failover Link populates the data from the failover link that you just configured.

  8. Check the Enabled checkbox under IPsec Encryption to enable encryption between the failover links and choose a Key Generation method.

  9. Click Add to start setting up the HA pair.

  Note that the Notifications Center icon keeps blinking until the creation of HA pair is in progress. In cases where the creation of HA pair fails for some reason, FMT notifies you by showing a Blocked error message. In such cases, because the migration tool attempted to create the HA pair and failed, the management center will have the HA pair created but not successful.

  Log in to the management center and break the HA manually and select Click Here in the error message in the migration tool to start to configure the HA pair again. For more information on how to break an HA pair, see:

  • Break a High Availability Pair if the target management center is On-Premises Firewall Management Center

  • Break a High Availability Pair if the target management center is cloud-delivered Firewall Management Center

  Note	The values entered or populated as part of the other migration steps are retained even if the HA setup fails and is to be re-configured.

Step 5

Click Proceed.

Step 6

Click the Select Features section to review and select the features that you want to migrate to the destination.

• If you are migrating to a destination threat defense device, the Secure Firewall migration tool automatically selects the features available for migration from the ASA configuration in the Device Configuration and Shared Configuration sections. You can further modify the default selection, according to your requirements.
• If you are migrating to a management center, the Secure Firewall migration tool automatically selects the features available for migration from the ASA configuration in the Device Configuration, Shared Configuration, and Optimization sections. You can further modify the default selection, according to your requirements.

• The Secure Firewall migration tool supports the following for access control during migration:

  • Populate Destination Security Zones—Enables mapping of destination zones for the ACL during migration.

    Route-lookup logic is limited to Static Routes and Connected Routes, whereas PBR, Dynamic Routes, and NAT are not considered. Interface network configuration is used to derive the connected route information.

    Based on the nature of Source and Destination network object-groups, this operation may result in rule explosion.

  • Migrate Tunneled rules as Prefilter—Mapping of ASA encapsulated tunnel protocol rule to Prefilter tunnel rules has the following advantages:

    • Tailor Deep Inspection—For encapsulated traffic and to improve performance with fastpathing.

    • Improve Performance—You can fastpath or block any other connections that benefit from early handling.

    The Secure Firewall migration tool identifies the encapsulated tunnel traffic rules in source configuration and migrates them as Prefilter tunnel rules. You can verify the migrated tunnel rule under the Prefilter policy. The Prefilter policy is associated with the migrated access control policy on management center.

    The protocols which are migrated as Prefilter tunnel rules are following:

    • GRE (47)

    • IPv4 encapsulation (4)

    • IPv6 encapsulation (41)

    • Teredo Tunneling (UDP:3544)

    Note	If you do not opt to select the prefilter option, all the tunneled traffic rules will be migrated as unsupported rules.

    The ACL tunnel rules (GRE and IPnIP) in the ASA configuration are currently migrated as bidirectional by default. You can now specify the Rule direction for the destination as bidirectional or unidirectional in the access control state option.

• The Secure Firewall migration tool supports the following interfaces and objects for VPN Tunnel migration:

  • Policy-based (Crypto Map)—If the target management center and threat defense is version 6.6 or later.

  • Route-based (VTI)—If the target management center and threat defense is version 6.7 or later.

• The Secure Firewall migration tool supports migration of Remote Access VPN if the target management center is 7.2 or later. Remote Access VPN is a shared policy that can be migrated without threat defense. If migration is selected with threat defense, the threat defense version should be 7.0 or later.

• (Optional) In the Optimization section, select Migrate only referenced objects to migrate only those objects that are referenced in an access control policy and a NAT policy.

  Note	When you select this option, unreferenced objects in the ASA configuration will not be migrated. This optimizes migration time and cleans out unused objects from the configuration.

• (Optional) In the Optimization section, select Object group search for optimal memory utilization by access policy on threat defense.
• (Optional) In the Inline Grouping section, the Secure Firewall migration tool allows you to clear the access rules of the pre-defined network and service object names that start with CSM or DM. If you uncheck this option, the pre-defined object names will be retained during migration. For more information, see Inline Grouping.

  Note	By default, the option of Inline Grouping is enabled.

• If you have SNMP and DHCP Server, Relay, and DDNS configurations on your source ASA device, the corresponding checkboxes are checked by default. Manually uncheck them if you do not want to migrate these configurations. Note that when DHCP is selected, you can either check Server or both Relay and DDNS.
• If you have group policies with SSL clientless VPN tunnel protocol configurations and tunnel groups with group policies that use SAML authentication, the migration tool checks the WebVPN checkbox by default. Ensure you manually uncheck this if you do not want to migrate these configurations.

Step 7

Click Proceed.

Step 8

In the Rule Conversion/ Process Config section, click Start Conversion to initiate the conversion.

Step 9

Review the summary of the elements that the Secure Firewall migration tool converted.

Step 10

Click Download Report and save the Pre-Migration Report.

Step 1

Navigate to where you downloaded the Pre-Migration Report.

Step 2

Open the Pre-Migration Report and carefully review its contents to identify any issues that can cause the migration to fail.

Step 3

If the Pre-Migration Report recommends corrective actions, complete those corrections on the ASA interface, export the ASA configuration file again and upload the updated configuration file before proceeding.

Step 4

After your ASA configuration file is successfully uploaded and parsed, return to the Secure Firewall migration tool, and click Next to continue the migration.

Step 1

If you want to change an interface mapping, click the drop-down list in the FTD Interface Name and choose the interface that you want to map to that ASA interface.

Step 2

When you have mapped each ASA interface to a threat defense interface, click Next.

Step 1

On the Map Security Zones, Interface Groups and VRFs screen, review the available interfaces, security zones, interface groups, and VRF configurations.

Step 2

To map interfaces to security zones and interface groups that exist in management center, or that is available in ASA configuration files as Security Zone type objects and is available in the drop-down list, do the following:

1. In the Security Zones column, choose the security zone for the interface.

2. In the Interface Groups column, choose the interface group for the interface.

3. In the VRF column, choose the VRF configurations for the interface.

Step 3

You can manually map or auto-create the security zones, interface groups, and VRFs.

Step 4

1. Click Add SZ, IG & VRF.

2. In the Add SZ, IG & VRF dialog box, click the edit icon, enter the name you want to give to the VRF, and click the green check mark. You can also edit the VRF name by clicking on the edit icon again.

   Note	If you are performing a merged-configuration migration and one of your contexts had VPN configuration, it does not get displayed here to be mapped to an interface, because it gets migrated to the global router directly.

3. Enter the security zone name in the Security Zone column. The maximum characters allowed is 48. Similarly, you can add an interface group.

4. Click Close.

1. Click Auto-Create.

2. In the Auto-Create dialog box, check one or both of Interface Groups and Zone Mapping.

3. Click Auto-Create.

Step 5

When you have mapped all interfaces to the appropriate security zones, interface groups, and VRFs, click Next.

Step 1

(Optional) On the Optimize, Review and Validate Configuration screen, click Optimize ACL in Access Control > ACP to run the optimization code, and perform the following:

1. Click Proceed to proceed with the ACL optimization, where the identified Redundant ACLs and Shadow ACLs rules for migration are displayed.

   The time taken for analyzing the ACL optimization depends on the source configuration file size. The estimation time is displayed.

   A report with the summary of total ACL rules considered for optimization is displayed. For more information on optimization report and its components, see Reporting for ACL Optimization.

   The Redundant ACL and Shadow ACL tabs appears only if there is data in the ACL optimization report.

   The ACLs are displayed in both Redundant and Shadow ACLs under different base rules.

   Note	An ACL entry that is displayed under the Redundant or shadow ACL, the same is not considered as the base ACL.

2. To download the identified ACL optimization rules, click Download Report.

3. Select rules and choose Actions > Migrate as disabled or Do not migrate and apply one of the actions.

4. Click Save.

   The migration operation changes from Do not migrate to disabled or vice-versa.

   You can perform bulk selection of rules, using the following options

   • Migrate—To migrate with default state.

   • Do not Migrate—To ignore the migration of ACLs.

   • Migrate as disabled—To migrate ACLs with State field set to Disable.

   • Migrate as enabled—To migrate ACLs will with State field set to Enable.

Step 2

On the Optimize, Review and Validate Configuration screen, click Access Control Rules and do the following:

1. For each entry in the table, review the mappings and verify that they are correct.

   A migrated Access Policy Rule uses the ACL name as prefix and appends the ACL rule number to it to make it easier to map back to the ASA configuration file. For example, if an ASA ACL is named "inside_access," then the first rule (or ACE) line in the ACL will be named as "inside_access_#1." If a rule must be expanded because of TCP or UDP combinations, an extended service object, or some other reason, the Secure Firewall migration tool adds a numbered suffix to the name. For example, if the allow rule is expanded into two rules for migration, they are named "inside_access _#1-1" and " inside_access_#1-2".

   For any rule that includes an unsupported object, the Secure Firewall migration tool appends an "_UNSUPPORTED" suffix to the name.

2. If you do not want to migrate one or more access control list policies, choose the rows by checking the box against the policy, choose Actions > Do not migrate and then click Save.

   All rules that you choose not to migrate are grayed out in the table.

3. If you want to apply a management center file policy to one or more access control policies, check the box for the appropriate rows, choose Actions > File Policy.

   In the File Policy dialog, select the appropriate file policy and apply it to the selected access control policies and click Save.

4. If you want to apply a management center IPS policy to one or more access control policies, check the box for the appropriate rows, choose Actions > IPS Policy.

   In the IPS Policy dialog, select the appropriate IPS policy and its corresponding variable set and apply it to the selected access control policies and click Save.

5. If you want to change the logging options for an access control rule which has logging enabled, check the box for the appropriate row and choose Actions > Log.

   In the Log dialog, you can enable logging events either at the beginning or end of a connection or both. If you enable logging, you must opt to send the connection events either to the Event Viewer or to the Syslog or both. When you opt to send connection events to a syslog server, you can choose the syslog policies that are already configured on the management center from the Syslog drop-down menu.

6. If you want to change the actions for the migrated access control rules in the Access Control table, check the box for the appropriate row and choose Actions > Rule Action.

   In the Rule Action dialog from the Actions drop-down, you can either choose ACP or Prefilter tabs:

   • ACP—Every access control rule has an action that determines how the system handles and logs matching traffic. You can either perform an allow, trust, monitor, block, or block with reset action on an access control rule.

   • Prefilter—A rule's action determines how the system handles and logs matching traffic. You can either perform a fastpath and block.

   Tip	The IPS and file policies that are attached to an access control rule are automatically removed for all rule actions except for the Allow option.

   ACL Rule Category—The Secure Firewall migration tool preserves the Rule sections in the CSM managed ASA configuration and migrates them as ACL categories on management center.

   Policy capacity and limit warning—The Secure Firewall migration tool compares the total ACE count for the migrated rules with the supported ACE limit on the target platform.

   Based on the comparison result, the Secure Firewall migration tool displays a visible indicator and a warning message if the total count of migrated ACE exceeds threshold or if it approaches the threshold of the supported limit of target device.

   You can optimize or decide not to migrate if the rules exceed the ACE Count column. You can also complete the migration and use this information to optimize the rules after a push on the management center before deployment.

   Note	The Secure Firewall migration tool does not block any migration despite the warning.

   You can filter the ACE counts in the ascending, descending, equal, greater than, and lesser than filtering order sequence.

   To clear the existing filter criteria, and to load a new search, click Clear Filter.

   Note	The order that you sort the ACL based on ACE is for viewing only. The ACLs are pushed based on the chronological order in which they occur.

Step 3

Click the following tabs and review the configuration items:

Step 4

(Optional) On the Network Objects and the Port Objects tabs, review all the network objects, network groups, port objects, port groups, and their values. To rename an object or object group, select the object and choose Actions > Rename.

Step 5

(Optional) While reviewing your configuration, you can rename one or more network, port, or VPN objects in the Network Objects tab or Port Objects tab, or the VPN Objects by choosing Actions > Rename.

Step 6

In the Dynamic-Route Objects section, all the supported objects that are migrated are displayed:

Step 7

In the Routes section, the following routes are displayed:

Step 8

Under the DHCP tab, you can review and validate the following tabs:

Step 9

Under the SNMP tab, you can review, validate, and work with the following tabs:

Step 10

In the Site-to-Site VPN Tunnels section, all the supported VPN tunnels that are migrated from ASA to management center are displayed, and includes the following lists.

Step 11

(Optional) Click Add Hub & Spoke Topology to configure a hub and spoke VPN topology using the target threat defense as the hub node and selecting one or more ASA peer interfaces as the spoke nodes.

Step 12

For configurations containing several site-to-site VPN tunnel configurations, to update the preshared keys for multiple entries at once, follow the steps below:

Step 13

In the Remote Access VPN section, all objects corresponding to remote access VPN are migrated from ASA to the management center, and are displayed:

Step 14

(Optional) To download the details for each configuration item in the grid, click Download.

Step 15

After you have completed your review, click Validate. Note that the mandatory fields that need your attention keeps flickering until you enter values in them. The Validate button gets enabled only after all the mandatory fields are filled.

Step 16

When the validation is complete, if the Validation Status dialog box shows one or more object conflicts, do the following:

1. Click Resolve Conflicts.

   The Secure Firewall migration tool displays a warning icon on either or both of the Network Objects or Port Objects tab, depending upon where the object conflicts were reported.

2. Click the tab and review the objects.

3. Check the entry for each object that has a conflict and choose Actions > Resolve Conflicts.

4. In the Resolve Conflicts window, complete the recommended action.

   For example, you might be prompted to add a suffix to the object name to avoid a conflict with the existing management center object. You can accept the default suffix or replace it with one of your own.

5. Click Resolve.

6. When you have resolved all object conflicts on a tab, click Save.

7. Click Validate to revalidate the configuration and confirm that you have resolved all object conflicts.

Step 17

When the validation is complete and the Validation Status dialog box displays the message Successfully Validated, continue with Push the Migrated Configuration to Management Center.

Step 1

In the Validation Status dialog box, review the validation summary.

Step 2

Click Push Configuration to send the migrated ASA configuration to management center.

Step 3

After the migration is complete, click Download Report to download and save the post-migration report.

Step 4

If your migration failed, review the post-migration report, log file, and unparsed file carefully to understand what caused the failure.

Step 1

Navigate to where you downloaded the Post-Migration Report.

Step 2

Open the post-migration report and carefully review its contents to understand how your ASA configuration was migrated:

Step 3

Open the Pre-Migration Report and make a note of any ASA configuration items that you must migrate manually on the threat defense device.

Step 4

In management center, do the following:

1. Review the migrated configuration for the threat defense device to confirm that all expected rules and other configuration items, including the following, were migrated:

   • Access control lists (ACL)

   • Network Address Translation rules

   • Port and network objects

   • Routes

   • Interfaces

   • IP SLA objects

   • Object Group Search

   • Time-based objects

   • VPN objects

   • Site-to-Site VPN Tunnels

   • Dynamic Route objects

2. Configure all partially supported, unsupported, ignored, and disabled configuration items and rules that were not migrated.

   For information on how to configure these items and rules, see the Management Center Configuration Guide. The following are examples of configuration items that require manual configuration:

   • Platform settings, including SSH and HTTPS access, as described in Platform Settings for Threat Defense

   • Syslog settings, as described in Configure Syslog

   • Dynamic routing, as described in Routing Overview for Threat Defense

   • Service policies, as described in FlexConfig Policies

   • VPN configuration, as described in Threat Defense VPN

   • Connection log settings, as described in Connection Logging

Step 5

After you have completed your review, deploy the migrated configuration from management center to the threat defense device.

Step 1

Use the show running-config command for the ASA device or context that you are migrating and save a copy of the ASA configuration. See View the Running Configuration.

Step 2

Review the ASA configuration file.

Step 3

Deploy the Firepower 2100 series device in your network, connect the interfaces and power on the appliance.

Step 4

Register the Firepower 2100 series device to be managed by the management center.

Step 5

(Optional) If your source ASA configuration has port channels, create port channels (EtherChannels) on the target Firepower 2100 series device.

Step 6

Download and run the most recent version of the Secure Firewall migration tool from https://software.cisco.com/download/home/286306503/type.

Step 7

When you launch the Secure Firewall migration tool, and specify destination parameters, make sure that you select the Firepower 2100 series device that you registered to the management center.

Step 8

Map the ASA interfaces with the threat defense interfaces.

Step 9

While mapping logical interfaces to security zones, click Auto-Create to allow the Secure Firewall migration tool to create new security zones. To use existing security zones, manually map the ASA logical interfaces to the security zones.

Step 10

Follow the instructions of this guide to sequentially review and validate the configuration to be migrated, and then push the configuration to the management center.

Step 11

Review the Post Migration report, manually setup and deploy other configurations to the threat defense and complete the migration.

Step 12

Test the Firepower 2100 series device using the test plan that you would have created while planning for migration.

Step 1

Connect to the ASA through the SSH console and switch to the interface configuration mode.

Step 2

Shutdown the ASA interfaces using the shutdown command.

Step 3

(Optional) Access the management center and configure dynamic routing for the Firepower 2100 series device.

Step 4

Clear the Address Resolution Protocol (ARP) cache on the surrounding switching infrastructure.

Step 5

Perform basic ping tests from surrounding switching infrastructure to the Firepower 2100 series device interface IP addresses, to make sure that they are accessible.

Step 6

Perform basic ping tests from devices which require layer 3 routing to Firepower 2100 series device interface IP addresses.

Step 7

If you are assigning a new IP address to the Firepower 2100 series device and not reusing the IP address assigned to the ASA perform the following steps:

Step 8

Run a comprehensive test plan and monitor logs within the managing management center for your Firepower 2100 device.