How often do you upgrade Confluence / JIRA?

[Jonathan Smith]

Just a general question to see if I am in the ballpark by upgrading production environments every 6 months. How often does your business upgrade production?

Regards.

[Sloan N_ B_]

Hey @Jonathan Smith

We as Atlassian Partner upgrade our Jira and Confluence very often. To stay up to date with the newest features of course. ;)

While I know other enterprises, I can say every six months is really common. Two times a year is good in my opinion. This way you don't fall behind with new features and bugfixes (!) without overdoing it.

Also never let end of Life get you. ;)

Some Enterprises only upgrade once a year. Since never Change a running system still has some truth in it.

Check out this post by Atlassian about their Enterprise Releases: Introducing Enterprise releases for Jira Software and Confluence

Might be of interest.

Cheers
Niklas

[Meg Holbrook]

We review the release notes and make a decision for each application dependent on new features and bug requests. We don't like to get too strict about timeframes and focus more on what's being offered/resolved. 

We don't have an enterprise-wide utilization yet though, so this allows us a bit more freedom since only about half of our corporate departments have been onboarded so far. 

[Fadoua]

Ideally it is six months, however we didn't upgrade yet as we are in the process of discussing if we will remain in AWS or use internal servers.

Every company I worked for it was between 6 to 8 months.

[Matt Doar__ LinkedIn]

As a large enterprise, we value stability over features. And we need to stay with supported versions, no End of Life. So we aim for one upgrade to an Enterprise release each year. Next is 7.6.x

[Sébastien Lucchini]

Hi,

We have an identical context and we decide to migrate to an Enterprise release version for Confluence and JIRA Software:

- Confluence 6.6.latest

- JIRA Software 7.6.latest

For Bitbucket and Crowd :

- BitBucket 5.(latest-1).latest

- Crowd 3.1.latest.

We will update at least once a year.

[Jonathan Smith]

Since I am in @Matt Doar__ LinkedIn's case where I don't want to impact the business, I will stick with the 6 month approach. Exception would be if a cool new feature (like co-authoring in 6x) comes up in Confluence 7.

Thank you all for the feedback!

[LeKisha Boswell]

Upgrades should occur  with regards to the size of the organization, instance, as well as security and mitigation risks to name a few. Each upgrade is unique and should be approached accordingly.

If you are employed by an enterprise organization, once annually would suffice; however, I would suggest upgrading at a minimal every two years as Atlassian stops support for outdated versions after 24 months. 

To aid in the decision of approving an upgrade or not

1. Review the release and upgrade notes under JIRA Software and Platform documentation.
2. Note what is the expected goal or outcome of the upgrade (e.g., improved performance, enhance features, fix defects) and ensure the selected version upgrade will meet those requirements.
3. Download the "Upgrade Checklist" template and evaluate your readiness and timeliness to complete each step.
4. Speak to the Approver to ensure the work can be scheduled.

You may also want to consider the Cloud instance if you have under 2000 users. Using JIRA Cloud new versions/features are automatically rolled out eliminating any upgrade nightmares! 

[Meg Holbrook]

This is more of the approach that our organization takes. I agree with you completely. 

[Vickey Palzor Lepcha]

I'd always suggest reading release notes and making a decision on how often - but yes, lets not hold on to legacy versions.

If you take security or new features into account - I'd say at-least maintain (n-1) pattern with your version and the latest version.

[kororos]

We have automated the upgrade process using the right scripts. This allows easy upgrades without facing any upgrade issues (most of the times). 

We believe that staying with the latest version of the software enables us to have a much smoother upgrade. Therefore, we upgrade to every new release (even minor) that is released by Atlassian. 

[Jonathan Smith]

Wouldn't mind seeing an article on "automating upgrades" - wink wink nudge nudge.

[Vickey Palzor Lepcha]

@kororos I'd love to know how it has been accomplished - I do upgrades regularly. I have had thoughts of automating it but not sure about where do I start.

Are you using some CMS ?

[nikhil khedlekar]

Would love to get hands on those scripts :) 

[kororos]

I will try to put together a small posting on how we implemented the scripts to automate upgrades. I will post the link here too. I hope to get this done within a week or so. 

[Andrew Culver]

About those scripts...

[April Merritt]

Is "whenever I feel like it" a valid answer? We have a lot of tools we are responsible for so sometimes its every 6 months, sometimes its back to back releases in a couple months.  There have been times its once a year.

Most of the time, more than anything its plug-in related.  I would upgrade more often, but there are a few plug ins we utilize heavily and they arent as fast to get updates out so it tends to slow us down.  

Generally we tend to stick to 'quarterly upgrading' which tends to be a little more like  semi-yearly quarterly upgrading.  

