Migration Plan from 5100 series HA using Smart-1 410 to 9100 series HA using Smart-1 700 series

[Wildan_Ahmad]

We have two 5100 Series HA Security Gateways running OS version R81.20 Jumbo Hotfix Take 113 and a Smart-1410 Series Security Management device running OS version R81.20. We would like to perform a technical refresh using two 9100 Series Security Gateways and a Smart-1700 Series Security Management device.

Plan:

1. Back up and restore GAIA on the two Security Gateways

My question is: the old Smart-1 units are running OS R81.20, while the new Smart-1 (700 series) units use the R82 base OS, and it seems they cannot be downgraded to R81.20. The old Smart-1 units are still in production use. So, do you have any suggestions for my next steps?

[PhoneBoy · Accepted solution]

Sounds like a good reason to move to R82, which is the recommended release at current.
Start by performing an Advanced Migration on the Smart-1 appliance per the Advanced Upgrade process: https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_Installation_and_Upgrade_Guide/Con... 
This does not require an outage.

More details in this thread: http://community.checkpoint.com/t5/Firewall-and-Security-Management/Replacing-R81-20-cluster-with-ne... 

[Wildan_Ahmad]

I have an idea to set up GAIA and migrate_server with OS version R81.20 on my lab VM. Once all the configurations are in place on the Smart-1 VM, I will upgrade to R82 and migrate the migrate_server from the VM to my new Smart-1.

What do you think about my idea?

[PhoneBoy]

You can do that, yes.

[Bob_Zimmerman]

Your old management supports R82, so I would start by upgrading it in-place. I've had bad luck with Blink upgrades on my managements, so I personally would just upgrade to R82, install jumbo 60, then install the hotfix from sk184766 as separate steps within the same change window. This doesn't involve an outage or anything, so I would do it during the business day.

The 5100 also supports R82, so my second change window would involve upgrading the cluster. In SmartConsole, just right-click on the cluster object and pick the Action > Version Upgrade option. I've had a few successes with Blink here, but you can also do the same process of upgrading to R82, installing jumbo 60, and installing the hotfix as distinct steps. Upgrading through SmartConsole involves a failover, but it should preserve state. The big selling point to me is it doesn't let you forget a step, because the whole upgrade process is scripted.

Once everything is on R82, I would replace the management server. Get the new management running jumbo 60 with the hotfix, export the database from the old one, import it on the new one. The new one needs to have the same name, and should ideally have the same IP. Push policy from the new one, and you're done. Again, I would do this during the day, when everybody is awake and sharp.

Then finally, a fourth change window to replace the cluster members. I generally bring one cluster member down, replace it with the new one, reset SIC to let the new box take over the old object, and push policy. As long as that goes well, I then force a failover (the members often won't be able to sync with each other, so this will probably involve a hard outage), then repeat the process on the other member.

Four windows (two of which can be during the day), which each touch a single part of the environment. Simple, and easy to undo if anything goes wrong.

[Wildan_Ahmad]

I completely agree with this plan, but my client doesn’t want to perform a major upgrade on the older devices currently in production

[Bob_Zimmerman]

If they don't want to upgrade the existing devices, then they need to be aware they are choosing to extend the outages needed, and they're opening themselves up to more opportunities to make mistakes. If they're okay being down for a few hours, then it's easy enough.

I would still do the management as a separate change from the firewalls. Ideally two changes to minimize the troubleshooting if something goes wrong: one to upgrade the old management, one to migrate to the new hardware. Have the new management run the old firewalls for a while to confirm everything was migrated successfully. Management changes like that don't go wrong often, but when they do, it's really, really bad.

[emmap]

You don't have to in-place upgrade the old one to do the migration, the R82 upgrade guide has instructions for doing a migration and upgrade in one step. Can export the database from R81.20 in a format targetting R82, the import it straight in to the newly built R82 server. 

[Bob_Zimmerman]

You don't need to separate them, but I hugely prefer to split the upgrade from the hardware swap. I've had both types of change go wrong, and I like to constrain the troubleshooting space when possible.

[emmap]

Fair enough, I haven't had a lot of issues with it and I like to keep the 'origin' side of the setup untouched for more complete rollback when engaged with a project but I can see where you're coming from there. Both methods are definitely valid and supported so there's no issue on that side of things.