Migrating from Cisco ASA to Palo Alto NGFW: A Step-by-Step Field Guide

Overview

Migrating from Cisco ASA to Palo Alto is one of the most common firewall replacement projects in enterprise networks today. The challenge isn't just technical — it's doing it without impacting production. This guide covers the full migration lifecycle: pre-migration audit, policy translation, NAT, VPN cutover, and post-migration validation.

Audit what needs to migrate

Document everything before you touch the PA. Screenshot show conn count during peak hours — this tells you expected session volume for capacity planning.

Phase 2 — Expedition Migration Tool (Automated Approach)

Palo Alto's Expedition (formerly the Migration Tool) is a free VM-based appliance that parses an ASA running config and auto-converts objects, NAT rules, and security policies into PAN-OS format. On a large firewall with thousands of rules it can save days of manual work. On a simple firewall it is still useful for catching object naming inconsistencies you would otherwise miss.

Expedition does not replace review. Treat its output as a first draft, not a finished config. Plan 2–4 hours of post-conversion cleanup regardless of firewall size.

2.1 — Deploy the Expedition VM

Expedition is distributed as an OVA. It requires an Ubuntu 20.04-based VM with at least 4 vCPUs, 8 GB RAM, and 100 GB disk. You access it entirely through a browser.

# Download from Palo Alto support portal (login required)
# support.paloaltonetworks.com → Software Downloads → Expedition
# Download: Expedition-1.x.x.ova

# Deploy in VMware ESXi or Workstation — import the OVA
# Power on and note the IP shown on the console (DHCP by default)
# Or assign static IP via console:
ubuntu@expedition:~$ sudo nano /etc/netplan/00-installer-config.yaml
# Set your static IP, gateway, DNS
ubuntu@expedition:~$ sudo netplan apply

# Access Expedition web UI
# https://<expedition-ip>  (self-signed cert — accept the warning)
# Default credentials: admin / paloalto
# Change the password immediately on first login

2.2 — Prepare the ASA Config Export

Expedition needs the full ASA running config as a plain text file. Capture it cleanly — partial configs cause incomplete migrations.

# On the ASA — disable paging and capture everything
ASA# terminal pager 0
ASA# show running-config

# Copy the full output to a .txt or .cfg file on your workstation
# Filename example: asa-fw01-running.cfg

# Also export the object-group and access-list detail for cross-reference
ASA# show object-group
ASA# show access-list
ASA# show nat detail
ASA# show route

# Export to TFTP if you want a clean file without terminal artifacts
ASA# copy running-config tftp://192.168.1.10/asa-fw01-running.cfg

2.3 — Create a Project and Import the ASA Config

# In the Expedition web UI:
# 1. Click "Projects" → "Add Project"
#    Name: ASA-Migration-FW01
#    Description: ASA FW01 to PA-3220 migration
#    Click Create

# 2. Inside the project → "Devices" → "Add Device"
#    Source Vendor: Cisco
#    Source OS: ASA (select version — e.g. 9.x)
#    Device Name: ASA-FW01

# 3. Upload config file
#    Click the device → "Import Configuration"
#    Upload: asa-fw01-running.cfg
#    Expedition parses and validates the file
#    Any parse errors appear here — fix them in the config file if needed

2.4 — Run the Migration

# In the project → "Migration" tab
# Source device: ASA-FW01
# Target PAN-OS version: match your PA hardware (e.g. PAN-OS 10.2)
# Target device type: Panorama or standalone firewall

# Migration options to configure:
#   Zone mapping — define which ASA interface maps to which PA zone
#   Example: outside (ASA) → untrust (PA)
#            inside  (ASA) → trust   (PA)
#            dmz     (ASA) → dmz     (PA)

# Click "Migrate" — Expedition processes the config
# A progress bar shows: Objects → NAT → Security Policies → Routes
# Typical time: 30 seconds to 5 minutes depending on config size

# After completion — review the Migration Report
# The report shows:
#   - Objects converted successfully
#   - Rules converted successfully
#   - Items that could not be converted (requires manual action)
#   - Warnings (shadowed rules, any/any rules, etc.)

2.5 — Review and Clean Up in Expedition

Before exporting, use Expedition's built-in analysis tools to clean up the converted policy. This is where the real value is — Expedition can find problems in your existing ASA config that you did not know about.

# Policy Optimiser — finds redundant and shadowed rules
# In project → "Policy" → "Optimisation"
#
# Run: "Shadowed Rules" analysis
#   Shows rules that are never hit because an earlier rule matches first
#   Action: delete or reorder shadowed rules
#
# Run: "Unused Objects" analysis
#   Address and service objects referenced by no rule
#   Action: delete to keep the object database clean
#
# Run: "Rule Usage" (requires log import — optional)
#   Import ASA syslog or ASDM CSV export to identify never-hit rules
#   Action: candidates for removal after stakeholder sign-off

# Check App-ID conversion
# Expedition maps port-based ASA rules to PA App-ID equivalents
# Example: tcp/443 → ssl  |  tcp/80 → web-browsing  |  tcp/25 → smtp
# Review each mapping carefully — not all port→app translations are correct
# Rules with unusual ports will remain port-based — convert manually if needed

# Check NAT rules
# ASA NAT order (section 1 / section 2 / section 3) maps to PA NAT rule order
# Verify: static NAT, dynamic PAT, NAT exemptions all appear correctly
# PA evaluates NAT top-to-bottom — order matters, same as ASA

2.6 — What Expedition Converts Well vs. What Needs Manual Work

2.7 — Export and Import to Panorama or PA Firewall

# Export from Expedition
# In project → "Export" → choose target:
#   "PAN-OS Configuration" — produces a candidate config XML
#   "Panorama Device Group + Template" — recommended for Panorama-managed PAs

# Download the exported XML file

# Option A: Import directly to a standalone PA firewall
# PA WebUI → Device → Setup → Operations → Import Named Configuration Snapshot
# Upload the XML → then Load Named Configuration → Commit
# WARNING: this replaces the candidate config — do on a fresh or lab PA only

# Option B: Import to Panorama
# Panorama → Device Groups → Import
# Expedition's Panorama export creates device group objects and policies
# Review in Panorama before pushing to managed firewalls

# Option C: API push (advanced — Expedition can push directly)
# In Expedition → "Target Devices" → add your PA firewall with API key
# Expedition pushes the converted config via PAN-OS API
# Still commits to candidate config only — you do a final review and commit

2.8 — Post-Import Validation in PAN-OS

After importing the Expedition config, validate it in the PA before any cutover.

# In PA WebUI — Objects → Addresses
# Verify: object count matches ASA object-group count (roughly)
# Look for: objects named "migration_*" — Expedition prefix for auto-created objects

# Policies → Security
# Sort by "Hit Count" if pushing to an existing device — new rules show 0
# Check: no rules with "any" in both source and destination zone + any application
# Verify: deny rules are present (ASA implicit deny becomes an explicit deny-all)

# Policies → NAT
# Verify rule count and order matches your ASA NAT table
# Test each NAT rule with the PA CLI:
admin@PA# test nat-policy-match source 10.1.1.50 destination 8.8.8.8 destination-port 80 protocol 6 from trust to untrust
# Shows which NAT rule would match — compare against ASA nat translation output

# Test security policy match
admin@PA# test security-policy-match source 10.1.1.50 destination 8.8.8.8 destination-port 443 protocol 6 from trust to untrust application ssl
# Shows which security rule would match and the action (allow/deny)

# Validate config (catches missing references, zone errors)
admin@PA# validate full
# Must return: "Configuration is valid" before committing

Phase 3 — Interface and Zone Mapping

ASA uses security levels (0-100). Palo Alto uses named zones. You must redesign this.

ASA security levels → PA zones

PA interface configuration

Phase 4 — Security Policy Translation

ASA ACLs become PA security policies. The logic is similar but the structure is different.

ASA ACL example

Equivalent PA security policy

App-ID vs port-based: PA uses App-ID by default. If migrating port-based ASA rules, use service: <port> instead of application-default initially, then gradually convert to App-ID after validation.

Phase 5 — NAT Policy Migration

ASA NAT and PA NAT have different ordering logic. This is the most error-prone part.

ASA NAT types → PA equivalents

ASA PAT rule

Equivalent PA NAT rule

NAT exemption for VPN traffic

Phase 6 — VPN Migration (Site-to-Site IPSec)

ASA site-to-site VPN → PA IPSec tunnel

Critical: PA requires explicit Proxy IDs when the peer is a Cisco ASA. Without them, Phase 2 will fail with INVALID_ID_INFORMATION.

Phase 7 — Cutover Procedure

Recommended cutover sequence

Phase 8 — Post-Migration Validation

Common Migration Mistakes