Legend
Introduction
The Firewall Migration Tool helps organizations move firewall configurations from and such as Check Point, Palo Alto, Fortinet, and Juniper into Cisco Firepower Threat Defense () under fixed cutover windows and little room for operational error.
Redesigning how network operators plan, validate, and execute firewall migrations, turning fragmented workflows into a more guided and auditable migration experience.
These migrations typically happen during hardware refreshes, platform consolidation, or broader security modernization efforts, often across , multi-context devices, and parallel migration jobs. For Cisco, is strategic infrastructure: the easier and safer migrations become, the easier it is for organizations to move existing firewall environments into the Cisco ecosystem.
Discovery work mapped the existing migration experience end to end: parsing inconsistencies on complex NATs, unsupported or partially converted configurations, fragmented validation flows, and review steps spread across multiple screens and external references. Operators frequently depended on Cisco support to navigate migrations confidently, especially during high-risk cutover windows.
The core UX problem was not the absence of functionality, but the operational overhead around it. Important migration context, validation states, mapping decisions, and remediation steps were distributed across disconnected flows, making migrations harder to review, reason about, and execute confidently at scale.
The redesign focused on consolidating workflows, improving visibility into migration readiness, simplifying high-density review states, and creating a more structured path from extraction through validation and deployment, without overwhelming operators with dashboard-heavy interfaces that become difficult to navigate under real configuration volume.
Complexity & constraints
Workshop readouts, customer feedback, and competitive audits across tools such as Fortinet FortiConverter, Check Point SmartMove, and Palo Alto Expedition surfaced a consistent pattern: migrations became difficult once configurations grew beyond straightforward rule sets.
The core challenge was not moving firewall policy from one platform to another. It was helping operators understand what translated cleanly, what required intervention, and what could impact during cutover.
- Complex NAT structures and vendor-specific syntax did not always parse reliably, forcing operators to manually review or rebuild portions of policy
- Converted configurations often carried forward redundant objects, duplicated rules, and legacy structure that still required cleanup after migration
- Validation and remediation were fragmented across multiple steps, making it difficult to track migration readiness confidently
- Dependency chains across interfaces, zones, objects, and HA configurations were difficult to reason about at scale
- High-risk actions such as validation, push, rollback, and parallel migrations lacked clear operational checkpoints
- Interface and zone mapping screens carried high information density, where small mistakes could propagate into production environments
- Operators frequently relied on manual review and Cisco support during migration windows, especially for larger or more complex configurations
- Post-migration cleanup and optimization often became a separate operational effort, reducing trust in automation-assisted migration flows
The discovery phase mapped the migration lifecycle from extraction through validation and push, identifying where operators lost visibility, confidence, and workflow continuity across the process.
“Competing tools already offered strong validation flows, making workflow clarity and operator confidence critical parts of the experience.”
Information architecture
The redesign had one job: make the migration understandable before anything reaches production.
The earlier experience spread migrations across fragmented stages including extraction, parsing, target setup, mapping, validation, review, and push. Operators frequently moved between disconnected screens and validation states, making it difficult to maintain confidence and workflow continuity during larger migrations.
The redesign consolidated that experience into four structured phases:
- Select source and target firewalls
- Map interfaces, zones, and applications
- Validate readiness and resolve action items
- Push with confirmation and progress tracking
The underlying workflow still handled operational sub-steps such as extraction, target configuration, mapping, review, validation, optimization, and push execution, but the experience grouped them into a clearer progression with fewer context switches.
Each phase answered one operational question before the next unlocked. The goal was not reducing functionality, but reducing the amount of migration state operators needed to hold in memory at once.
A persistent header carried migration identity and source-to-target context throughout the workflow, while the stepper grouped related sub-steps together so operators could maintain orientation even across long-running migrations, handoffs, and parallel jobs.
Earlier experience
9 steps- 1Entry & project setup
- 2Configuration extraction
- 3Parsing & conversion
- 4Target selection
- 5Device & HA setup
- 6Interface & zone mapping
- 7Validation (scattered)
- 8Review (disconnected)
- 9Push configurations
Guided flow
4 phases- 1Select firewalls (source + target with extraction)
- 2Map interfaces, zones, and applications
- 3Validate readiness and resolve action items
- 4Push with confirmation and progress tracking
“Collapsing nine fragmented stages into four structured phases gave operators a single mental model to carry across vendor and target variants.”
Interface & zone mapping
Interface and zone mapping became one of the highest-friction parts of the migration flow. Operators were translating firewall logic between different environments, often across large rule sets where small mistakes could surface much later during validation or cutover.
The redesign moved validation closer to the mapping process itself, helping operators catch mismatches while interfaces and zones were still being configured instead of discovering them later during review.
Mapping with automation boundaries
Interface mapping stayed manual, with validation feedback integrated directly into the workflow. Security zones auto-mapped where naming aligned, while override controls handled ambiguous or unsupported matches. Batch actions supported large rule sets without removing row-level visibility and control.
Review & validation
Validation was where operator confidence consistently broke down.
By the time migrations reached review, teams needed a clear understanding of what was ready, what still required intervention, and what could potentially impact production during deployment.
Review
The review flow consolidated compatible configurations, unresolved action items, optimization suggestions, and migration readiness into a single layer. Operators could resolve unsupported rules, naming conflicts, and bulk edits before entering validation.
Validation & conflict resolution
Pre-migration validation surfaced categorized issues with drill-down visibility into conflicts and dependencies. Operators could resolve issues in context, rerun validation, and compare results across runs while maintaining audit visibility throughout the migration lifecycle.
Configuration optimization
After validation, optimization offered optional policy cleanup before cutover. Operators could start analysis from the migration flow, review anomaly summaries by category, drill into selected rules and objects, and save preferences that committed only during migration. Suggestions stayed explainable and opt-in throughout.
Key design decisions
Every major interaction had to answer one question: could an operator confidently move forward without second-guessing the system?
Checkpoints before irreversible actions
Validation, review, and push were treated as explicit workflow states instead of passive confirmations. Critical issues blocked deployment, while remediation paths stayed attached directly to affected configurations.
Progressive disclosure over dashboard density
The earlier experience exposed too much migration state at once. The redesign focused each step around a single operational decision, surfacing review tables, diff views, and optimization suggestions only when they became actionable. Progress and migration state remained visible throughout the flow.
Errors that help operators recover
Warnings and unsupported configurations were grouped by severity instead of presented as flat error lists. High-severity issues required acknowledgment, while remediation paths linked directly to documentation and in-flow fixes.
AI suggestions stay operator-controlled
optimization suggestions explained why rules were flagged and allowed operators to accept or reject changes individually. Suggested changes never silently modified policy and remained visible through audit history.
Credentials and trust boundaries
Connection status, extraction logs, and device metadata remained visible throughout migrations so operators could verify what the system touched during extraction and push operations.
“I need to see validation status and what's still open before I approve a cutover, not dig through logs after the fact.”
Push & deployment
The final phase treated cutover as a monitored operation, not a single confirmation click. Operators reviewed what would migrate, what was intentionally skipped, and how each configuration category would land on the target before starting push.
Systems thinking
Edge cases were treated as part of the product flow, not exceptions outside it.
The migration framework handled multi-context flows, and targets, HA scenarios, partial parsing failures, and parallel migrations within the same structural shell. Headers, steppers, status language, and review patterns stayed consistent across migration types so operators could transfer familiarity between workflows instead of relearning the system each time.
Shared migration shell
Headers, phased steppers, and footer actions repeated consistently across migration types to maintain workflow continuity.
Status semantics
Migration status, substatus, validation state, and push progress used the same vocabulary throughout the product, reducing ambiguity across review and deployment flows.
Review patterns
Review summaries expanded into detailed rule, object, VPN, and access-list views without breaking migration context, using the same interaction patterns across workflows.
One framework across target types
, , and targets reused the same migration structure with target-specific variations layered where required, reducing one-off workflows while still respecting platform differences.
Final reflection
Trust in migration tooling is earned during review and validation, not during a product demo.
Discovery mapped where operators lost confidence across the migration lifecycle: fragmented validation flows, unclear remediation paths, dense review states, and limited visibility into migration readiness during high-risk deployment windows.
The redesign focused on making migrations easier to follow, validate, and reason about at scale. Structured phases, clearer review checkpoints, inline validation, and more consistent workflow patterns helped reduce operational overhead without hiding the underlying complexity of the migration itself.
One constraint stayed consistent throughout the project: operators needed enough visibility to trust the migration, but not so much information that review became difficult to manage under real configuration volume. That balance shaped nearly every workflow decision across the product.