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

Trying to clean up custom fields from a migration

Mike Ruthven

Hi there!

Our company was a spin out from a much larger company, and when our Jira project was migrated out, a great deal of information that existed in the larger company's Jira cloud projects came with it. I've been cleaning up, but currently am faced with 932 custom fields in our system, of which we need...possibly zero, honestly.

I'm comfortable using the REST API and have a script that shows me the list of custom fields, but that only shows 29 custom fields. I am an org-admin for our site, and have tried calling with a personal token, or one created via the organization settings page, same results. I am assuming I'm just missing something obvious that is limiting what the call returns. Any help is appreciated!

Thanks,

Mike

Accepted answers

Vishal Biyani_2pr07j

@Mike Ruthven

have you run this end point to get the list of fields?

https://your-cloud-instance.atlassian.net/rest/api/3/field

Once you have identified the fields you should be able to use below endpoint to delete the custom fields

url = "https://your-domain.atlassian.net/rest/api/3/field/{id}"

Refer link: The Jira Cloud platform REST API

All comments

Valerie Knapp_dpp5c6

Hi @Mike Ruthven , welcome to the Atlassian Community and thanks for your question.

I refer you to an article by my fellow community leader, @Darryl Lee

https://community.atlassian.com/t5/Jira-articles/Tidying-Up-Jira/ba-p/1748466

What I typically recommend after a migration is to install the free trial of an app like Optimizer https://marketplace.atlassian.com/apps/1217194/optimizer-for-jira?tab=overview&hosting=cloud or https://marketplace.atlassian.com/apps/6398/jira-command-line-interface-cli?hosting=cloud&tab=overview , which can help you identify and remove in bulk things like inactive workflows, unused screens and custom fields.

Anyway, please read the article and check out the apps to see if they help you.

If you have more questions or doubts, please let us know.

Best of luck!

Vishal Biyani_2pr07j

@Mike Ruthven

have you run this end point to get the list of fields?

https://your-cloud-instance.atlassian.net/rest/api/3/field

Once you have identified the fields you should be able to use below endpoint to delete the custom fields

url = "https://your-domain.atlassian.net/rest/api/3/field/{id}"

Refer link: The Jira Cloud platform REST API

Petru Simion [Simitech Ltd.]

@Mike Ruthven ,

Cleaning up custom fields can be a daunting task. You need to determine if they're used anywhere, identify redundant fields with similar meanings, and simplify by consolidating multiple fields into one. Custom fields can be embedded in various places, including:

- Screens (create, edit, and view)
- Workflows, where fields are used in actions, transitions, or other workflow steps

Manual searching is extremely time-consuming and prone to errors. An automated solution is essential to efficiently identify and optimize custom fields

If you are open to using apps, you can use Fields Dashboard for Jira , an app released by our company.

Search and filter custom fields across your organization's projects with precision. Choose to:

- Search all fields in all projects
- Filter by specific projects and fields

Analyze field usage from two distinct perspectives:

1. Screen Scheme Perspective: View how fields are utilized in projects through their inclusion in create, edit, and view screens.

fields_dashboard_fields_in_screen_schemes_large_result.png

2. Workflow Scheme Perspective: Examine how fields are employed in projects as part of screens used by workflow actions.

fields_dashboard_workflows_search_result_unfiltered.png

Regards,

Petru

Mike Ruthven

Hey Vishal,

I have run that endpoint, yes. It only returns 29 fields, but the UI shows me > 900. So I'm trying to figure out what permissions I would be missing (I am an org admin) that would not return all 900+. I realize there is pagination but at 29 that is not the boundary that I am hitting I don't believe.

Mike Ruthven

Hi Petru,

I will have a look at this tool. The issue is less trying to analyze the custom fields, and more the ability to just remove them in bulk. We exported a very simple project from our parent company's instance when we were spun out, and we seem to have gotten all the custom fields from all of their projects in our instance. I know that we are only using a handful of fields, and the proliferation of custom fields has been zero at the new company, so I can almost certainly just remove _all_ custom fields, and then could clean up any mess afterwards, though this would be a better way to skip that cleanup step.

Mike Ruthven

Hi Valerie,

Thanks for the reply! The article you linked seems to be geared for a workspace that has grown a bit too organically over time, where I'm in "spun out from large company, inherited a huge amount of customization from that large company, don't want _any_ of it." I have installed the CLI and am getting permission issues, as running the `getFieldList` command gives me a 401. I am an org admin in this workspace, so I'm struggling with what I might have done incorrectly when generating my access token.

Vishal Biyani_2pr07j

@Mike Ruthven

as per documentation, one of the reasons why the fields are not returned is below

is it possible that some of the fields are not mapped to any project?

Mike Ruthven

Oh. It hadn't even occurred to me to read it that way. That is almost certainly the problem. OK. I kind of get the feeling I'm going to have to one-at-a-time delete them from the UI.

David Day: Appcento

I've been in your shoes, went through a DC-to-Cloud migration with JCMA and ended up with hundreds of "(migrated)" duplicates across custom fields, schemes, and automation rules. The manual approach is brutal because you have to check each field type (select list, user picker, etc.) individually before renaming or merging.

What helped me was a systematic scan first, identify which duplicates are safe to merge vs. which ones conflict with existing data.

I ended up creating a Forge-based app (Migration Field Cleanup: https://marketplace.atlassian.com/apps/353982928) that classifies duplicates as SAFE / REVIEW_REQUIRED / CONFLICT so you don't accidentally overwrite active field data. It also handles the "(migrated)" suffix removal in bulk, including custom fields tied to automation rules and archived projects (which is where most people get stuck).

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

optimizer