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; } } }

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.

Accepted answers

Dave LIAO

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.

All comments

Dave LIAO

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

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 P 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... 🔍

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.

fields_dashboard_scheme_search_result_for_designated_projects_and_only_custom_fields.png

fields_dashboard_workflows_search_result_unfiltered.png

Regards,

Petru

David Day: Appcento

This is a tricky one because cleanup and compliance pull in opposite directions. The approach that works for us: archive the field rather than delete it, archived fields keep their data intact and you can restore them if needed, which satisfies retention requirements. Then create a new clean field with the proper naming convention and migrate active issues over.

For historical data on the old field, you don't need to touch it, it stays in the database and is accessible for reporting or audits even though it's archived. The key is documenting which fields are archived and why so your compliance team can trace back if they ever need to pull reports from them.

Welcome!

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

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud