nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

The Dark Side of JIRA Administration: Have You Crossed the Line?

Gregory Kneller_fxdgrb

Hello, Fellow Jira Administrators!

Have you ever found yourself in situations where Jira’s built-in tools, standard GUI, scripting, or even the REST API just aren’t enough? Tasks like performing bulk changes involving tens of thousands of issues, renaming Issue Security Levels, changing custom field types, bulk updating fields of issues in non-editable statuses, renaming user groups, merging usernames, or similar advanced operations can be extremely challenging—or even impossible—within Jira’s standard capabilities.

This becomes particularly relevant during Jira migrations, large-scale cleanups, or when managing highly customized instances.

Over my 15+ years of working with Jira across various versions in heavily loaded production systems for large enterprises, I’ve often resorted to what I call “Forbidden JIRA Administration”. This involves direct database edits and other unconventional techniques to solve problems Jira’s native tools cannot handle.

While these methods are inherently risky, I’ve been able to execute them successfully by adhering to the principles of risk-aware change management and safe deployment, ensuring system stability and data integrity.

I’d Love to Hear From You!

Have you ever used database manipulations or other “forbidden” methods to manage your Jira instance? For what kind of tasks?
What challenges, risks, or surprises have you encountered while performing such operations?
How do you ensure safety and reliability when stepping outside Jira’s standard tools?

I’m looking forward to hearing your stories, experiences, and insights! Let’s collaborate and share best practices for tackling the limits of Jira.

Comments

Hua Soon SIM [Akeles]

As much as possible, we will prefer using ScriptRunner to do bulk updates via the Jira SDK and groovy scripts.

It is risky to do direct database edits because the relationship is complex and Jira is very extensible with plugins. It is not a trivial task to understand the data usage and design assumptions of each and every apps installed in the system.

The most scary problem is it is ok during testing/verification, but the error surfaced only after a few months. It could mean data patching or data integrity or even data loss.

One way to reduce the risk is to countercheck with Atlassian.
They do provide a number of SQL scripts for patching in the Confluence KB.

Hua Soon SIM [Akeles]

Another question that popped up is how does Jira Cloud users tackle similar issues?

They do not have access to the database and Jira logs.

So is database manipulation really necessary?

Rolf Lader_cy8ul1

If possible, I try to use database access only to get the relevant information and use the methods of the Jira class libraries via Scriptrunner for data manipulation.

In rare exceptional cases (moving users between directories) I have done this through direct database manipulation using stored procedures. Whereby I check and ensure data integrity during the changes.

All operations are verified intensively on test environments before run the changes in production.

Taylor Chase

Count me as another vote for the wonders of Adaptavist's Scriptrunner utility. Saved my bacon a significant number of times.

Atlassian does have advice on a number of database modifications that can be done using example scripts from their documentation, many of which I have had to do at least once.

Though I do have one "Forbidden Jira Administration" technique - our users use Jira to track ALL of their time, and there are a couple of shared cards that have MASSIVE numbers of worklogs attached to them (one had over 10,000 at one count). I have had zero success enticing users to stop doing it, so my forbidden technique involves taking the worklogs in blocks of 1000 and changing the card they are associated with using direct database modification.

Nancy Debnam

We need to disable accounts after ninety days of inactivity. Although, we don't directly change the database, we do query the database for last login dates.

David Yu

Seems like a good start of the Anarchists Cookbook for Jira.

I don't think I have anything too controversial to list, mainly use the DB for read-only maintenance tasks such as:

Deactivating inactive accounts
Find users without avatar pictures and syncing them from Slack
Automatically archive projects if they have the word Archive in them
Delete asset log history directly in the DB
Clean-up invalid inactive/assignees on Service Desk portals
Finding & Scrub PII information from tickets

I also do some light-weight modification of sources. For example, we needed higher number precision in our number fields (0.0005 for example). And still limping along by patching an unsupported Watchers plugin.

Matt Doar _Adaptavist_

Well, necessary perhaps but not so possible. I suppose some of the Cloud backup solutions would allow this and then restore. But that feels even more "forbidden"

Matt Doar _Adaptavist_

