What Is JCMA? Why Jira Cloud Migration Assistant Creates Duplicate Fields (And How to Fix Them)

Jira Cloud Migration Assistant (JCMA) is Atlassian's official tool for migrating from Data Center (DC) to Cloud. During migration, JCMA copies custom fields from your DC instance into the target Jira Cloud site. But here's where things get tricky: if a field with the same name already exists in Cloud, JCMA doesn't overwrite it. Instead, it creates a new field with a "(migrated)" suffix.

Why JCMA Creates Duplicates

• Existing field in Cloud: If your team already created a custom field with the same name as one from DC, JCMA appends "(migrated)" and creates a duplicate.
• Multiple migration phases: Large migrations often run in waves. Each wave can re-create fields that were already migrated, compounding duplicates.
• Test migrations: Teams frequently run test or dry-run migrations to validate the process. These create temporary duplicates that are rarely cleaned up before production migration.
• Default Cloud fields matching DC names: Jira Cloud ships with many default custom fields. If a DC field shares the same name, JCMA treats them as different and creates a "(migrated)" copy.

The result? A DC instance with 50 custom fields can become a Cloud site with 100 to 150+ "duplicate" custom fields. This isn't just a cosmetic issue -- it creates real operational problems.

What This Breaks After Migration

Duplicate fields are not just a naming nuisance. They cause real issues that affect daily operations, reporting accuracy, and system performance.

User confusion

Users see two fields with nearly identical names and don't know which one to use. Some enter data into the original, others into the migrated copy. Data becomes fragmented across both fields.

Broken JQL queries

Jira searches that reference a specific field ID will only return results from one of the two fields. Queries miss data stored in the other, leading to incomplete or misleading search results.

Performance degradation

Jira Cloud has limits on the number of custom fields per project. Excess fields consume index space, slow down issue creation and updates, and increase the overall footprint of your Jira instance.

Reporting errors

Dashboards, gadgets, and automation rules tied to a specific field ID will only capture data from one copy. Reports undercount or misrepresent the actual state of your projects.

Configuration complexity

Screens, workflows, and field configurations must be maintained for every custom field. Duplicates double the configuration surface area, making it harder to manage and audit.

The Manual Cleanup Process

Cleaning up duplicate fields manually is straightforward in concept but tedious at scale. Here's the step-by-step process most teams follow.

Step 1: Inventory All Fields

Export a full list of custom fields from your Jira Cloud instance. Use the Jira REST API or an admin report to capture field names, IDs, types, and creation dates. This gives you the baseline for comparison.

Step 2: Match Pairs

Compare the Cloud field list against your DC export. Identify fields that share a name but differ by suffix (e.g., "Priority" and "Priority (migrated)"). Group them into pairs for cleanup.

Step 3: Determine the Original

For each pair, decide which field is the original and which is the migrated copy. Typically, the field without a "(migrated)" suffix is the original -- but this isn't always reliable. Check creation dates and field history to confirm.

Step 4: Check Issue Usage

Before merging, verify how many issues reference each field. If the "migrated" copy has more populated values, you may need to migrate data from the original into it instead. Use JQL cf[FIELD_ID] queries to count issues per field.

Step 5: Plan the Merge

Create a migration plan that specifies which field in each pair will survive and what data needs to be moved. Prioritize fields by usage count -- merge the most-used pairs first.

Step 6: Execute Merges

Migrate field values from the duplicate into the surviving field using Jira's REST API or a bulk update tool. Update any workflows, screens, and configurations that referenced the old field ID.

Step 7: Verify and Clean Up

After merging, run validation queries to confirm data integrity. Delete the now-empty duplicate fields. Update any automation rules or integrations that pointed to the old field IDs.

Automating the Process

The manual approach works for small instances with a handful of duplicates. But at scale -- hundreds of fields across dozens of projects -- manual cleanup becomes error-prone, time-consuming, and risky.

Migration Field Cleanup for Jira automates this entire workflow directly inside your Jira Cloud instance.

• One-click scan: Instantly identifies all duplicate custom fields and groups them into pairs.
• Automatic safety classification: The app classifies each pair as safe to merge, needs review, or is risky -- based on issue usage and field type.
• Issue count per field pair: See exactly how many issues reference each field before deciding which to keep.
• Batch merge with live progress bar: Merge hundreds of field pairs in one operation, watching real-time progress.
• Runs on Atlassian Forge: No external servers, no data leaves your Jira Cloud instance. Fully compliant with Atlassian's security model.

The app is free to install and scan. Merge operations require a license, but the free tier covers most small-to-medium cleanup tasks.

Prevention Tips for Future Migrations

• Use a non-production test environment: Run your first migration into a sandbox Cloud site. Clean up duplicates there before migrating to production.
• Freeze shared entities during migration: Prevent new custom fields from being created in either DC or Cloud while the migration is underway.
• Do a big bang migration: Avoid multiple incremental migrations. One clean pass reduces the chance of duplicate creation.
• Document your field inventory: Maintain a living document of all custom fields, their purposes, and their IDs. This makes post-migration cleanup far easier.

Resources

• Atlassian KB: How to Resolve JCMA Duplicate Custom Fields
• Atlassian Confluence: DC to Cloud Migration Guide
• JIRA MIG-1163: JCMA should detect and warn about duplicate custom fields
• Migration Field Cleanup for Jira - Atlassian Marketplace