Dreading the process of an Atlassian Jira software upgrade? Depending on how many issues you have and how large your instance is, we get it - it’s overwhelming.

Below are a list of steps to help walk you through the process of achieving a successful Jira software upgrade so that you can be free of bug fixes, access new features, and operate with improved performance. Keep in mind that every situation is different, so you may need to follow additional steps in order to meet the needs of your environment.

Step 1: Evaluate the Backend

The first part of the upgrade process is checking to see if the current backend of Jira is going to be supported - backend platforms such as your java version, operating system version, and most importantly - the version of your database. If the backend is not supported, you're going to have to upgrade/downgrade it in order to align yourself with the correct version that's supported for that version of Jira. You can learn more about supported platforms via Atlassian’s documentation. 

Step 2: Validate Upgrade Path

Once you've identified the support platforms of your system, the next step is to validate the upgrade path. For instance, if you are running Jira Service Desk, previous versions of Jira before 6.9 require an upgrade path to 7.0 before upgrading to 7.1 and higher.

Step 3: Test, Test, Test

It's important to make sure that the upgrade you're performing isn't going to break your production system. Start with creating a new test machine and completing a refresh of production. This will help you identify any unforeseen issues with the upgrade.

Once you have your test environment established, the next step is to run through the test upgrade. You'll want to create a runbook that can be reused for your production system. Power off the application, take a snapshot, and back up the database. Powering off the application first allows you to get a complete backup of the system.

Step 4: Add-ons

The next step is powering on your system and validating the add-ons. The add-ons page, located under the system settings, has an upgrade checker that allows you to validate which add-ons are supported under the version you're upgrading to. It will provide a list showing which add-ons are Incompatible, Compatible if Upgraded, Compatible, and Unknown (in this order). You'll want to disable all add-ons except for the ones that appear on the list as Compatible. This ensures that the upgrade process will not fail due to unsupported plugins.

Step 5: Upgrade your Production

After disabling all required add-ons, you can shut off the application and perform the upgrade installation. Download the bin file of the new version and run it. It will either ask you if you want to install a new version of the application or upgrade a current installation (which it will default to if detected). It will also ask if you want a backup of the home directory. If you've taken a snapshot in a previous step, this backup is not necessary. The upgrade installation will also identify any changes to configuration files, i.e, server.xml changes for proxy information and setenv.sh changes for added heap size or extra arguments. After the installation is complete, you will need to reapply these changes.

Step 6: Validation 

When the installation of the bin file completes, you can start up the application and the application will make the required upgrade changes in the database. When the application comes up, you can validate the application state as well as re-enable and upgrade any disabled add-ons in the previous steps.

Step 7: Post-Upgrade

As a final step, it's always a good idea to do an integrity check of the database and a reindex of the application. 

Upgrade Complete

Congratulations, your upgrade is now complete! We strongly suggest not to wait until it is too late to upgrade your software and risk damaging your production system. It is crucial to protect your software from any potential security threats or lingering bugs in your system. You also don’t want to miss out on any new features that can help drive business growth and maximize ROI.

Praecipio Consulting works with companies across different industries and realize Jira Software is an instrumental part, not just within IT teams, but across the entire business operation. Read how we helped a fortune 20 medical supply company migrate and consolidate their Confluence and Jira instances. To ensure Jira is performing in an optimal manner, our Atlassian experts at Praecipio Consulting can help you execute a smooth and seamless Jira software upgrade. Feel free to contact us should you need any help. 

In two recent studies*, 86% of IT organizations are concerned about delivering value to their organization and 80% of an IT department's budget is used in Keeping the Lights On (KTLO). As such, IT organizations are focusing more on the right ways to keep their applications happy and healthy. One of the most important decisions an IT organization can face is how to host their Atlassian applications. Depending on resources, experience, and budget, the best choice may not be obvious at first glance. There are pros and cons of each hosting method. The question to ask is where do you find the most value when considering each option? Maybe the IT organization is new (or the company is new) and is looking for a hosting option that will take little-to-nothing to spin up and maintain. In this case, Atlassian Cloud may be the perfect fit. But what if you have a large employee headcount and access to experienced IT resources and increased funding? Maybe it makes sense to host internally to maintain complete control or, for a more hands off approach, off-loading the maintenance and performance responsibilities to someone else. That's where Praecipio Consulting can assist by offering Cumulus, our Managed Hosting platform. As Atlassian Platinum Solution Partners, we take on the responsibility of maintaining your system and are on call for your Atlassian needs. Where do you find the most value in your particular case?

What is the best return on investment for hosting?

The answer is: it depends.

1. What are the hosting methods and what are the pros and cons of each?

Atlassian Cloud

Pros:

• You let Atlassian manage your system as SaaS (Software as a Service).
• No upfront hardware costs.

