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

[Gregory Kneller]

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.

[Sim]

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.

[Sim]

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?

[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"

[Gregory Kneller]

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.

[Sim]

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 😬 

[Rolf Lader]

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.

[Gregory Kneller]

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

[Sim]

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.

[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_]

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

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

[Gregory Kneller]

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

[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!

[Gregory Kneller]

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:

1. 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).  

2. 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. 

[Sim]

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.