- Products
- Learn
- Local User Groups
- Partners
- More
Firewall Uptime, Reimagined
How AIOps Simplifies Operations and Prevents Outages
Introduction to Lakera:
Securing the AI Frontier!
Check Point Named Leader
2025 Gartner® Magic Quadrant™ for Hybrid Mesh Firewall
HTTPS Inspection
Help us to understand your needs better
CheckMates Go:
SharePoint CVEs and More!
Hello, people.
Currently we want to install from 0 a CP in Standalone R81.10, in OPEN SERVER (On ESXi).
We have now a CP in Standalone in version R80.30 that is damaged.
We want to use the migrate_server to export the database of the damaged CP, and import it in the new CP with version R81.10.
Here, we have a doubt.
Once we have "installed" the new R81.10, should we simply import the R80.30 policy package, with the "Migrate_server import"?
Or do we have to take into consideration something else before importing the policy package?
Cheers.
Its been a while since I did that method, but I dont see why it would not work, as mgmt part is half of standalone : - )
So technically, migrate server process should work.
Andy
As long as you specify the target version upon export, I believe it should work.
See: https://support.checkpoint.com/results/sk/sk135172
Hello,
My doubt is basically because of the following:
The documentation shared, is clear, but there is a point in the SK, that mentions to download the Upgrade Tools package (I attach the image), and this is where my doubt appears, this step #2 I understand, that is "optional", right?
Our idea is to INSTALL FROM 0 a new VM in the ESXi, from GAIA OS in Standalone deployment, which will work in R81.10 version, and we just want to "import" the rules database, from the VM that is damaged (which works in R80.30, but we already have a Backup, that we managed to obtain with the migrate_server export).
So, this step #2, in our scenario, if it can be OMITTED?
Simply, it would be to have the GAIA OS R81.10, up, and import the R80.30 policy package, with the "migrate_server import", is that correct?
Thanks for your comments.
Thats it, just make sure you follow examples given in the sk.
Andy
Hi, Bro
In a standalone deployment environment, is it normal that when I try to generate the "export" of the team's policy database, the services are "stopped"?
Is it not possible to generate the export of the policy package, without affecting the equipment?
Cheers 🙂
Sadly, I dont think its possible. As IM sure you know already, when cpstop is issued, it will unload the policy, so I strongly recommend doing this after hours. See, thats huge downside in my mind about standalone setup...no separate management server, which is very inconvenient when you have to perform any such similar operation.
Andy
So, is it natural, then, that the process of "exporting" package policies, in the standalone environment, affects the customer's overall services?
But it is 100% that the equipment, when applying the CPSTOP, during the export process, when it returns to "lift", has generated me the BACKUP of the policy package?
Yes and yes. Again, that is HUGE downside of standalone, not having separate management server to do these things in the middle of the day.
Correct, it will get you the backup of the policy, but do it AFTER HOURS, as it will totally remove the policy package until its cpstarted again.
Andy
Hello,
I am having recurring problems when trying to export the policy package.
I keep getting the same error over and over again.
Am I applying the correct command for the export?
I already have CPUSE updated.
I am in the cd $FWDIR/scripts folder.
I apply the command: ./migrate_server export -v R81.10 /var/log/tmp/CPR81X.tgz (On my Standalone)
But the export stays at 3% and I get the following message in Putty.
Is this normal?
Am I applying the correct command in the "migrate_server export"?
That parameter, "-v R81.10" is correct? Or should it go there, "-v R80.30"?
My environment right now, is in R80.30.
Cheers 🙂
Just follow SK example bro. If issues, I would work with TAC.
How long does it take before you get that message?
I suspect the SSH session is timing out because the process is taking so long.
TAC may need to assist here also.
An alternative approach to using migrate_server is: https://community.checkpoint.com/t5/API-CLI-Discussion/Python-tool-for-exporting-importing-a-policy-...
Unlike a migrate_server, this won’t require an outage on your existing gateway.
Unlike migrate_export, some rules and objects will have to be recreated (those without API support).
Also please refer to:
Upgrading a Security Management Server or Log Server from R80.20 and higher with Migration
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
User | Count |
---|---|
29 | |
16 | |
4 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 | |
2 |
Tue 07 Oct 2025 @ 10:00 AM (CEST)
Cloud Architect Series: AI-Powered API Security with CloudGuard WAFThu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Thu 09 Oct 2025 @ 10:00 AM (CEST)
CheckMates Live BeLux: Discover How to Stop Data Leaks in GenAI Tools: Live Demo You Can’t Miss!Wed 22 Oct 2025 @ 11:00 AM (EDT)
Firewall Uptime, Reimagined: How AIOps Simplifies Operations and Prevents OutagesAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY