Migrating to Cisco Secure Firewall: TAC Best Practices

Introduction

Your organization has been running legacy firewall platforms for years, and the mandate has arrived: migrate to Secure Firewall Threat Defense. The stakes are high. A botched migration can leave critical traffic blocked, security policies misaligned, and your team scrambling to roll back changes under pressure. Whether you are transitioning from an older appliance or performing a hardware refresh between Secure Firewall models, following a disciplined, TAC-recommended approach is the difference between a seamless cutover and a weekend-long war room.

This article delivers a comprehensive, step-by-step walkthrough of the best practices for migrating to Cisco Secure Firewall Threat Defense. We cover the entire migration lifecycle, from stakeholder identification and tool installation through pre-migration analysis, configuration push, post-migration validation, and Firepower Management Center (FMC) model migration. Every recommendation in this guide reflects field-tested procedures used by TAC engineers to help customers execute successful firewall migrations at scale.

By the end of this guide you will understand how to plan your migration, leverage the Firepower Migration Tool (FMT) effectively, map interfaces and security zones, optimize access control rules before pushing them, validate your deployment with static and dynamic checks, and handle FMC-to-FMC model migrations when upgrading management platforms. Whether you are studying for your CCNP Security certification or leading a production migration project, this guide equips you with the knowledge to move forward with confidence.

Understanding the Migration Lifecycle

Before touching a single CLI command or opening the Firepower Migration Tool, it is essential to understand the full migration lifecycle. The process is not a single event but a series of deliberate phases, each with its own deliverables and checkpoints.

The Three Phases

The migration workflow breaks down into three major phases:

Getting Started (Pre-Planning) -- Identify stakeholders, create a User Acceptance Test (UAT) plan, download the Firepower Migration Tool or Security Cloud Control, choose your firmware version, provision the FMC and FTD, and install the Secure Firepower Migration Tool.
Pre-Migration (Execution) -- Upload the configuration or connect the source device to FMT, select the features to migrate, optimize and validate the migrated configuration, push the migrated configuration to FMC, deploy the configuration from FMC to FTD, and perform static validation of the User Acceptance Test.
Post-Migration (Verification) -- Perform dynamic validation of the User Acceptance Test, monitor device and network health, create a baseline, customize the health policy, and complete housekeeping and best practices tasks. Each phase feeds the next. Skipping stakeholder identification in phase one, for example, means you will not have a UAT plan to validate against in phase three. Treat the lifecycle as a linear pipeline where the output of one stage becomes the input to the next.

Behind the Scenes: Six Critical Checkpoints

Within these three phases, six key checkpoints determine success:

Checkpoint	Purpose
Identify Stakeholders	Ensure network, security, and application owners are aligned on scope, timeline, and success criteria
Installation (FMC, FTD, and FMT)	Provision all infrastructure and tooling before migration begins
Software Conformance	Validate that firmware versions on all components meet the migration requirements
Version Compatibility	Confirm that the source and target platforms are on a supported migration path
Features Available	Verify that every required feature exists on the target platform and FMC version
User Acceptance Test	Define clear pass/fail criteria before migration starts so success is objectively measurable

Pro Tip: Creating a thorough UAT plan before the migration begins is the single most impactful step you can take. Without predefined success criteria, you have no objective way to determine whether the migration succeeded.

How Does the Firepower Migration Tool Work?

The Firepower Migration Tool (FMT) is the primary utility for converting configurations from legacy platforms to Cisco Secure Firewall Threat Defense. Understanding its installation requirements and navigation flow is critical before you begin.

Installation and Prerequisites

Keep the following considerations in mind when installing and running FMT:

Air-gapped version: An air-gapped version of FMT is available on demand for environments without internet access.- System and file permissions: Ensure the account running FMT has the necessary file system permissions.
Pop-up blockers: FMT uses browser-based authentication. Disable pop-up blockers to avoid authentication failures.
Version currency: Always run the latest version of the Firepower Migration Tool. Uninstall any older versions before installing the current release.- Console requirement: The console window must stay open while the Secure Firewall Migration Tool is open and running. Closing the console terminates the migration session.

FMT Navigation Flow

The FMT interface guides you through a structured workflow. Understanding each screen helps you anticipate what information you need at each stage.