Cons:

• No access to database or operating system.
• Some features that are present in Atlassian server products may not be available in Atlassian Cloud.

Internally Hosted (Server)

Pros:

• Full range-of-motion on the entire application and operating system. You are the admin.
• Personally dive into the application and get to know its inner workings.

Cons:

• Whether you’re building on top of a virtualized or physical system, you’re going to run into hardware costs and the maintenance fees that hardware brings with it.
• Time away from your team to keep that system up, running, and configuration changes when needed.
• Performance tuning can be a daunting task.
  
  

Praecipio Consulting Managed Hosting

Pros:

• More customization than Atlassian Cloud allows.
• Atlassian Platinum Solution Partners manage your instance and performance tune for you.

Cons:

• Some features will be present to Cloud first before they are released to Server.
• No control over file or database structure.

2. What does it take to migrate to a different hosting method?

Each hosted method is little different to migrate to. If you’re migrating to cloud, it’s preferred to migrate via export (if it’s not a huge instance). If you’re migrating to a server you could migrate with the above method or you can take a backup of your database and move over your data (attachments, logos, etc) to the new server. Praecipio can help you out if you’re looking for a seamless transition.

3. What kind of database should I use?

Although you can use MSSQL or MySQL, it's PostgresSQL that Atlassian deems as its preferred database. PostgreSQL also allows for an easy move to datacenter Atlassian products as PostgreSQL is able to be turned into a database cluster, a functionality that MySQL is not capable of. You can make a MSSQL cluster too, but it comes with high licensing costs.

4. What is the trickiest migration Praecipio Consulting has taken on? What made it tricky?

We had a client that needed to migrate various applications. During this migration they needed to conform to a new username and email standard associated with the parent company. What made this tricky was you couldn't manually change this easily since there were thousands of users; you'd waste a lot of man hours and downtime making a change like that. The change had to be automated to modify each user in each application with various different places in the databases being updated with the new user values. This was to ensure that you kept all the users historical data intact and the user could come back into work after the migration, use his new account to log in like nothing happened.

5. What is the cloud user license limit?

Atlassian Cloud's user limit is 2000 for licenses. If you have a 2000 plus user count your options could be multiple Atlassian Cloud accounts or the Atlassian Server products that you'd manage internally or through managed hosting.

6. What is the storage limitation on cloud?

Atlassian Cloud has another limitation that you should be aware of. Cloud has a storage limitation. If you have a user count below 500 users you're looking at a overall storage limit (across all applications on your account) of 25GB. If you're over the 500 user count, you've expanded that limit to 100GB.

7. Between Jira and Confluence, which is more difficult to migrate from Server to Cloud? 

When performing a straight migration, Jira and Confluence are just about on equal footing on complexity to move to Cloud. Now, if you are merging two applications, that is a different story. Jira is a lot more complex to merge than Confluence due to the amount of variables that Jira has to have in place, like workflows, issue types, fields, notifications, etc. The list is long and you have to make sure the structure is there before you can merge your data. Additionally, merging data must be done from server to server. So if your end goal is to be in the Cloud, you have to merge all your instances to a single server and migrate that up to the Cloud.

8. Why should I consider Data Center if I don't have a performance problem?

One of the main reasons to consider Data Center is uptime. Data Center has multiple application nodes that you connect to through a proxy. If a node goes down due to a hardware issue, guess what? The proxy connects you to the next available node so that you don't even realize there has been an outage. To take complete advantage of the high availability perks of Data Center, you would also incorporate a database cluster. The same rule as before comes into play. If you lose a database server in the cluster, you're still up and running. You could even lose database servers and applications nodes at the same time and still have your environment up and all users working. Granted, there are at least one application node and database node up at the same time.

9. When doing a migration or merge - do you recommend having a staging environment to cutover from (as opposed to going straight from production to production)?

Usually it's not that necessary to have a staging environment to cutover from. Actually it's preferred to do the entire migration while the current production instance is off so that no one can update it to avoid anything becoming out of sync. What should be done is preform the entire migration/merge in a test environment and list out the steps that a needed to perform that migration. As long as any extensive configuration changes are not being made those steps are going to pan out the same no matter what data is actually included into the application.

10. How difficult is it to change the OS? For example, Windows to Linux?

Surprisingly, it is not as difficult as you might think. Most of the time it acts as any other migration. The thing that will usually cause problems is if you have something tied into you Atlassian application that is dependent on Windows or Linux to run correctly, a plugin for instance. The application itself can be installed and the data moved over without much of a headache.

*Source: HDI, “Service Management, Not Just for IT Anymore”, 2014
*Source: Gartner, “Eight of Ten Dollars Enterprises Spend on IT is “Dead Money”, 2015