Upgrading from JIRA 7.4.3 to JIRA 8.0

[luizduarte]

We are planning to upgrade our JIRA Server instance(current version 7.4.3) to JIRA 8.0+ We have a fairly big instance(1k3+ CFs, 200+ WFs, but fewer than 200k issues) can we migrate directly*? Or de we need to have other, older versions and make several incremental upgrades?

*When I say directly I just mean getting the installer and copying JIRA_HOME or pointing there(after backing it up some three times in cloud AND in loco).

Regarding post function plugins and whatanot, can we install these after or do we need to prepare something, and if the instance doesn't have them, will the post functions just dissapear and are there other consequences.

[Mike Rathwell]

Good morning, @luizduarte 

Assuming you do as @RianS suggests, that is most of the way there. However, if you have groovy scripts you might have to check if they are using ComponentManager. I had a handful of those in both scripted custom fields and workflow functions. This page was where I found most of the gotchas.

Also, while the latest versions support JDK 11, just don't go there yet. Many plugins won't work on JDK 11 yet so just stick to JDK 8 for the time being.

[RianS]

You probably can go straight to the new version, but you need to check the compatibility on your plugins. Make sure they are at a plugin version that supports the destination Jira version. You can update the plugins before the upgrade, or disable ones that may be incompatible so that the upgrade is smoother.

Most plugins store their data in the database and the application home directory. The plugin jar/obr are stored in that directory as well so should already be installed after the upgrade.

If there is functionality provided by a plugin, there can be any number of consequences if the plugin is removed or disabled. Most of the time the functionality is missing, but will return if the plugin is re-enabled/installed.

Testing is something you'll want to try and do. If you have a development environment, run the upgrade on that first so that you can see what functionality has changed and whether any configuration changes you have made continue to function. Some administrators have used javascript to hide parts of the interface or perform other customizations and these are likely to break in a newer version, especially when moving from multiple versions forward.