Create a Post
Showing results for 
Search instead for 
Did you mean: 

migrate_server instead of migrate export/import

Dear all,

When the management server is running R80.20 or higher, and you'd like to upgrade to a higher version, you'd propably done that is the past with database script "migrate export".

Now, a new script is in place, and it is a different way to do the export/import as in the past.


I have already walked through the process, but still have some questions, perhaps someone is able to provide some answers.

  1. hugh diffecence in filesize
    • a migrate export on my R80.20 server with the old tool to the same version (R80.20) results in a filesize of 1,7GB.
    • export with the new tool to version R80.40 results in a filesize of ~350MB (without logs/indexes) - wow, that's a lot much less. After the import, I saw, that any database revisions are gone. Is this the reason?
  2. slow import process
    • I've used the upgrade tool, build version 993000252 (sk135172) 
    • it took round about 1 hour to import the database. I have the feeling, that the script is slower than the old method. But what Im missing, is a progress bar or anything else. However, no logfile was written (/var/log/opt/CPshrd-R80.40/migrate*). . A liitle more conversation would be good.


The server is running on HP DL360 Gen8, 16 Cores, 48 GB RAM.

0 Kudos
3 Replies

I believe that may be one of the things we do in migrate export is not take every revision, which can definitely reduce file size of the export.

One benefit of the new migrate_server tool is that we can update it independently of a regular maintain release. @Eran_Habad showed me a video of an improvement coming to the CLI version that will show some progress when doing the upgrade.

There is also an interactive upgrade report in the Gaia WebUI that updates as the upgrade is going on.

0 Kudos


Please note that not only that the name of the script was changed from migrate to migrate_server, but the entire management upgrade mechanism is new. Some of the benefits of the new upgrade mechanism can be found in this post.

Indeed the export file is smaller, there are two main reasons for that. First, only the latest revision is being upgraded and not the entire database as before. In future versions we may change that and allow upgrade of several revisions. Also, migrate export takes all data files from the database, while migrate_server introduced an optimization and takes only the required part of the data.   

Regarding to the upgrade process, we have plans to reduce the upgrade time in upcoming versions. A new HTML report was introduced, it shows the progress and status of the upgrade. The upgrade report helps us to get visibility for what took the major time, and improve. If you agree to share with us the report we could also learn from it.

Regarding upgrade logs, from R80.40 the new upgrade mechanism collects all upgrade logs by default. Once upgrade process is finished, either successfully or with a failure, all upgrade logs (including the HTML report) are being stored in the management server under /var/log/.

  • /var/log/upgrade-export.<time stamp>.tgz
  • /var/log/upgrade-import.<time stamp>.tgz


Indeed one of the great benefits of the new upgrade mechanism is the updatable upgrade tools package, which allows faster delivery of fixes and enhancements, independently from regular maintain release. Soon we will introduce an improved UI to the advanced upgrade (via CLI), it will be released as part of the updatable upgrade tools package. A video is attached.





FYI, I edited your post to add the video inline.