Migrating from Cisco ASA to Palo Alto: A Practical Cutover Outline

Cisco ASA firewalls have protected a huge number of networks, and many organizations are now moving to Palo Alto Networks next-generation firewalls. The migration itself is very manageable, but only if you treat it as a redesign with a careful cutover, not a copy-and-paste exercise. This outline covers the phases we follow and the details that most often cause trouble.

Phase 1: Discovery and inventory

Start by documenting what the ASA actually does, not what everyone remembers it doing.

• Export the running configuration, including objects, object groups, access lists, NAT, VPNs, routing and failover.
• Record ACL hit counts with show access-list to identify rules that have not matched in a long time.
• List every site-to-site VPN peer, its crypto settings and the networks it protects.
• Document remote-access VPN usage, authentication sources and client versions.
• Identify dynamic routing, multicast, inspection policies and any services the ASA provides, such as DHCP.

Phase 2: Map the design to zones

ASA interfaces and security levels become Palo Alto security zones. This is where behavior changes:

• On an ASA, traffic from a higher security level to a lower one is allowed by default unless an ACL says otherwise.
• On Palo Alto, traffic between different zones is denied by default, and traffic within the same zone is allowed by default. Every interzone flow needs an explicit rule.
• Implicit behavior that people relied on, sometimes for years, must be written down as explicit policy.

This is also the right moment to improve segmentation. If several networks share one ASA interface today, consider whether they deserve their own zones.

Phase 3: Convert objects, policy and NAT

Conversion tools save time on objects and rule translation, but every converted rule should be reviewed. Pay particular attention to NAT:

• ASA NAT is evaluated in sections: manual (twice) NAT first, then auto NAT, then after-auto manual NAT. Palo Alto evaluates NAT policy top-down in a single rulebase, so the order must be rebuilt deliberately.
• On Palo Alto, security rules for destination-NAT traffic match the original, pre-NAT destination IP address together with the post-NAT destination zone. Getting this wrong is the most common reason published services fail after cutover.
• Remove ACL entries with zero hits only after confirming with application owners, or convert them first and remove them after cutover based on Palo Alto hit counts.

Phase 4: Rebuild VPNs

Site-to-site VPNs on the ASA are usually policy-based with crypto maps. On Palo Alto they are route-based, using tunnel interfaces. When the remote peer is still policy-based, you need proxy IDs on the Palo Alto side that exactly match the remote encryption domains. Mismatched proxy IDs are a classic cause of tunnels that come up but pass no traffic.

Remote-access users move from AnyConnect to GlobalProtect. Plan the client rollout, portal and gateway configuration, certificates and authentication, ideally SAML with multi-factor authentication, before cutover day. See our GlobalProtect consulting page for design considerations.

Phase 5: Decide your App-ID strategy

A converted ASA policy is port-based. You can either convert everything to App-ID before cutover, or cut over with port-based rules and modernize afterward. For most organizations the second approach is safer: preserve behavior at cutover, then use traffic logs and the Policy Optimizer to convert rules to App-ID with the application-default service in planned stages.

Phase 6: Pre-stage and validate

• Install a supported, recommended PAN-OS release and current content updates before cutover.
• Activate licenses and subscriptions, and attach security profile groups to allow rules.
• Load the configuration and test critical flows, NAT and VPNs in a lab or on an isolated segment.
• Configure logging, log forwarding and administrator access before go-live.
• Write a test plan with application owners: who tests what, and what success looks like.

Phase 7: Cutover

A good cutover is boring. Prepare a written runbook with timings and owners, and include:

• A change freeze on the ASA in the days before cutover.
• Fresh backups of both configurations.
• The physical or logical swap of cabling and interfaces.
• Clearing ARP caches on upstream routers and switches, because they may still hold the ASA’s MAC address for the same gateway IP.
• Running the test plan immediately after the swap.
• Clear rollback criteria and a time limit, decided in advance, for switching back to the ASA.

Phase 8: Stabilize and modernize

For the first days after cutover, watch traffic logs for unexpected denies and applications identified differently than expected. Then start the modernization work: App-ID conversion, decryption, User-ID and cleanup of rules that never match. Keep the ASA configuration archived, and decommission the hardware once you are confident rollback is no longer needed.

Migration checklist

• Configuration exported and documented, with hit counts
• Zones designed and interzone flows written as explicit rules
• NAT order rebuilt and pre-NAT addresses used in security rules
• VPN proxy IDs matched to every policy-based peer
• GlobalProtect ready, with client rollout planned
• Supported PAN-OS release, current content and licenses
• Test plan agreed with application owners
• Runbook, rollback criteria and ARP plan written down

Related: Palo Alto firewall consulting · What a Palo Alto firewall health check includes