You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
The Atlassian Community can help you and your team get more value out of Atlassian products and practices.
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 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 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.
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.
What about merging multiple Jira instances?
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.
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.
Another common nightmarish scenario for Jira admins is archiving projects to increase performance while remaining compliant. Quite could be quite the challenging undertaking.
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.
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 :)
Teodora _Old Street Solutions_
Marketing Manager of Custom Charts for Jira
Old Street Solutions
28 accepted answers