Upgrade and Caveats for JIRA Upgrade 6.1.6

Hi all,

stumbling accross the Atlassian Community, I would like to gather some info about dealing with very outdated JIRA instances - as one of our customers currently use Jira 6.1.6.

Do you know of any best practices for an adequate upgrade path for those kind of old/abandoned setups?
We came up with the idea to setup a fresh and new installation of Jira Software 8.x, to make the change in overall workflow for the new JIRA possible to handle for all team members.
As the customer currently uses Jira 6.1.6 with some addons (like Tempo for timetracking), I guess this would be the most seamless transition for all users, due to the fact, that you can do a gradual rollout e.g. for only new projects in the new Jira.
But how would you handle here data and archives that need to move to the new JIRA for final rest? Is it a possible solution to just keep the old JIRA instance, until it is no longer needed or would it be better to export and import relevant data to the new Jira?

Another approach here would be - of course - to do a full upgrade from the old JIRA 6.1.6 to the recent enterprise release. But as far as I know (and sadly at the moment we do not have much experience in upgrading JIRA), this might cause data loss or at least conversion of some custom fields/data, that is stored in some no longer available addons.

Any help on this topic is highly appreciated! If this topic was discussed earlier, I would be very happy for links to those topics!

Generally speaking, I have always taken the instance, fixed it up and upgraded it. Abandoning is typically only left for apps that are so far scaled in the wrong way that it’d be more work to import than rebuild.

The only application I have been forced to rebuild is Bamboo and I am pretty sure the previous admin screwed up the integrity constraints in the DB to cause that.

Regarding upgrading –
What sorts of plugins are these?
Assuming plugins are sorted and the upgrade path is determined, this should be straight forward.