PIX to ASA – How to migrate?

Yes, I’ve been gone for a while. I’m busy with my Exchange work and studies and with everything else around me I hardly get to even look at my home lab. But as they say, good things happen to those who wait and we’re upgrading our company PIX to ASA so I have some real use for my Cisco knowledge.

When coming to perform this task there are few things to remember, I’ll review the most important points (at least as I see it).

First there is the technical detail – End-of Sale and End-of-Life for PIX is past due. The important meaning is that Cisco will not support PIX (so go ahead and either upgrade to ASA or find another solution), if you have issues with existing PIX you’re not going to get Cisco’s help and if (god help you) your hardware will die, you’re doomed…

You can always migrate manually (and there are some benefits here, I’ll get to it in a sec) or take the shortcut and use the configuration migration tool. If you’re not sure which option fits your knowledge and experience I bet the migration tool is your option, for the rest of you – read further to get the main points of each option.

So now that you’ve decided on performing the upgrade using the migration tool, check your PIX software version. If your PIX is running 7.X or higher you are in a good place as the configuration migration tool mostly match up your old PIX interfaces with the new interfaces of the ASA. If the number of interfaces on ASA is lower than the number of existing PIX interfaces you’ll have to use dot1q (if you want to use the migration tool).

The other less pretty case is when your PIX is running an older than 7.X version as you have to convert the PIX conduit and outbound commands. The rest of the process is similar, use the migration tool and you should be okay.

You might ask yourself why would you go the hard way and build your configuration manually? Like many times in life, sometimes it’s just better starting from scratch. When you build the configuration you have in mind the existing network environment with current and future needs. When migrating from existing configuration you tend to live the past, keeping old configurations (mostly access rules and objects) because they exist – not always because they are being used.

If you have the knowledge and time building new configuration is, in my opinion, the better option. You get a more accurate configuration that suit your needs and clean old unused objects. And there is one more pro, whether you’re the new guy in the company (as in my case) or a few year veteran that knows the network inside out – planning and building the new configuration let you get familiar with all the needs and review the method you’re using. Veteran’s tend to get stuck with their old doctrines and rebuilding can prevent it, make them rethink their work.