fbpx
ASA to Palo Alto Migration

Introduction

The next-gen firewall market is very dynamic but in the recent years there has been one vendor that really made an impact on the market and quickly became the Market Leader – Palo Alto is still going very strong and has been adding functionality and expanding its market share outside the firewall on-prem offerings. It has great product, excellent support and Value for Money, plus it is very stable.

A lot of companies are currently in the process of migrating out of their current firewall solution in favor of a new Palo Alto deployment. This article aims at sharing the migration steps, our expertise and best practices in doing a migration from Cisco ASA to Palo Alto Networks Firewall.

We have already outlined the difference between traditional and Next-Gen firewall and why companies around the word are slowly but surely migrating out of Cisco ASA (not supported anymore and at the end of its run) in the following article.

Migration Challenges

Each company we talked to has the same challenges – to improve their security without compromising the availability of their service.

This is exactly what we in Advanced Firewall Solutions will help you with. If have chosen the way of Palo Alto and their uncompromisable security, there will be need of replacing your legacy products, which mean migration.

How do we perform Cisco ASA to Palo Alto Networks migration?

The exact requirement from all our customers is the same – please replace the devices but with minimum downtime.

Migration of a network firewall takes careful planning.

We always follow these steps:

1. Prepare for the migration

Before the migration, we gather as much information as possible – network schemas, documents, the most current config, the customer requirements. Do a proper plan of the migration and following cutover, separate customer and own responsibilities and put dates and tracking system for how both sides are doing.

Talk to customer for the process of issuing a change freeze for the days needed before the cutover.

2. Migrate the firewall in AS-IT-IS fashion

You don’t want to introduce many changes to the network in one go, as its not always possible to foresee all things that can go wrong, so we keep it simple when doing a major migration to Palo Alto Networks firewall. Migrate out as closely as possible the original config of the legacy device and import to in the new one.

Of course, you can change things like interface (add port-channels to have link and port redundancy) but do not try to enable all features on the new device in a untested and production environment, our approach is to do the feature adding and optimization after the initial migration after achieving a steady state in the environment.

3. Use the vendor migration tools

The tools help automate the tedious parts of the migration (objects, long rulesets, routing) but be aware of their limitations and only use them if you have experience with them. Palo Alto has a great tool (build by PA itself) called Expedition, which can help you in lowering the time for a large and complex configuration-wise migration and can help you in not doing the typical copy and paste errors in manual labor.

Of course, such tools (Expedition) are not flawless and not easy to operate, hence our experience with them is of great value to our customers. There are numerous “underwater stones” that you can hit, depending on the original vendor and that could cause downtime upon cutover.

Fortunately the Cisco ASA is straight-forward to migrate out of due to the fact all config is readable and text based and it is a zone type of firewall (security level can be used as zones). Some caveats here are the per interface ACLs that are massively used in ASA compared to the global ACL in Palo Alto

4. Verify and Test your resulting firewall config

We always plan our migrations in a such way that we can test fully the L1-L3 connectivity of the new device before going live. We also deploy manual and automatic checks for different and crucial parts of the config – security rules, NATs, routing.

We go over the config with the customer representative as not to miss any vital details and concentrate on the critical resources.

5. Prepare for the cutover

We are a strong believer that preparation wins the battle.

During our migrations, we strive to have as easy and as stress free cutover as possible, with close to zero interference with customer operations.

What kind of preparation is mandatory?

  • Change documents – risk analysis and other needed to pass the change meeting
  • Runbook – We work with client to create a detailed Runbook of the actions to be executed in the cutover with exact times and responsibilities – who does what and exactly when
  • Detailed Test plan – pre-engage customer teams to test functionality of application and user experience at each major stage
  • Success criteria document – can be inside the Runbook, basically at certain points in the cutover, a quick evaluation must be made of the progress and result and a decision to continue or backout has to be made. Only after who runbook is played out and tests are successful the decision for closure of the successful cutover can be made
  • Backout plan – if things do not go as planned and decision is made to reverse you need to make sure you have the proper plan to do it.

6. Execute the cutover

You need to follow the plan and documents created before as part of the preparation, improvisation without real need is not welcome, skipping steps and tests is a big no-no. In our method we always engage multiple resources (consultants) on our end to make sure we can react immediately to any issues and parallely work on resolving them, a single person can be overwhelmed easily by multiple issues and cannot fully concentrate.

We are valued by our customers for providing smooth sailing experience in our migrations.

7. Next day support

Even with a detailed testing, there is always a chance of something being missed and an issue arising on next day or first major business day after the cutover.

We always plan for immediate ad-hoc support after successful migration and dedicate resources to be available to customer for chosen time-period.

Conclusion

Migration from Cisco ASA to Palo Alto Network is not easy, especially for your core network security vendor, a botched-up migration can sabotage a whole organization and can bring negatives to its IT management and department, plus direct losses from not utilizing new purchased gear that has time-based licenses.

We, at Advanced Firewall Solutions have the experience, skills and methodology to execute a perfect migration for you, that would enable you to take all the benefits from the new solution, without all the headaches.

Reach us for a friendly talk and scoping of a potential migration to Palo Alto Networks.