Source Device Selector -- The first screen presents a source device selector where you choose the firewall platform you are migrating from. Once selected, FMT displays guidelines and instructions specific to the source firewall vendor. These instructions detail the correct configuration extraction methods based on the source device type. Configuration Upload -- After selecting the source, you upload the configuration file or connect the source device directly to FMT. For platforms that support virtual systems (VSYS), FMT displays the extracted VSYS configurations and allows you to select which VSYS to migrate. Parsed Configuration Summary -- FMT parses the uploaded configuration and presents a summary of what was extracted, including the migration progress stage, the source device type, the extraction method used, and the VSYS configurations identified.

What Does the Pre-Migration Report Tell You?

The pre-migration report is one of the most valuable outputs of the Firepower Migration Tool. Before any configuration is pushed to the FMC, this report gives you a clear picture of what will migrate successfully, what failed to parse, and what was intentionally ignored.

Overall Summary

The overall summary section provides a high-level view of the configuration that will be successfully migrated. It includes:

Policy names and rule counts
Objects (network and service)
Logical interfaces
Applications
Static routes
VPN configuration

Configuration Lines with Errors

This section details configuration elements that could not be migrated successfully due to parsing issues within FMT. Common items that appear here include network objects and routes that FMT could not interpret correctly.

Pro Tip: When you encounter configuration lines with errors, the recommended approach is to fix them in the source configuration file and re-upload the corrected file to FMT. Do not attempt to manually recreate these elements on the target platform without first understanding why they failed to parse. Fixing at the source ensures consistency between what FMT reports and what actually exists on your firewall.

Ignored Configurations

The ignored configurations section lists all configuration elements that FMT deliberately skipped during migration. These are not errors -- they represent features or configuration constructs that FMT does not handle. Review every line in this section carefully. For each ignored element, verify whether the feature is supported in FMC. If it is supported but was ignored by FMT, you will need to recreate that configuration manually on the target platform after migration.

How to Select the Target Device When You Migrate to Secure Firewall

After reviewing the pre-migration report and confirming that the parsed configuration meets your expectations, the next step is selecting your target FMC and FTD.

Choosing the FMC

FMT presents a choice of FMC as the migration target. You connect FMT to your target FMC, which then displays the list of registered devices.

FMT also provides an option to proceed without selecting a specific FTD, which is useful for pre-staging configurations on the FMC before the physical hardware is available.

Feature Selection

The feature selection screen lets you choose which configuration components to migrate. A critical option on this screen enables you to filter out unused objects so that only referenced objects are migrated to the target platform.

Pro Tip: Enable the option to exclude unused objects during migration. Migrating thousands of stale, unreferenced objects clutters the FMC object store and makes ongoing management more difficult. Only migrate objects that are actively referenced by policies and rules.

Mapping Interfaces and Security Zones for Firewall Migration

Interface mapping and zone mapping are where the logical topology of your source device gets translated to the physical and logical topology of your target FTD. Getting this right is essential.

Interface Mapping

During interface mapping, FMT presents the source device interface list alongside the FTD device interface list. Your job is to map each source interface to the corresponding target interface.

A critical requirement applies here: the number of interfaces on the FTD must be greater than or equal to the number of interfaces on the source device. If your source device has more interfaces than the target FTD, you cannot complete the mapping, and the migration cannot proceed without consolidating interfaces on the source side first.

Zone Mapping

Zone mapping translates the security zones from your source device to zones on the target FMC/FTD. FMT supports two approaches:

Auto-creation: FMT can automatically create zones identical to the source device zones. Common zone names such as Inside, Outside, DMZ, VPN, Prod, Staging, Servers, and Guest are replicated on the target with identical naming. This approach works well when your target zone architecture mirrors the source.
Manual zone creation: You can manually create and map zones if your target architecture uses a different zone design. This is common when the migration is also an opportunity to restructure the security zone architecture.

Application Mapping

FMT handles application mapping in two stages:

Auto-mapping: FMT automatically maps applications from the source configuration to their equivalents in the Cisco application database. Most common applications map cleanly without intervention.
Manual mapping: Applications that cannot be auto-mapped require manual intervention. You select the appropriate target application from the complete application list.

How to Optimize and Validate Rules Before Pushing Configuration

The optimize, review, and validate phase is where you refine the migrated configuration before it touches the FMC. This is your last opportunity to clean up rules, disable unnecessary policies, and confirm that the migration output matches your expectations.

Optimization Actions

FMT provides two key optimization actions for individual rules:

