Sort by Topics, Resources
Topics
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Salto for
Jira
Guides
Battling technical debt in Jira—a guide
Jira performance tends to degrade over time. Often, it’s the result of too many customizations. 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.
Author
Sagi Bracha
8
min read
SHARE
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.
Why does Jira grow over-customized?
It’s more than just server age. Five factors are at play:
- Over-engineered fixes
- Lack of regular maintenance
- Over-accumulation of data
- Multiple geographically isolated administrators
- Administrator turnover
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.
The 5 ways over-customization hurts your ability to manage Jira
1. Performance degrades
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.)
2. The data grows fragmented
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.
3. It burns out administrators
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.
4. Screens and controls grow unusably complicated
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.
5. It makes cloud migrations more difficult
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.
Recommendations for reducing your customizations
If your instance has reached a state of configuration bloat, dial it back with these five approaches.
1. Archive old projects
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.
Learn more about archiving and restoring projects.
2. Delete old issues
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:
- Workflow status is done
- Creation date is more than 3 years ago
- Last issue access was more than one year ago
3. Reduce and rationalize your custom fields
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.
Consider:
- Deleting old fields
- Deleting rarely used fields
- Merging or deleting redundant fields
Prioritizing your custom fields for 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.
How will I know I’m not accidentally deleting a critical field?
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.
How to delete those custom fields
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.
4. Delete anything else extra
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.
5. Prevent over-customization in the first place
If you don’t change your process, the over-customization is likely to continue. Consider:
- Limiting the number of administrators
- Creating project templates
- Reusing existing fields and repeatable elements
- Making field names as obvious as possible
- Archiving projects the moment they become unnecessary
- Scheduling periodic sweeps to delete old issues
- Using apps to track your customizations
Is Jira feeling faster?
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.
What’s next?
Knuckles has suggestions
Jira
Essentials
All resources
No items found.
Enterprise App Configuration. Re-Imagined.
© Copyright Salto 2024 | Various trademarks held by their respective owners
