Key Takeaways
- Project settings own screens, field configurations and field contexts, and those are exactly where a "(migrated)" field quietly hides after a migration.
- A field can be global or limited by context, so a field visible in one project may not exist at all for another.
- Audit each project field by field, remove duplicates from screens and configurations before you delete, and merge the data first.
Every project on your site can show a different set of fields, and after a migration that quiet per project detail is the reason two teams end up looking at two versions of the same issue without realizing it.
Migration moves the fields, but it does not tell you which projects still reference the duplicated ones. This guide maps the project settings that control fields, shows where a "(migrated)" field hides, and gives you an audit order that keeps you from deleting something a team still depends on.
The Project Settings That Control Fields
Five settings run the show. A field configuration decides whether a field is visible or required. A field configuration scheme assigns that configuration to one or more issue types in a project. A screen decides what appears when a user creates, views or edits an issue, and screen schemes and issue type screen schemes connect those screens to projects. A field context decides which projects a field is available in and whether it can be customized per project.
Change any link in that chain and a field can appear in one project and vanish in another. That is why a duplicate field can be obvious to one team and invisible to the next.
Where Migrated Duplicates Hide in Project Settings
On a screen
Screens are the most visible hiding place. After a migration a create or edit screen can carry both "Severity" and "Severity (migrated)", so users see two fields that mean the same thing and fill in whichever they notice first.
Workaround: open each screen under Project settings and remove the "(migrated)" field from the layout, but only after its data is merged into the original. Removing it from the screen hides it, the field still exists until you delete it.
In a field configuration
A field configuration can mark a duplicate as required. If "Severity (migrated)" is required while the original is optional, users are forced to fill the wrong field on every create, which keeps the duplicate alive with fresh data.
Workaround: review the field configurations in use by the project, clear any required flag on the duplicate, and confirm the original carries the required setting you want. Do this before the merge so new issues stop feeding the copy.
In a field context
A field context scopes a field to specific projects. A "(migrated)" field may arrive with a context that covers the whole site while the original is scoped to two projects, or the reverse, so the two fields appear in different places entirely.
Workaround: list the contexts for both fields and compare the project lists. If the duplicate covers projects the original does not, add those projects to the original context and migrate the data before you remove the copy. The context endpoint is covered in the REST API audit guide.
In a shared field configuration scheme
Field configuration schemes are often shared across projects. Removing a field from a scheme to fix one project can pull it from every project that shares the scheme, which is how a safe looking edit breaks a team you forgot about.
Workaround: check how many projects each scheme serves before editing. If the impact is wider than intended, copy the scheme, attach the copy to the one project, then make the change there.
Audit Order for a Single Project
Work from the data out to the configuration, so you never delete a field that still holds values.
- List the fields in the project and flag every name containing "(migrated)".
- For each flagged pair, count the issues holding values in both fields.
- Merge the pair, filling the original only where it is empty.
- Remove the duplicate from screens and clear any required flag in the field configuration.
- Compare field contexts and move any project scope the original was missing.
- Delete the duplicate only once it is off every screen and configuration and its data is merged.
- Repeat the quick pass on the next project, some pairs will be no-ops because the field was never used there.
Run it project by project and the site gets cleaner in a predictable way. Rushing any single step, especially the merge before the delete, is how a field with live data disappears for good. The wider sequence sits alongside the rest of the post migration work in the JCMA post-migration checklist.
Resources
- What Is JCMA? Why Jira Cloud Migration Assistant Creates Duplicate Fields
- JCMA Post-Migration Checklist: What to Clean Up After Migrating
- How to Merge Duplicate Custom Fields Safely
- Jira Custom Field Types Explained: A Post Migration Reference
- Atlassian: What gets migrated with the Jira Cloud Migration Assistant
The project by project audit is where Migration Helper earns its keep. It scans for "(migrated)" fields, matches each to its original, compares the schema, and merges in one click, filling the original only when it is empty so Cloud native data is never overwritten. It runs entirely on Forge, and teams of 50 or fewer users can scan and merge free. Install Migration Helper from the Atlassian Marketplace.
Ready to clean up duplicate fields?
Install Free →