Action	Behavior
Do not migrate	Rules are not pushed to FMC at all. Use this for rules you have confirmed are no longer needed.
Migrate as disabled	Rules are pushed to FMC but marked as disabled. They will not be deployed to FTD. Use this for rules you want to preserve for reference but not enforce immediately.

These two options give you granular control over which rules make it to the target platform. The "migrate as disabled" option is particularly valuable for rules that need further review -- they exist in the FMC for inspection and can be enabled later without re-running the migration. This approach is safer than "do not migrate" because the rule definition is preserved, even though it is not actively enforced.

Configuration Push

Once optimization is complete and you have reviewed the migration summary, the configuration push stage sends the migrated configuration to the FMC. During this phase:

Different configuration components are pushed separately (objects, policies, routes, and other elements are transferred as distinct configuration groups).
Configure sleep settings on your workstation to prevent FMT failures during large configuration migrations. If the machine enters sleep mode during the push, the FMT session can fail, requiring you to restart the process from the beginning.

Pro Tip: For large migrations with thousands of rules and objects, ensure your workstation power settings prevent sleep and screen lock during the push. A failed push midway through can leave partial configuration on the FMC that must be cleaned up before retrying. On enterprise-scale migrations, the push can take a significant amount of time depending on the number of objects and rules being transferred.

Understanding the Post-Migration Report

After the configuration push completes, FMT generates a post-migration report. This report serves as the authoritative record of what was migrated and how. It is the companion document to the pre-migration report and should be reviewed with equal rigor.

Migration Summary

The migration summary documents the configuration elements that were successfully migrated. Compare this against the pre-migration report to identify any differences or items that were dropped during the push. The migration summary should show the same counts and categories as the pre-migration report. If there are discrepancies, investigate them before proceeding to deployment.

Selective Policy Migration

This section provides details on the features you selected for migration, confirming which policy categories were included and which were excluded. It serves as an audit trail showing exactly what was requested and what was delivered.

Migration Conversions

The migration conversions section is the most detailed part of the post-migration report. It covers:

Network and service object handling -- How objects were translated from source to target format, including any name changes or format adjustments
Partially migrated configurations -- Elements that were only partially converted, along with reasons for the partial migration. These items require manual follow-up to complete the configuration on the target.
Unsupported configurations -- Features that could not be migrated at all, with explanations for why they are unsupported. These must be recreated manually if needed on the target platform.
Expanded access control rules -- Rules that were expanded or split during conversion. A single source rule may become multiple target rules due to differences in how the platforms handle rule logic.

Static and Dynamic Validations After Migrating to Secure Firewall

Post-migration validation is divided into two categories: static checks that verify configuration correctness without passing live traffic, and dynamic checks that validate behavior under real traffic conditions. Both are essential. Static checks catch configuration errors before they impact users, while dynamic checks confirm that the migrated firewall behaves correctly under production load.

Static Checks

Static validation should be performed immediately after the configuration push and before cutover to the new device:

Packet tracer -- Use the packet tracer utility to simulate traffic flows through the migrated policy and verify that packets are handled as expected. Test representative traffic flows from each security zone to confirm that access control rules, NAT translations, and routing decisions produce the correct outcomes.
Policy Analyzer Optimizer -- Review the migrated policies using the analyzer to identify redundant, shadowed, or conflicting rules. The analyzer can surface rules that will never match traffic because they are shadowed by higher-priority rules.
Best Practice Recommendations -- Review the system-generated best practice recommendations for your deployment. These recommendations highlight configuration patterns that deviate from recommended security postures.
System Health -- Confirm that the FTD device and FMC are reporting healthy status across all subsystems.
Baseline -- Establish a configuration and performance baseline before any live traffic hits the device. This baseline becomes your reference point for all subsequent comparisons.

Dynamic Checks

Dynamic validation occurs after the cutover when live traffic is flowing through the migrated firewall:

Elephant Flow Detection -- Monitor for elephant flows (very large, long-lived flows such as database replication or backup traffic) that may impact performance on the new platform.
Configured Traffic Blocks -- Verify that traffic being blocked matches your security policy intent and that no legitimate traffic is being dropped. Check connection events and syslog for unexpected denies.
System Health -- Continue monitoring device health under production load. Resource utilization patterns under live traffic may differ significantly from idle baselines.
Application Performance -- Validate that application performance meets baseline expectations. Look for increased latency, throughput degradation, or connection timeouts that could indicate policy or inspection issues.
Baseline -- Compare live performance metrics against the baseline established during static validation to identify any deviations.

