After March 17th 2017, Jira 6.4 will no longer be supported by Atlassian. To stay on supported versions of Jira, you’ll need to upgrade to Jira Software, Jira Service Desk, or Jira Core. (End of support means that Atlassian support will no longer be able to help with questions related to 6.4, even if you have current maintenance.)
If you’re currently on Jira 6.4 or an earlier version, you’ve likely started planning your upgrade. Because the upgrade from Jira 6.4 requires a slightly different upgrade process than previous versions, we’ve put together this blog post to address some of the most frequently asked questions from customers on the upgrade process from Jira to Jira Software. We hope this is a helpful resource for you, and we appreciate everyone who took time to let us know what’s on your mind.
End of support for Jira 6.4: FAQs about upgrading from Jira to Jira Software, Jira Service Desk, and Jira Core
1. Do we need to upgrade Confluence to keep it compatible with Jira Software?
All of the currently supported versions of Confluence are compatible with all versions of Jira Software (up to 7.3.2, the most current version today). If you use application links with Jira and Confluence today, make sure to check the Application Links version matrix in the documentation for specific details on the compatibility of Atlassian applications.
Also, if you use an older version of Confluence, please make sure your current version is still supported. The Atlassian End of Support Policy page lists all dates when each version of our products will no longer be supported.
2. We want to upgrade our server when we move to a new version. What’s the recommended process?
If you’re planning to migrate to a new server, it’s always a good idea to test thoroughly, especially during major changes. We recommend:
- Back up your files (of course!)
- Install Jira Software 7.0.x on your new server
- Migrate your data and run your usual testing
- Then upgrade to the latest Jira Software 7.3.x on the new server
Check out the full documentation on migrating to a new sever on this page: Migrating Jira applications to another server
Edit issues from a board or backlog in Jira Software 7.2
3. What’s the recommended process if we use a VM?
If you already use a virtual machine, you don’t need to spin up a new machine to perform the upgrade (unless you want to). Before you start, make sure to back up the database as well as the VM. Once the data is upgraded, you can’t roll back.
4. How do we get upgrade help for issues with add-ons?
The best way to get answers for questions relating to add-on behavior/functionality is to contact the add-on vendor directly. The vast majority of the add-ons supported in Jira 6.4 are supported and working as before (or with new features!) in the new Jira applications.
If you run into issues starting up Jira Software after the upgrade because of incompatible add-ons, we recommend that you reinstall add-ons through the UPM to ensure you have a compatible version installed (instead of manually bringing over the installed-plugins folder). No data will be lost with this method, since it’s stored in the database.
Also, Jira Software 7.3 introduces a new feature to disable add-ons on Jira startup to help you troubleshoot issues related to add-ons. Check the Jira Software 7.3 release notes for more details.
5. What is the recommended upgrade path for different versions?
If you’re on version 5.2 or later, you can upgrade directly to Jira Software 7.0.x, then to Jira Software 7.3.
The most recent version of Jira Software is 7.0.11, but you can upgrade to any point version of Jira Software 7.0 (e.g., 7.0.1 – 7.0.11) for the initial upgrade to the 7 version.
Key Jira Software features since Jira 6.4
6. Can we use Jira Software and Jira Service Desk within one Jira installation?
Yes, absolutely. This documentation provides a high-level overview of the different Jira applications and their capabilities.
7. How should we plan for the new workflow customization capabilities in Jira Software 7.3?
By default, when you upgrade to Jira Software 7.3, all your project administrators will have access to edit projects’ workflow. However, there are a few ways you can prepare for this, if this isn’t the exact behavior you want in your instance:
- You can prevent a workflow from being customized by sharing a workflow with another project (project admins can only customize a workflow if it’s not shared)
- You can use the new script we’ve created to check which groups/users will be able to edit workflows
There are also limitations to what actions project admins can take when it comes to customizing workflows. Take a look at the Jira Software 7.3 release notes on the feature for more info.
New workflow features available in Jira Software 7.3
What’s next?
We hope this information is helpful to you along your upgrade journey. If you have any lingering questions, here are some additional resources that might help: