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]

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?