Network Infrastructure Updates

After migration, several network-level updates may be required on surrounding infrastructure:

Static routes: Update any static routes on adjacent devices that refer to the firewall IP address, especially if the IP addressing scheme changed during migration.
Dynamic routing protocols: Ensure that routing neighbors see the FTD IP as the next hop for expected destinations. Verify that adjacencies form correctly and that route advertisements are received as expected.
ARP cache: Clear the Address Resolution Protocol (ARP) cache on the surrounding switching infrastructure to ensure traffic is forwarded to the new device rather than the old one.

Pro Tip: Clearing ARP caches on adjacent switches is one of the most commonly missed post-migration steps. Stale ARP entries can cause traffic to continue flowing to the old device or to be blackholed entirely. Clear ARP on all directly connected Layer 3 devices immediately after cutover. This single step prevents the majority of "traffic disappeared after migration" trouble tickets.

What Hardware Platforms Are Supported for Migration?

The supported source and target platforms vary by FMC version. Understanding which platforms are on supported migration paths is essential for planning your hardware procurement and migration timeline. The following table summarizes the currently shipping migration paths:

FMC Version	Source Platforms	Target Platforms
FMC 7.4.0	11XX Series: 1120, 1140, 1150; 21XX Series: 2110, 2120, 2130, 2140	31XX Series: 3105, 3110, 3120, 3130, 3140
FMC 7.6.1	41XX Series: 4110, 4120, 4140, 4150 (M4 Blades); 93XX Series: SM24, SM36, SM44 (M4 Blades)	New 42XX Series: 4215, 4225, 4245
FMC 10.0.0	41XX Series: 4112, 4115, 4125, 4145 (M5 Blades); 9300 Series: SM40, SM48, SM56 (M5 Blades); 1010 Series	New 12XX Series: 1210CE, 1210CP, 1210CX; New 61XX Series: 6160, 6170; New 220 Series

All the source and target devices listed are forward compatible, meaning that as new FMC versions are released, previously supported platforms continue to be valid migration sources and targets. This forward compatibility protects your migration investment -- you will not lose support for a previously valid migration path when upgrading the FMC.

How to Perform Firepower Device Migration Between FTD Appliances

Firepower Device Migration is the process of migrating configuration from one FTD appliance to another -- for example, during a hardware refresh where both the source and target are already running Threat Defense. This is distinct from migrating from a legacy platform using FMT and is specifically designed for scenarios where you are replacing one FTD with a newer or more capable FTD model.

Prerequisites for Device Migration

Before initiating a device-to-device migration, confirm the following prerequisites are met:

Same FMC domain: Both the source and target FTD must be registered to the same FMC (and the same domain within that FMC). Cross-domain or cross-FMC device migration is not supported through this workflow.
No active tasks: Ensure there are no active deployments, domain movements, or import/export tasks running on the FMC. Active tasks can conflict with the migration process and cause failures.
IP address changes: If the source device is still live, change the IP addresses of the interfaces on the target device. Interface IP addresses are copied from the source to the target during migration, so duplicate IPs will cause conflicts on the network.
NAT policy updates: Update NAT policies with the modified IP addresses after changing interface IPs to ensure NAT translations reference the correct addresses.
Certificate re-enrollment: Re-enroll device certificates on the target device if any were in use on the source. Certificates are device-specific and cannot be migrated.
HA parameters: Configure High Availability parameters such as monitored interfaces, failover trigger criteria, and interface MAC addresses on the target device.
Diagnostic interface: Configure the diagnostic interface manually, as it gets reset after migration and does not carry over automatically.
SNMP configuration: Configure SNMP using the platform settings for the device, as SNMP settings are not carried over during device migration.

Device Selection

When selecting the target device for a device-to-device migration:

FMT lists FTD-eligible target devices. Tags are displayed for ease of selection, helping you quickly identify the correct appliance in environments with many registered devices.
The target device will use Snort 3 as the detection engine even if the source device uses Snort 2. This is an important consideration -- Snort 2 rules may need review after migration to ensure compatibility with Snort 3. The migration from Snort 2 to Snort 3 affects intrusion rule syntax, rule actions, and detection behavior.
The target device version must be the same or higher than the source device version. You cannot migrate to a lower firmware version.
The mode of the device must be identical on both source and target (routed or transparent). You cannot change the device mode during migration.
Forward Error Correction is available on 25G and 100G interfaces on 31XX and 42XX platforms. If your deployment uses these high-speed interfaces, verify that FEC settings are compatible between source and target.