I too used to do lots of DB changes for migrations and merges of various kinds. When ScriptRunner came out, I could do lots of that with scripts, which feels safer. The testing is still needed of course.

What makes me raise an eyebrow is the advice from Atlassian not to manipulate the database (especially with Jira running) and then the Knowledge Base articles that give SQL on how to fix a problem.

And I'm going to admit here that if some DB value in Jira isn't cached, then they can be updated while Jira is running. Just test it thorougly and be prepared to restart production if you got it wrong!

Matt Doar _Adaptavist_

"Anarchist's Cookbook for Jira" made me laugh.

But not near any instance I'm responsible for, thank you

Gregory Kneller_fxdgrb

I agree that testing is critical— and not just testing! I make backups of all tables I plan to change before making any modifications.

But restarting Jira after database changes in my experience, is usually not required☠️

Here’s why:

Cleaning Jira’s Cache Often Resolves Most Issues
Tools like ScriptRunner or SIL Engine can be used to clear Jira’s cache, which addresses many potential inconsistencies without needing a restart (however for multi-node datacenters it would be better to restart).
Some Changes Don’t Even Require Cache Clearing
For example, updates to the database table customfieldvalue are available immediately in the issue view.

❗ Reindexing Is Required after 99% manipulations
And this can be a pain point in heavily customised and large instances.

Gregory Kneller_fxdgrb

When a change is truly necessary and cannot be achieved through automation rules, APIs, or apps, I resort to XML manipulations in the cloud backup. However, this process is more complex than working with a database, will require downtime for users, and is challenging to test due to the lack of a test instance in the cloud.

Gregory Kneller_fxdgrb

Reporting from database, or even use sql results for scripts that do the changes using API, is not so risky as direct database manipulations

Gregory Kneller_fxdgrb

Anarchists Cookbook for Jira, thank you, it is a great name!
I am actually think about this writing

Hua Soon SIM [Akeles]

It is much more difficult to do impact assessment for Cloud since the data for apps are not be included in the Cloud backups.

I won't dare to try to modify a Cloud backup 😬

Hua Soon SIM [Akeles]

It might be messy trying to reconcile the records when the user is in the internal directory as well as the LDAP directory.

You might want to try some user deactivation apps for more streamlined operation. The users can be deactivated automatically.

Hua Soon SIM [Akeles]

I would still insist to get a scheduled downtime and stop Jira if there is a need to execute SQL to modify the database.

In event if the database change goes haywire, there is still some time for recovery.

Andrea Mura

Ah, "Forbidden JIRA Administration"! That secret realm every Jira Admin dreams of entering but can’t speak of aloud—like a superhero lurking in the shadows to solve the problems that Atlassian just won’t touch.

Personally, I’ve always felt a bit like a hacker in a 90s movie, with my terminal flashing away while I try to change custom field types or rename user groups. And then, when it all finally works, you feel like a wizard just casting a spell… and hope nothing blows up!

To answer your questions:

I’ve "experimented" with the database a few times, like stepping into Jira’s forbidden playground. But always with my heart racing and a backup in hand, of course.
The surprises? Oh, those are the best part! Like when you change a value and find out you’re actually altering something you shouldn’t, and the system starts doing weird things… like generating errors from another dimension. 😅
Safety and reliability? Well, it’s like being a superhero: you do it all with discretion and a well-thought-out plan, always with a backup as your "magic object" of protection.

We’re all in the same boat, just trying not to sink it with too many "hacks." 😆

adamtwarner94

Just came across this post - I've done a few direct db things here and there over the last 15 years of administering Jira - luckily not much - and always doing it in a test instance first to make sure there were no unintended consequences.

Probably the biggest thing I did was to load a list of 1000+ dropdown options into a custom field which would have taken a LOT of typing and no other good way to satisfy this case. Just created a script to do the initial load and then manually did updates as needed thereafter. There were a couple of gotchas I discovered in testing - one that you have to make sure you update the next option id sequence number, which is also stored in a table, and two that you have to restart jira to see the values you loaded since everything gets cached in startup. But worked fine. If you create a custom field then add a few options through the UI to see the pattern it was pretty easy to see how to load it.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration

database

gui

hack