Custom Field cleanup whilst retaining the field data

[Sara Innes]

Hi there! I'm the administrator of a Jira Cloud environment that was migrated from Server to Cloud a couple of years ago, and existed for a few years before that. 

There is a lot of custom field sprawl (1,111 fields) that our Site Optimiser has found are unused - I reckon I can "clean out" about half of these as they're either duplicates, unused, or even just outright misspellings of fields that got replaced with the correct spelling rather than being renamed. This cleanup will help a lot in my quest to standardise schemes across the site. However, there is a data retention policy of 6 years in my company, and so I need to find a way to satisfy both that and the desire for a spring cleaning. A backup of the site has been done, but unfortunately won't suffice - the data needs to be searchable/accessible within Jira. 

There are 4 pages of active projects on the site, and 3 pages of archived projects - I presume most of the fields identified by the Optimiser as "Never used" are legacy fields that were used by these projects pre-migration, and my searching for "Custom Field X" is not Empty won't identify tickets in archived projects. 

My current plan of action is to unarchive one project at a time, use Scriptrunner to pull every field on all of that project's tickets that has a value, and append that information in plaintext into the description of the ticket. (Or a "Legacy Data" paragraph custom field)

I have a bad feeling that doing this en-masse will cause issues like mass-alerts (and so I planned to change these projects to an Archived notification scheme whilst I did this) or rate limiting. I've got my fingers crossed that there is a better way but would appreciate hearing about how anyone else has accomplished a cleanup like this while retaining the data. 

[Dave Liao · Accepted solution]

This would be a really good Community article! #todo

For sure, remove the easy ones first - anything never used. Perform a JQL query against these fields, sometimes the Site Optimizer is enthusiastic/optimistic. 😂 

For anything seldomly used, try to match the field to-be-retired with an existing field. There may be fields with a legitimate use case, make that THE canonical field and consolidate data from fields-to-be-retired into that field.

Perform bulk update operations to migrate data, and DON'T email users with those updates. 😉 

Ensure no data is hidden by a security level you might not be part of.

In cases where snapshots are important, consider selective CSV exports.

[Sara Innes]

Thanks for the quick reply!

Migrating the obvious misspelled fields into their correct field will be easy enough, but I'm just worried that the things listed as "Never used" according to the optimiser are flagging that way incorrectly (I know for a fact that some were used by archived projects pre-Cloud migration) and the JQL search won't work to find field data in my many archived projects. 

And in the opposite case, fields with default values set are listed as having been used Often despite being on no screens, so it will be a blast to figure out when they were last used legitimately and by whom. 

Is there a way for admins to use JQL searches against the Archived Projects as well as live ones, or to bypass security schemes? Or is it going to be the old-fashioned manual way of touching everything to double-check? 

[Trudy Claspill]

JQL searches can't be used on Archived projects. One of the advantages of Archiving is that the issues are removed from the search index to improve the performance of searching.

Note that there is not an API endpoint to search issues in archived projects.

You could create an "archived" permission scheme that gives only you access to the archived projects, unarchive them, and the associate the new Permission scheme to them. That would give you the ability to use JQL searches against them while keeping the data "hidden" from the rest of the users. You want to maintain a mapping of the original Permission Schemes so you could restore them later.

It also is not possible to bypass issue security schemes. The security schemes (or allocation of users to roles or user groups) would need to be modified such that the person executing the searches was included in all security levels.

[Dave Liao]

What Trudy said!

A view-only permissions scheme would let you query against archived Jira spaces. (Restore a Jira space, then apply the view-only permissions scheme to it.)

I wonder how many Work Item Security Schemes you've got in your Jira... 🔍 

[Sara Innes]

Not too many Security schemes luckily, but LOADS of Field Schemes, Screen Schemes, Work Item Schemes, etc that would be divine to whittle down. 

I've decided to go with y'all's recommendation of the mass-unarchiving and applying the read-only scheme, after which I'm using Scriptrunner to scrape each ticket in those projects and append the existing custom field information (as well as Work Type, Versions, and Components for safety) into the description or comments of those tickets. That way all the data is retained in a field that will never be hidden, and I can fiddle with the old schemes without fear of destroying or hiding any data. 

Once that's done, I'll start my field-cleanup process with the quick wins that truly have no information stored against them and go from there! 

[Petru Simion _Simitech Ltd__]

Hi @Sara Innes ,

Field cleanup in long-lived / migrated Jira sites is always tricky — especially when you also have retention requirements. And you’re absolutely right that simply searching for “field X is not empty” won’t always tell the full story, because:

✔ Archived projects are excluded
✔ A field may still be configured somewhere even if it has no values
✔ Fields may be referenced in screens, workflows, post-functions, or field configs

So before deleting a field, you really need to confirm two independent things:

1️⃣ Is the field ever populated with data?

(historical or current — including archived projects)

2️⃣ Is the field still in use anywhere in configuration?

Examples:

• included in a screen or screen scheme

• referenced in a workflow condition/validator/post-function

• used in a field configuration

• used in transitions or automation

Even if a field is empty today, deleting it when it’s still wired into a workflow/screen can break real-life processes.

---

A safer way to approach cleanup

Instead of unarchiving projects and bulk-rewriting ticket descriptions (which can create noise, audit overhead, and rate-limit pain), I’d recommend getting full visibility first.

Tools exist to map exactly where a field is being used across the site, including projects, screens, workflows, and schemes.

You can use, Fields Usage for Jira an app released by our company.

It lets you see for any field:

✔ whether it’s referenced in screens / schemes
✔ whether it appears in workflows
✔ which projects it’s actually enabled in
✔ whether it is safe to retire

That way you can:

🔍 Identify true legacy fields
🧹 Confidently detach them from configs
🗄 Preserve historical data without rewriting issues
🛡 Avoid workflow/screen breakage
📑 Stay compliant with retention policy

Once you verify a field is not populated and no longer used anywhere in config, then cleanup becomes much safer and predictable.

You can search for all fields or filter them out,  analyze your fields usage or export them to csv for further analyzis.

Regards, 

Petru