This is a recurring issue that many teams face after JCMA migrations. The "(migrated)" suffix gets appended whenever a field with the same name already exists in your Cloud instance, and if you run test migrations or migrate from multiple Data Center instances, it compounds over time.
The approach of scripting automated removal is risky because you need to be careful about data loss. Before deleting any "(migrated)" field, you should verify that its values have been safely merged into the original field first. Deleting a migrated field without merging its data means losing all the issue values stored in that field.
I built an app for this exact problem: Migration Field Cleanup for Jira on the Marketplace. It scans all your custom fields, detects every "(migrated)" duplicate pair automatically, classifies each as safe or requiring review based on schema comparison, and merges the migrated values into originals only when the original is empty. It never overwrites existing Cloud data. Free to install and scan, merge requires a license.
The workflow is: scan first to see the full picture, review safety classifications for each pair, then merge in batches with a progress bar. After merging, you can safely delete the migrated copies since their data is already in the originals.
Full Disclosure: I work for Appcento, the company that built Migration Field Cleanup for Jira.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.