Upgrade Jira Software from a very (very) old version: how to act.

[Chiara Squilloni]

Hi everybody, 

I need advice.

In our company we are currently using a very (very very) old JIRA Version, we never update it because we used an internal pluging to manage external emails that wasn't compatible with jira 7.

Finally we keep another addon supported in latest version and we are ready to upgrade our product.

So we have to upgrade manually, from 6.4.1 to the latest version (a long road to go!).

We are facing with problems and honestly I'm not satisified by my Jira, because there was a time in wich too many administrator used jira (without a common strategy and point of view) and there is a mess with custom field not used, old workflow and so on. So that's the point: it is better to go on, update the jira version and after (if I survive!) schedule a "jira refactoring" or it is better to instal a Jira software brand new version (the latest, of course) and migrate the projects?

I dont' even know if the second option is possible because of licence problems.

[Rachel Wright]

Hi @Chiara Squilloni ,

It's hard to say what you should do, with only the amount of info in the description, but you have many options to consider:

1. Stair stepping your upgrades to a current version and refactoring (which is guaranteed to take some time)
2. Standing up a new instance and migrating all your data (issues, configurations, schemes, change history, custom fields, users, etc)
3. Standing up a new instance and simply importing issue data (only)
4. Starting fresh (Standing up a new instance and not migrating/importing old data)

Here are some pros and cons for idea #4 (starting fresh):

Pros:

• Reduce the size of your instance
  • Leave old, unused projects behind
  • Leave closed issues or unlikely to be worked issues behind
  • Regain attachment or database storage space
• Revamp your usage or configuration strategy
  • Leave past configuration mistakes behind
  • Ditch needless customizations and use standard features instead
• Refresh the technology
  • Escape old log errors or corruption
  • Ditch database tables created by old or unused add-ons
  • Update the database schema to the latest standard
  • Upgrade the database version or change database types
  • Upgrade the application version
• Clean up user access
  • Leave inactive users and their assets (e.g. saved filters) behind
  • Ditch un-maintained groups
• Restart issue numbering
  • Example: The next ID starts at ISSUE-1, not ISSUE-1058741.

Cons:

• Resistance to change
  • Users are sometimes resistant to change, even when it's needed
  • Users battle fear of the unknown, loss of access, or loss of access to data
  • Decision makers are apathetic or daunted by the scope of the task
• Storing existing data
  • Access to existing data as a historical record
  • Old data in one system, new data in a different system
• Licensing and support
  • Multiple instances may temporarily (or permanently) increase license costs
  • Multiple instances will require additional storage, hardware, resources, administrative support, etc.
• User impact
  • Users may experience downtime
  • Users may need to adapt to a different environment
  • Users may require re-training

I hope this helps!

Rachel Wright
Author, Jira Strategy Admin Workbook

[Chiara Squilloni]

Dear Rachel, 

you are such an inspiring person! Thank you so much.

I'm going deep in my update, I guess that the most hard work is from 6.x to 7.x

Thank you so much for giving me the right way to see the problem.