Chassis Manager Details for 4100/9300 Platforms

For migrations involving 4100 or 9300 series devices, an additional step extracts configuration from the chassis manager. These platforms have a two-tier management architecture where some configuration lives at the chassis level rather than the FTD application level. This step captures:

Port-channel (PO) configurations -- Aggregated interface settings from the chassis level, including member interfaces, LACP parameters, and load-balancing algorithms
Interface attributes -- Physical interface settings managed at the chassis layer rather than the FTD application layer, such as speed, duplex, and media type

Interface Mapping Options for Device Migration

Device-to-device migration offers three interface attribute handling options:

Option	Behavior
Default (Retain Target)	Interface attributes from the target device are retained. The target keeps its existing speed, duplex, and negotiation settings. This is the safest option when the target has already been configured with correct physical layer settings.
Copy from Source	Interface attributes are copied from the source to the target device. Speed, duplex, and auto-negotiation values are set to default if the copied values are incompatible with the target hardware.
Custom	Interface attributes are customized from their default settings. You define each parameter manually, giving you full control over the physical layer configuration.

Only data interfaces are listed for interface mapping. Management interfaces are handled separately and are not part of the migration mapping workflow.

Executing the Migration

After reviewing the interface mapping summary, follow this sequence:

Review the complete interface mapping summary to confirm all mappings are correct.
Proceed with "Submit" to initiate the migration task.
Click "Submit" again to confirm and start the process.
Monitor progress through the task notification system in the FMC.
Once completed, you receive a notification along with a "Download Report" option.

An important behavior to note: the device will not be automatically deployed as part of the migration process; it will only be configured. You must manually deploy the configuration from FMC to the target FTD after the migration task completes. This gives you an opportunity to review the migrated configuration on the FMC before pushing it to the device -- an intentional safety measure that prevents untested configuration from reaching the production firewall.

FMC Model Migration: Upgrading Your Management Platform

In addition to migrating firewall appliances, organizations sometimes need to migrate from one FMC to another -- for example, when upgrading to a higher-capacity management center, replacing end-of-life hardware, or moving to a newer FMC version that supports additional features and platforms.

Prerequisites for FMC Model Migration

FMC model migration has its own set of prerequisites that differ from device migration:

Target FMC should not have managed devices: The target FMC must be clean with no devices registered to it. Any existing device registrations on the target will conflict with the migration.
No High Availability: The target FMC should not be part of a High Availability pair during the migration process.
No active tasks: FTD registration, deployment, and backup tasks should not be running during migration on either the source or target FMC.
Supported migration path: Confirm that your source-to-target FMC combination is on the supported migration path list. Not all FMC model combinations are supported.
Classic license handling: Classic licenses are not available for FMC version 7.6 and later, as NGIPS is not supported. Before model migration, you must delete existing classic licenses from the source FMC.
Backup availability: Ensure you have a valid, recent backup from the source FMC before beginning. The backup file is the input to the migration script.

Migration Workflow for FMC Model Migration (Pre-10.0.0)

For FMC versions prior to 10.0.0, the migration workflow requires deleting existing classic licenses on the source FMC before initiating the model migration. This step is mandatory because the target FMC running 7.6 or later cannot import classic license configurations. Failing to remove classic licenses before creating the backup will cause the migration script to fail on the target.

Running the Migration Script

The actual FMC model migration is executed via a command-line script on the target FMC:

Log in to the target management center CLI.
Run the expert command to switch to expert mode.
Execute the migration command, providing the path to the source FMC backup file.

expert
root@firepower:# /var/sf/bin/sf-migration.pl /var/sf/backup/source_local_backup

The script takes the backup file path as its argument and handles the restoration of policies, objects, device registrations, and configuration from the source FMC onto the target. The migration script processes the backup file sequentially, restoring each configuration category in the correct dependency order.

Post-Migration Activities for FMC Model Migration

After the migration script completes on FMC version 7.4.x and later, update the following parameters as needed:

