Best method to upgrade JIRA v5.2#812-sha1:c4fbab6 to latest

[Terri Eads]

I've been reading the documentation and it's still not clear to me what the best method is to upgrade from JIRA v5.2#812-sha1:c4fbab6 to the latest 7.6. I also need to move the instance to a new linux host running a newer OS. Is there a definitive guide somewhere? Thanks for any input.

[Andy Heinzer · Accepted solution]

Hi Terri,

There are a couple of different ways to do upgrades when it comes to Jira, these are explained in Upgrading Jira Applciations.  Personally I am a fan of the Fallback method.  Mostly because it provides the clearest way to revert should the upgrade not work as expected.

In regards to your specific situation: I would recommend that you upgrade in this order:

5.2 -> 7.0.11 -> 7.6.0

With each upgrade, you will need to make sure that you first have a supported platform for that version of Jira.  This tends to be a concern when making such a major leap between versions because the supported database versions might not be the same between these major leaps.  Each version of Jira has a corresponding supported platforms page:

• Jira 7.6 supported platforms
• Jira 7.0 supported platforms
• Jira 5.2 supported platforms

Also it is very important to make sure that you also update all the plugins you use with Jira on each upgrade in order to make sure that both the functionality you need still works and that your Jira data/plugin data can be upgraded later on.  That is why it is really important that you do not skip the upgrade to the 7.0.x version of Jira.  A lot changed in this version from previous releases.

I would also recommend reviewing the KB: Upgrade Guide for Jira 7.2.   I know that guides says it is for Jira 7.2, but the info there still very much applies to the 7.6 version.  In support we found lots of customers that would try to skip the 7.0 -> 7.1.x versions and try to upgrade a 6.x version directly to 7.2 or higher.   While there are some users that were able to do this successfully, we found a lot of users could end up with a broken installation because several plugins should have been updated on prior versions to maintain data and there exists no way to update that plugin data without reverting the upgrade or trying to downgrade the install.   We have found this is true of many plugins for Jira, both Atlassian made plugins and 3rd party vendor plugins.

Lastly, since you mentioned wanting to move the application to a new OS, I would also recommend Migrating JIRA applications to another server.  This guides does explain specific steps needed in order to make sure that you can both migrate and upgrade at the same time if needed.   Jira upgrades can be done this way, but there are specific steps to follow if you upgrade Jira this way to make sure that all your data exists and works in the upgrade.

Sorry this answer is probably a lot to digest, please let me know if you have any questions or concerns.
Andy

[Terri Eads]

Andy,

Thank you so much for the information. I had read that from a 5.x version the upgrade would be to some 6.x version, then 7.x, but your answer is more specific and will save time.

It sounds like it may be best to upgrade in place then migrate?

One more question: where do I find the older versions. I have downloaded the latest but have not found the intermediate versions.

Thank you!

[Andy Heinzer]

The versions of JIra for 6.x and before are on the old Archive page.

However for Jira 7 versions you can still find these on the main download page.   You can go to https://www.atlassian.com/software/jira/update and then click the View All Versions.   The bottom left box you can click it, then click the '7'.  This will then display all the 7. releases (7.0.x, 7.1.x, 7.2.x, etc)

While you can upgrade in place,  the fallback method typically has you setting up a separate new server or VM in order to install JIRA to.  In your case I think that would work better than an in-place upgrade.  Especially because the supported databases changed so much between 5.2 and 7.0, it's pretty unlikely you can do an upgrade in place without first migrating the data to a new supported database.   Plus in place upgrades tend to be less successful, than those that are installed fresh to a new instance and then connected back to your existing data to upgrade it.