Jira Inferno: The Nine Circles of Jira Administration Hell

[#1]

If you spend enough time as a Jira admin - whether you are managing a single, mid-sized instance, a large enterprise one or juggling multiple instances at once - you will eventually find yourself in Jira admin hell. Bottlenecks, broken configurations, harmful impacts on your production system - does this sound familiar?

Botron Software is a trusted friend of the Jira admin community - the company designed its first Atlassian application, Configuration Manager for Jira, with the struggles of Jira admins in mind. Since then our development team has introduced numerous features to help admins avoid the Jira inferno, including introducing issues as part of the configuration snapshot and currently working on implementing Service desk support.

Our team is very familiar with the pain points of Jira admins, so we decided to illustrate some of the more common hellish scenarios in the spirit of Dante's “Divine Comedy”. Apologies to our friends at Atlassian, we hope you won't be offended - Jira is an amazing product, but managing and scaling it is quite a difficult task for admins.

The First Circle: Abandon all hope, you who enter here!

The first circle of the Jira inferno is reserved for those junior admins who are still unaware of potential occupational hazards of their chosen career.

The Second Circle: Test-Staging-Production

The second circle of the Jira inferno is one of the most common amongst admins - implementing changes to an existing Jira configuration is a slow, manual and error-prone process in hell.

The Third Circle: Moving Jira projects between instances

Ah, moving projects between different Jira instances. Not a pleasant task in hell, isn't it? Loss of data and capabilities, messed up Scrum and Kanban boards and missing attachments are just a few of the nightmarish scenarios that could go wrong during a typical Jira migration.

The Fourth Circle: Consolidating Jira instances

What about merging multiple Jira instances?

The Fifth Circle: Jira project templating

Have you ever had to recreate the configuration of a Jira project to be used as a template? Doing it in hell will require slow, mundane and repetitive manual work.

The Sixth Circle: Jira projects backup & CMDB

Keeping a copy of a project configuration for compliance and data protection reasons is quite a common scenario for Jira admins who manage enterprise instances.

The Seventh Circle: Jira project archive

Another common nightmarish scenario for Jira admins is archiving projects to increase performance while remaining compliant. Quite could be quite the challenging undertaking.

The Eighth Circle: Jira clones

Have you ever tried creating a clone of your production environment to test changes? Easier said than done, right? Once you walk through the gates of heaven, you don't need to worry about the implementation of this task.

The Ninth Circle: Delegated project administration

One of the biggest challenges of Jira scalability is the ability to delegate administration privileges. Allowing users to test changes is a risky and highly non-recommended move, but putting the burden of this on the shoulders of a single Jira admin is no better.

Before you despair, keep in mind that each circle of hell has a heaven equivalent and the key to the gates can be found in the marketplace :)

[M Hoogenboom]

Seems like a very useful add-on, but I'm again suprised that it is almost impossible to manage a larger instance of JIRA without this add-on and other very useful add-ons. JIRA out-of-the-box seems an empty shell which can be easily broken. 

[Thomas Schlegel]

I wouldn't say that it is almost impossible. I'm administrating Jira in our company for more than 11 years now, we have 1300 users, about 300 projects, 140.000 issues a lot of workflows, custom fields, a test stage...  You have to know, what you do, but it is not almost impossible to maintain that out of the box.

[M Hoogenboom]

Probably when you don't have any add-ons and don't customise too much, it's easier. But it is easy to make a mess of it as well. In our JIRA instance, the default statusses were renamed, because it was possible. (eg. In Progress became Rejected). Now, you cannot use the default workflows anymore, but worse: you cannot migrate projects to other instances anymore as well. It's difficult to correct, because reversing this influences the agile boards and history of the projects using these statusses. And nobody wants to lose information. As administrator of JIRA, you have to be able to say: no and stick to the defaults as much as possible unless there is a good reason to alter something.

[Thomas Schlegel]

As I said, you need to know, what you do. I just didn't want to leave the statement here uncommented that it is almost impossible to manage a larger instance without this app.

[M Hoogenboom]

Good to hear it is possible!

[Benjamin Horst]

The Configuration Manager was a nice tool to help migrate two bigger Jira instances (~700 users and ~120k issues in each) together.  

However it didn't take care of AO tables, which caused the real pain (e.g. TestFLo)  We had to merge the well-sorted instance into the messy one and clean up later, since we weren't able to migrate the AO tables. Same goes for some hard codes links etc. 

All in all Configuration Manager is great for working with the standard Jira. It only had a few flaws. E.g. take care if someone has changed the basic Jira schemes in the source for example. If you import it, it overrides.

But if you have added lots of Add-Ons, Configuration Manager is like having a garden hose in Jira administration hell. And I don't blame Config Manager for this ;).

[Deleted user]

Hi Benjamin,

Thanks for the feedback! A bird told me that the team behind the Configuration Manager are working toward resolving this issue, so future users won't have to suffer through such scenario again ;-) 

[Craig Castle-Mead]

Having used Configuration Manager to help merge ~ 25 instances into our primary environment, I can attest that it's a huge help. There's still a lot of manual work to do, but with each release it's improved. We're developing a custom solution for the delegated admin component, but primarily cause we have a lot of additional business rules about how project keys need to be named, what schemes various teams can use etc.

The 9 circles of admin hell are pretty spot on - some days it feels like you're 100 circles of hell deep though!

CCM

[Vickey Palzor Lepcha]

My problem has always been with issue archiving as the bulk grows. Why don't we have option to archive and compress old issues.

[Marc Dvorschak]

Well... We just started with JIRA. After reading this article I have something to look forward to ... Hurray!

[Benjamin Horst]

@Marc Dvorschak: Great. If anyone ever tells you that it's a good idea that another apartment sets up his own Jira and that these system will never need to be merged into one... make sure he wins in the lottery the next day, so he moves to his own island far away from your company.

[Daniel Holmes]

Very useful article to explain what you can't just let teams have admin permissions because they promise to be good and don't want to be bottlenecked by central admins.

[Karen Rogalski]

This is a must-read for every new Jira Admin. It will save them countless hours of pure Jira Admin frustration.