Cannot create a backup from older version of JIRA.

Nicholas Hilton

I am trying to create a backup of the JIRA server that our teams use currently. The problem is that the version they are running is v6.0.4 and has not been updated in quite a while.

I was going to export a backup to another server and then incrementally  upgrade them to the latest version of server so that I can export all of the issues to their cloud server. This server has been in use for quite some time so a restore of the entire system is impossible, I must use a csv output file of the issues that they want.

They are planning on just abandoning the server once I can get the projects set up in cloud and the issues migrated over. I have a few limitations in what I can do.

1. I cannot upgrade their in-use 6.0.4 server to any later version. I must do it on another system. They are worried that if I upgrade it they may lose data or the server might crash. I don't want this either.

2. I will take their server backup and restore it to a sandbox of JIRA that I have set up on another machine and follow this upgrade path with the data:

• 6.0.8 -> 6.3.5
• 6.3.5 -> 6.4.14
• 6.4.14 -> 7.2.2

3. They would like a bulk of their issues migrated to cloud by way of a csv file. Export from server to cloud.

4. While performing a full backup export of 6.0.4 I get an error after 5 minutes that points me to this Atlassian ticket: https://jira.atlassian.com/browse/JRASERVER-20696

I am not coming up with anything useful that I can use on google right now. Is this task even possible with these rules?

 

Thanks

Andy Heinzer

Hi Nicholas,
I understand you are looking to upgrade Jira so that you can migrate to Cloud.  There are a couple things I would recommend.

Since you won't be upgrading Jira in place, I strongly recommend following Migrating Jira Applications to another server.  This is a pretty comprehensive guide that details the steps to follow to both move this Jira instance and upgrade it at the same time.

There is a problem with the upgrade path you have chosen.   There is no need to upgrade to the 6.3.x line, but skipping the 7.0.x versions of Jira are potentially problematic due to the significant changes to the plugin system in that version.  For example if you use Jira Agile or Jira Service Desk now in your current version of Jira, you really should make sure you go to a 7.0.x version first, and then upgrade all the plugins you need for Jira there to make sure everything works.  Failing to do this could leave plugins unable to update their plugin specific data in Jira's database.  From that point you can then just install the latest version of Jira, 7.5.0.   Skipping major versions when upgrading JIRA applications - Atlassian Documentation also explains this.  As such I would recommend the following upgrade path:

6.0.4 -> 7.0.11 -> 7.5.0

Upgrade JIRA 7.2 - JIRA Knowledge Base - Atlassian Documentation is also another KB guide that helps to explain a lot of the common pitfalls users encounter when trying to upgrade older Jira 6 versions and before up to Jira versions of 7.2.x and beyond.  There are likely changes needed to database versions in order to maintain a supported platform that might have to happen before you can upgrade this data successfully in Jira.

When migrating from Server to Cloud or from Cloud to Server, the expectation is always that your Jira server version be at the latest publicly available version.   You might be able to go to 7.2.2 and then migrate to Cloud, but it's also possible that you can't migrate to Cloud on that version without upgrading again first.

I also understand that you appear to be encountering a problem while generating an XML backup to do this migration.   While the XML backup can be useful for this purpose, if this is failing, we would instead recommend using native database backup tools in order to create a backup.   This is also explained in our Backing up Jira data documentation.  The integrity of XML backups are not guaranteed, so we would still recommend using native database backup tools to then restore a backup of your data to a completely separate database.   This way you can test out this upgrade/migration without effecting your production instance.   But these native tools vary depending on what database you're using on the backend.  If using postgresql, you could use something like pgAdmin 3 or 4, if using MySQL you can use a couple of different utilities like MySQL Workbench, and if you were using Microsoft's SQL there is a SQL Server Management Studio application that should be used to create more reliable backups than the XML backup can create.   I would recommend using the native database tools in order to complete the upgrade first.  I would expect that the updated versions of Jira would be more reliable in regards to generating XML backups that you could then use to import that data into Cloud.

Why would the customer want the bulk of their issues in Jira server to migrated to cloud via CSV import?   Are they wanting to merge instances of Jira together into a single existing Cloud instance?   It could be done, but it would likely be a lot more prep work on the destination instance to do this.  With a CSV import, you are only capturing the issue data.   You wouldn't have any of the workflows, screens, permission schemes, notification schemes, field configurations, filters, etc.   But if they are not looking to merge Jira instance, and can just import complete backup, they would have all that previously configured information plus the issue data.