[Pronto Software]

No set timing strategy here, it averages once a quarter, but there are times when upgrades are applied a month apart. 

One strict rule.
Stay two to three increments behind the current release. This is for compatibility sanity with add-ons. Vendors can't possibly maintain the cadence of releases that mothership Atlassian peddles. Move too far ahead of your core add-ons, you will hit issues.

Having said that, we update add-ons on a weekly basis. There's basic shake-down testing then updates in Prod. One or two add-ons per week keeps the "Update" list down to a rolling half a dozen.

Critical stuff.
Intimate understanding of your business and its Atlassian use cases. Thorough analysis of Release Notes. You'll waste a lot of time and energy without these.

Efficient use of resources.
I have a target group of stakeholders around the business that perform upgrade testing on specific features. For example: next upgrade, Confluence includes change for features A, B, and C. Understanding touch-points I'll hand test cases to the stakeholders who utilise those features in their Spaces, Code Repos, Jira Projects, SD Portals, Portfolio Plans, integrated systems, etc, etc. Knock up a Board to manage all of this, and do Stand-ups to maintain momentum.

Automation.
We use some scripting to automate the Server side of things and collect very granular logs of events.

[Rick W]

Great point about not going directly to the most recent release. We just completed an upgrade from 7.1.1 to 7.7.2 and a few people asked me why I didn't go with 7.9 and I replied that I prefer the stability of a release that has been out for a while (even though in this case it was only a three month difference).

[Sébastien Lucchini]

Hi Rick,

I think it's better to upgrade to 7.2.last for you (on month perhaps after Atlassian publishing) and recommend to plan an upgrade to 7.6 Enterprise Release.

[Wim Kerstens]

Hi people,

Except for April Merritt, I wanted to know if all of you are supporting only Atlassian products in your organization(s) or are the Atlassian tools just one of the many tools you are supporting? And also what might be interesting is amount of support personnel that is involved with or without experience.

I'm in a rather small (4 member) group in separate locations that supports a ton of tools and Jira is (with some heavily used add-ons) just one of 10+ R&D environments we support/upgrade. This also has an impact on the upgrade cycle of our environments.

regards,

Wim

[Robert G. Nadon]

Hi Wim,

I would think most all companies support more than just Atlassian tools, I know we do.    We support Jenkins, Nagios, SharePoint, and more along with the Atlassian suite of tools.  

As far as upgrades they are unique to each vendor.  

For Atlassian we make sure and not go EOL, which is now about a yearly upgrade.

Best,

Robert

[nikhil khedlekar]

Currently, we are aiming for twice a year - but - we keep running into major upgrade issues and end up doing many upgrade iterations in a non PROD JIRA/Confluence environment - before we green flag it for production. So, we end up doing once a year .. mostly.

What we would really love to do is dockerize the JIRA and CONFLUENCE applications and automate its "upgrade testing" function - thus making the upgrade process easier, repeatable and reliable. Our goal is to upgrade as often as possible. 

[Craig Castle-Mead]

Every 3-6 months for Jira and confluence (sooner if there’s a critical vulnerability). 

Bitbucket, Crowd, Bamboo, fecru every month or two.

Leverarging Puppet Tasks to handle the bulk of the upgrade logic and puppet to enforce all the configuration. Has meant that the last two members to join our team have run production upgrades in their first week.

CCM

[Alfa Product Team]

We have jira (including service desk), bamboo, fisheye, and confluence and they're all vital systems for our business, and we have built a wider ecosystem around them.
That means a balance is to be found somewhere between "bleeding edge" and leaving upgrades so long that they become a Big Deal rather than the non-event we want from a support point of view...
Over time we have shifted to Puppet for managing our services, including Atlassian suite of products, and that's making the upgrade process technically more predictable and reliable..., but we still need to engage with end users and make sure integrations and addons are working - the effort for which depends on the system (e.g. fisheye has no add ons, jira has a dozen).
As this needs to fit in around "business as usual" for end users that means (not withstanding vulnerability patching) we reckon one atlassian product each quarter strikes the balance...
Which is a long way of saying we get through upgrading the full set once a year.

Antony Moss
Product Dev Director
Alfa Financial Software

[Jack [AppFox]]

I now recommend the new Enterprise releases that Atlassian will provide bugfixes for until their EOL.

Previously, we reccomended 6 month upgrade cycles, but as others have said reliability is more important than the risk of bugs and in the past this has caused big problems after go-live (sometimes requiring a minor version upgrade to fix...)

This follows the Ubuntu-like Long Term Support (LTS) model, which has been proven to work.

Using Docker, we have been able to rapidly test new versions and Ansible also makes these production upgrades a synch.