Customizations add data. Excess data can make Jira laggy and unresponsive. It often starts as small performance issues—slow queries, sluggish projects—but over years, they accumulate until issues no longer index, and it’s difficult to manage or update the instance at all. Eventually, the system is so ridden with technical debt nobody has time to pay it down.
This guide explains how to fight back. We’ll explore the causes of over-customization, the impact they have, and ways to clean things up.
It’s more than just server age. Five factors are at play:
Of the five factors, over-engineered fixes is the most destructive. Because there are often multiple ways to configure something in Jira, and no guardrails to keep configurations consistent, people tend to fix things in overly creative ways. Rather than learning what all prior teams did and devising an elegant, minimal fix, they brute force it because they’re busy. If people copy those over-engineered fixes, that debt becomes intrinsic to the system.
People tend to fix things in Jira in overly creative ways.
And these five factors don’t occur in isolation. They compound. One administrator in one location may slightly over-engineer components, then leave, and their peers in another location build upon it because they couldn’t understand it. Other administrators find they’re always deprioritizing maintenance in lieu of crises in other Atlassian apps.
The debt accumulates until people avoid updating Jira. Sometimes, it’s enough of a pain to work with, that administrators quit. The accumulation of configurations and data make each successive change slightly harder until the entire system is so sluggish, JQL queries cease to function.
Let’s explore the impact these five forces can have on your instance, which will provide clues as to how to address them.
When a Jira instance reaches thousands of customizations, users start to notice the pages load slowly. For administrators, those load times are even worse and the custom fields page may take several minutes to load. If you add another 1,000 customizations, it’s not uncommon for those performance issues to cascade to other areas, such as indexing, which makes it difficult to retrieve information.
In Figure 1, we can see how doubling the number of custom fields in an instance impacts response times. If you double the number of customizations, creating an issue takes twice as long. Searching with JQL takes 2.5x as long. (Data provided by Atlassian.)
Over-customization affects your reporting, too. If teams aren’t strict about enforcing conventions, other administrators can create duplicate workflows, issue types, and custom fields. This then fragments their data and makes it difficult to run meaningful reports. For example, consider a user who configures a report to look for all issues with a “waiting for vendor” status, and does it based on the filter “waiting for vendor.”
At first, this report works. But as other users create other variants of that status—waiting for a vendor, waiting for a request—that report ceases to show everything. And unless the person who built that report checks it, they won’t know it’s incomplete.
It’s far more work to correct over-configuration than it is to commit it. This can grow extremely frustrating to administrators who’ve inherited an instance, or whose peers aren’t as diligent in their customizations. It might take that person 3-4x longer to reverse-engineer something than it would have to just build it correctly themselves. If peers are always building things incorrectly, or simply don’t coordinate, the technical debt can grow out of control and make work miserable.
After enough over-customization, Jira screens can contain so many fields they look like an airplane cockpit. This makes it more difficult for users to query or input information. It also makes the system much harder to learn, which elongates people’s onboarding and invites human error.
Over-customized instances create a tangle of dependencies that can stall or defeat your cloud migration. If you plan to migrate your Jira instance to the cloud, put the time in now. Clean up your instance. Remove unnecessary data, elements, and customizations. Reduce the number of workflows as much as possible. The migration will amplify anything wrong so if it’s a pain now, it may be a total blocker later.
If your instance has reached a state of configuration bloat, dial it back with these five approaches.
Archiving old projects helps with performance because once archived, the index ignores that project’s data. It also reduces the clutter in your lists and on your screens. Archiving is also reversible, so there’s little risk. Search old projects that are no longer used, and that no one will miss if they suddenly stopped appearing in project pickers, lists, search results, and JQL autocompletes.
Because archiving is easily undone, err on the side of over-archiving. Like minimalists do when clearing a house of unwanted possessions, archive things you aren’t sure about and see if anybody notices. If you ask them all what they wanted to save, they’ll probably say everything. But if you quietly place things in the archive? Often, nobody ever asks.
Unlike archiving projects, deleting is irreversible. Once an issue is deleted, it’s gone forever. Thus, it’s higher risk, but still worth pursuing. You may have positively ancient issues that nobody’s touched for years, and which they won’t miss. This is also an important step to take before migrating to the cloud, where that glut of unnecessary data would eat away at the cloud instance’s performance.
To analyze which issues you can safely delete, export those issues to CSV and manipulate it on your desktop. Jira can only export 1,000 issues at a time, so if you need to export more, you can use a tool like Exporter. That app will also reveal issue data like transition logs, comments, and attachments that allow you to understand those issues in greater detail.
Criteria for deleting:
Custom fields are easy to create but difficult to delete, because you never really know what else relies on them. For that reason, they tend to over-accumulate. People may also add new fields inefficiently, adding multiple separate checkbox fields that could have been one field with multiple checkboxes. Or, open text fields that could have been a dropdown. You now have the power of hindsight and can audit your custom fields and draw up a list of candidates for rationalization, reorganization, and deletion.
How will you know which custom fields can go? In Jira Data Center 8.16 and later, you now have tools. The custom fields page includes columns that show the usage of each custom field—how many issues actually use them and when the last value was changed. You can sort them by usage and begin at the bottom of the list.
You can also use Jira’s built-in custom field optimization tool, available in Jira Data Center. It’ll scan your custom fields and highlight ones that are misconfigured, could be retired at no cost, or are rarely ever used.
A third way is to use third-party apps such as Custom Field Toolbox for Jira. It shows you where your custom fields are used in issues, screens, workflows, and saved filters.
And finally, if you’re comfortable with SQL, you can also use that. For example, the query in Figure 4 returns all custom fields that have been used fewer than five times.
If you want to ensure your selected field doesn’t have a critical dependency with other elements, you can use an app like Salto. It extracts your configuration to analyze it and tell you all the dependencies of every element. It’ll also show you dependencies other apps won’t.
The simplest way is to navigate to Administration → Issues and select Custom fields. Find your custom field, and select Actions → Delete.
You can also use the Jira Command Line Interface (CLI) app and the removeCustomField function. Provide the custom field name/id to the CLI action in Figure 6 and run it.
After you’ve addressed projects, issues, and fields, delete anything else extra, such as boards, workflows, workflow statuses, screens, issue types, and roles. The more data you can delete, the more you help your performance.
If you don’t change your process, the over-customization is likely to continue. Consider:
Customizations make Jira sluggish. They impact performance, user experience, and administrator usability. It’s crucial to continuously optimize your instance and think in terms of systems—guardrails, templates, and documentation—to keep it running optimally. Especially if there’s a cloud migration in your future.
The rich text element allows you to create and format headings, paragraphs, blockquotes, images, and video all in one place instead of having to add and format them individually. Just double-click and easily create content.
A rich text element can be used with static or dynamic content. For static content, just drop it into any page and begin editing. For dynamic content, add a rich text field to any collection and then connect a rich text element to that field in the settings panel. Voila!
Headings, paragraphs, blockquotes, figures, images, and figure captions can all be styled after a class is added to the rich text element using the "When inside of" nested selector system.