Migrating to new cloud instance

Question

Hi all,

I am tasked with merging two cloud instances.  One is the legacy Jira Software (JS) instance that is used heavily for Scum and Business projects.  The other, which we are migrating to, is a newer cloud instance of Jira Service Desk (JSD) with a meaningful URL.

I've given up on merging the instances.  It is too lengthy or complicated a task using the server method, and not in the budget to engage outside help.

So, I'm looking at another way.  I will install JSD on the legacy JS instance and configure to match production JSD as closely as possible.  When happy with the new JSD after testing, I will then migrate it and JS with the legacy instance to the newer cloud instance.

I've made the assumption that restoring a backup of a cloud instance will erase all data at the target instance.  But, I've come across this, which seems to indicate I can restore parts of a backup over multiple times.  It's implied this would not wipe data at the destination.

If that's the case, am I not better off backing up and restoring relevant projects from the legacy JS into the newer JSD, saving the time and hassle of recreating JSD?

If my original approach is sensible - of rebuilding JSD on the legacy instance and backing up/restoring to the new instance - do you have any gotchas or tips to share?

Thanks,

Marc

unknown · Answer

I've only done this with postgres. This document https://confluence.atlassian.com/jirakb/migrating-from-jira-server-to-jira-cloud-779160826.html says that there could be errors on time zone and to prevent them you should check (and change) the time zone. A change would only be possible with postgres, so i recommend to switch to postgres first. This step is explained here: https://confluence.atlassian.com/adminjiraserver/switching-databases-938846867.html .

Marc Deslauriers · Answer

Thanks, Tobias - is using the provided H2 database an option if going the server route?

Marc

unknown · Answer

Tips for the server aproach:

* Backup
* Clean up what you can (remove unneeded projects, schemes and configurations, even issue types).
* Prefix everything so you know where settings came from and project settups dont mess up each other on merging.