IP address of the target FMC: If the target FMC uses a different IP address than the source, update it in all relevant configurations and documentation.
FMC address on managed devices: If the IP address of the FMC changes, edit the FMC address in the threat defense devices so they can re-establish communication with the new management center. Note that this step is not required if the management connection is initiated from the FMC side rather than from the managed devices.

Frequently Asked Questions

What is the Firepower Migration Tool and when should I use it?

The Firepower Migration Tool (FMT) is a utility that converts firewall configurations from legacy platforms to Cisco Secure Firewall Threat Defense format. Use FMT when migrating from an older platform to a new FTD appliance managed by FMC. FMT handles the translation of access control rules, NAT policies, objects, interfaces, routes, and VPN configurations. Always run the latest version and uninstall any older versions before beginning. An air-gapped version is available for environments without internet access.

Can I migrate to Secure Firewall without connecting a target FTD device?

Yes. During the target selection phase, FMT provides an option to proceed without selecting a specific FTD. This allows you to pre-stage the migrated configuration on the FMC before the physical target hardware is available. Once the FTD is provisioned and registered to the FMC, you can assign the pre-staged policies and deploy. This approach is useful for planning and pre-validation when hardware delivery timelines do not align with the migration schedule.

What happens to Snort 2 rules when migrating to a new FTD appliance?

When performing a device-to-device migration, the target device will use Snort 3 as the detection engine even if the source device uses Snort 2. This means your intrusion rules and detection policies may need review after migration to confirm they behave as expected under the Snort 3 engine. Test thoroughly during the static and dynamic validation phases to ensure no detection gaps are introduced.

Do I need to clear ARP caches on adjacent switches after migration?

Yes. Clearing the ARP cache on the surrounding switching infrastructure is a critical post-migration step. Stale ARP entries can cause traffic to continue being directed to the old device or to be dropped entirely. Clear ARP on all directly connected Layer 3 devices immediately after the cutover to the new firewall. For dynamic routing protocols, also ensure that neighbors see the FTD IP as the next hop for expected destinations.

What are the requirements for FMC model migration?

The target FMC must not have any managed devices, must not be part of a High Availability pair, and must not have active tasks such as FTD registration, deployment, or backup running. You must also confirm that your source-to-target FMC combination is on the supported migration path. For FMC version 7.6 and later, classic licenses must be deleted before migration because NGIPS is no longer supported. A valid backup from the source FMC is required as the input to the migration script.

How do I handle interface attribute incompatibilities during device migration?

During device-to-device migration, if you choose to copy interface attributes from the source to the target, speed, duplex, and auto-negotiation values are automatically set to default if the copied values are incompatible with the target hardware. Alternatively, you can retain the target device's existing attributes using the default option or customize each parameter manually using the custom option. Forward Error Correction is available on 25G and 100G interfaces on 31XX and 42XX platforms.

Conclusion

Successfully migrating to Cisco Secure Firewall Threat Defense requires disciplined planning, thorough tool preparation, and rigorous post-migration validation. The migration lifecycle -- from stakeholder identification through dynamic validation -- provides a structured framework that TAC engineers rely on to execute migrations with minimal risk and maximum confidence.

Key takeaways from this guide:

Plan before you execute. Identify stakeholders, create a UAT plan, and verify software and version compatibility before touching the migration tool.
Leverage the pre-migration report. Review every error and ignored configuration line. Fix issues in the source configuration and re-upload rather than trying to patch them on the target.
Filter unused objects. Enable the option to exclude unreferenced objects to keep your FMC clean and manageable.
Optimize before you push. Use the "do not migrate" and "migrate as disabled" options to control exactly which rules reach the target platform.
Validate in two stages. Static checks (packet tracer, policy analyzer, baseline) should precede dynamic checks (elephant flow detection, application performance, traffic block verification).
Clear ARP caches. This commonly missed step can cause traffic blackholes after cutover.
Understand device migration specifics. Target devices use Snort 3 regardless of source, version must be equal or higher, and device mode must match.
Prepare for FMC model migration separately. Delete classic licenses before migrating to FMC 7.6 or later, and run the migration script from the target FMC CLI using the source backup file.

Firewall migration is a high-stakes activity, but with the right preparation and adherence to TAC-recommended best practices, you can execute it confidently and minimize disruption to your network. The tools, reports, and validation procedures described in this guide give you a repeatable framework that scales from single-site deployments to enterprise-wide migration programs.