Technology platforms mature and improve over time. The Atlassian ecosystem is no exception. One area where Atlassian has matured dramatically is in supporting customizations. In the past customizations were a real “wild west” edit the database and file system approach. Today we have flexibility in configuration and a strong API. Often people have a hard time letting go of history, especially with technology we feel has failed us. There are many that assume that any customizations are unwise in JIRA. I wanted to cover JIRA customization and contrast the past with the reality of today. Later in the article I will lay out a few best practices as well so you can get what you want from JIRA without risking too much.

In the not-too-distant past, a typical JIRA installation might have played out something like this:

A group in a company obtains a copy of JIRA Server, installs it, and immediately jumps into configuring all the admin screens to get projects running. They start by using one of the built-in workflows with all the standard transitions. As usage expands, needs are found and are either accommodated by the administrator or met by a nifty add-on that did what was wanted out of the box.

Once in awhile something very specific will be desired to increase efficiency or user adoption, so the admin will go in and modify the database, add some scripts, or edit some of the configuration files directly. A few months later they realize they cannot upgrade JIRA because they would lose all their customizations that they depend on–or perhaps worse, they upgrade and most of their functionality is broken.  

Some companies invest the hours to fight through the upgrade pain and customize a much newer version, but many companies simply stay at a very old version until the application is abandoned. I recently spoke with a company that was still stuck using 4.x, while 7.x is the current version! This cycle is far more prevalent than people realize. Many smaller and mid-sized companies find themselves in this position, I have multiple students in every class facing this very specific dilemma.

Fortunately JIRA customization is far different today than it was a couple of years ago. Atlassian has done a great job moving to a clean API that allows for significant external input while increasing the flexibility of the system. There is a new danger I will talk about in a moment but customization can live across version upgrades today, unlike in the past.

JIRA Customization Best Practices

I typically describe JIRA as a big box of legos. Used properly there are few scenarios that cannot be accommodated with the base system. When approached in an educated way it is incredibly flexible. Here are some guidelines around customizations I share when consulting on JIRA implementations.

1. 

   (Click image to enlarge)

   Understand completely how projects come together. Utilize “Custom Issue Types” to break up your workflows, allow for clearly defined field configurations, and ultimately better reporting. Here is the diagram we use in our classes to teach students how to correctly put together a project.

2. Search for a way to accomplish your goal within the base system. I commonly encounter cases where people moved to Add-ons to do something they could have accomplished by customizing filters, issue types, workflows, or other elements. Only use Add-ons that are truly necessary.
3. Do not view applications in the marketplace as similar to Android or IOS apps. They are more deeply embedded than that and can be a major roadblock in the upgrade process. Approach them cautiously.
4. Use Add-ons that are heavily used and updated often. This seems really obvious but I have run across organizations that are one of 50 people using an add-on that has not been updated for years. Stay on the main road and you will not be left behind.
5. If you have a specific need do not be afraid to integrate using the API. It is powerful, well documented, and can really open up “safe” customizations using BI tools, web integrations, etc.
6. If you use JIRA Server simply DO NOT MODIFY the database or the file structure. Lie down until the feeling goes away. Ignore all the old Confluence pages that tell you how. (I wish Atlassian would take these down)
7. Within JIRA there are issue types specifically created by JIRA Agile. Unless you are comfortable working 100% in the way Atlassians implements Agile, create your own issue types. The behavior, features, rules etc around the Epic and Story issue types WILL change as they continue to develop their products. If you create your own issue type it will behave however you have configured it and will be far less likely to change.

If you follow these best practices (which may need to be modified over time), you are not guaranteed to completely avoid problems. But In our experience you are far less likely to be caught in a situation where an upgrade breaks your customizations. Unlike a couple of years ago we encourage customization as long as you stay on the safe path.

JIRA is easy to get, inexpensive, and generally accepted as a great tool. It is very easy to get off the safe path and into the weeds with such a configurable and powerful tool. Good training and best practices are a sensible choice.