Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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

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.

1 comment

Rachel Wright
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
Nov 06, 2019

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):


  • 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.


  • 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

Like Chiara Squilloni likes this

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.


Log in or Sign up to comment