Stream: troubleshooting

Topic: Best strategy for migrate to a new server

Carlos Perez-Miguel (Mar 11 2026 at 16:00):

Hi, not sure if this will fit into this channel, sorry if not.

At DIPC we have been working with an old server as our Dataverse installation for the last year. Now we have purchased a new one and I am looking into the best strategy for migrating all the contents from our ancient server to the new one.

• Is there any guide about this?
• Is there any tool?
• What would be the required steps?

I saw that there is a backup script on the dataverse repo but it is quite old.

Thank you!

Philip Durbin 🚀 (Mar 11 2026 at 16:04):

Hi! Will you be keeping the same version of Dataverse, for now? That will make things easier, I would think. Fewer changes.

Oliver Bertuch (Mar 11 2026 at 16:09):

Once you installed your new server's operating system, it shouldn't be that hard to migrate the installation. It will require planned downtime though.

Here's some things you'll need to consider (not necessarily complete):

• Shutdown the application, database and index before attempting any copy operations.
• Depending on where you store your data at rest, you may need to copy the data from old to new. You're taking the easy way when you store your data on S3 or some network file system. For local filesystems, you will need a copy & sync job, probably with rsync. You could also start by only migrating your data to a new network filesystem in case you have it now on a local disk, that will make the transition easier.
• Depending on how you installed Postgres and Solr, you can probably just use rsync to copy your installation's files (minus the actual data) from the old to the new server. When you used some package to install Postgres or Solr, you'll need to install them in the new location and then do a data migration with those. Not to hard, but you should read up on that.
• Take care of any Cronjobs and Startup Scripts. Depending on your current OS you might need to adapt (e.g. because of SystemD changes). Cronjobs are usually easy to copy and paste between servers.

I can only highly recommend to automate such tasks to make it easier in case of necessary recovery.
Probably @Don Sizemore has more thoughts on this.

Oliver Bertuch (Mar 11 2026 at 16:09):

Also - what Phil said. Don't make a migration and an upgrade at the same time. Avoid too many moving parts at once.

Carlos Perez-Miguel (Mar 12 2026 at 08:27):

So basically we could say these steps apply?

1. stop payara
2. backup Solr
3. backup Postgres
4. install Dataverse on new server
5. copy collection files to new server
6. restore Solr and Postgres backup on new server

Philip Durbin 🚀 (Mar 12 2026 at 11:18):

Basically, yes. You'll also want to copy over logos for collections (dataverses), if you have any of those. The are usually stored in /usr/local/payara6/glassfish/domains/domain1/docroot/logos

Philip Durbin 🚀 (Mar 12 2026 at 11:19):

That's one of the steps in #12043 which is about upgrading from Payara 6 to 7. (This pull request hasn't been merged yet.) See this file in that pull request: doc/release-notes/12020-Payara-and-Java-updates.md

Carlos Perez-Miguel (Mar 12 2026 at 11:34):

If I copy the entire /usr/local/payara6/glassfish/ between installations, will payara still work?

Philip Durbin 🚀 (Mar 12 2026 at 12:04):

I'm not sure, but it's probably worth a shot!

Don Sizemore (Mar 12 2026 at 12:18):

Carlos Perez-Miguel said:

If I copy the entire /usr/local/payara6/glassfish/ between installations, will payara still work?

You can probably do that, yes, but on a new system I'd exclude /usr/local/payara6/glassfish/domains/domain1/generated/ /usr/local/payara6/glassfish/domains/domain1/osgi-cache/ and possibly lib/databases/ejb/

Last updated: Apr 03 2026 at 06:08 UTC