Upgrade V9 to V10 issue

[Mick_Ball]

We have a number of 3020's coming to EOL and running max version 9.. We have purchased new PA-450's to replace these but they can only run on min version 10.

When I load the config from 3020 to 450 commit fails as part of the config is either no longer viable or in the wrong place. I have been able to edit certain bits but not sure what else may become an issue further down the line...

Does PA have a tool for converting configs from 9 to 10...?   my only other option is to install a VM v9, load the config and upgrade that to V10 then export...

any help/advice much appreciated.

[TomYoung · Accepted solution]

Hi @Mick_Ball ,

This question comes up a lot on this community.

Expedition should be able to do it, but I have not seen a post where someone has done it with Expedition.  https://live.paloaltonetworks.com/t5/expedition/ct-p/migration_tool  The 1st PAN-OS config is the base config.  So, load the PA-450 config 1st.  I like to run the Day 1 Configuration for the new NGFW and load that into Expedition.  I have done a lot of 3rd party migrations with Expedition.

When you upgrade the PAN-OS, the NGFW converts the code.  So, the NGFW has that built in somewhere.  A "load older PAN-OS" option would be nice under Device > Setup > Operations.

Here is a thread where I went through 5 options -> https://live.paloaltonetworks.com/t5/general-topics/migrate-from-pa-3050-to-pa-3410/m-p/531128.  One person used your process and edited the XML to fix it.  They exported and imported the device config to get the certificates.  (I think that actually gets the keys.)  The question you face is "How many more commit errors are there?"  Once you get the commit to succeed, I don't think you will have issues "down the line."

Pasting pieces of the CLI at a time will actually show you the syntax errors, but that would take a LONG time.

Thanks,

Tom

[Mick_Ball]

OK thanks for the info...   I will have a play, and i did search but probably not used the correct wording.

Odd that you should mention it but after I got the device to commit (it was an OSPF seting no longer used)  I then added it to Panorama, when I modified an object and commited to all firewalls the 450 failed as it did not like the modified address object.

The commit error was not about the object but the fact that one of our gateway configs was using it in a split tunnel setting as below.

so...  I removed the ST reference from the gateway config, commited from Panorama and when completed added the ST reference back in and all was good...

It worked on all the other devices and 10.0.0.1 was just the name of the object, the ip was 10.0.0.0/8.

No real biggy I suppose but we have around 32 gateways spread over 8 boxes so could get messy...

Let me go have a play and thanks Tom.

[TomYoung]

Hi @Mick_Ball ,

Thanks for sharing!  So that is an example of an issue down the line.  Very interesting.  I would hope that would be the end of the line for those errors.  I would like to hear a follow up from you after a while.

I have a customer with some PA-3020s.  I would like to try the Expedition approach and see how that works.

Thanks,

Tom

[Mick_Ball]

Tom , hi

accepted as solution as answered my question but as it turns out i did not need it..

The main issue was caused by me not being able to use the xml configuration file because it did not contain the objects from Panorama so initial commit was failing. after reading up it was suggested that you are better off to "export device state" as this captures all realtime settings...  it was the import of this that was causing errors and on 2 of our 8 gateways I could net get the config on there at all... so gave up as your solution is for xml and config state is different format..

so... I simply removed device from Panorama, selected the keep all objects option, exported and imported with no issues...  well apart from the fact that i had ethernet1/12 as a test DMZ link and of course the 450's only have 8 interfaces but easily fixed.

Just an FYI and thanks again for your time.