How to Remove (migrated) Suffix from Jira Custom Fields After DC-to-Cloud Migration

If you recently migrated from Jira Data Center to Cloud using the Jira Cloud Migration Assistant (JCMA), you have likely noticed that every custom field got a duplicate with "(migrated)" appended to its name. This is expected JCMA behavior, but cleaning up these duplicates manually is tedious and risky.

This guide walks you through both manual methods to remove the (migrated) suffix from Jira custom fields and automated approaches, so you can choose what fits your instance size and comfort level.

If you need background on why JCMA creates these duplicates in the first place, see our earlier post: What Is JCMA? Why Jira Cloud Migration Assistant Creates Duplicate Fields (And How to Fix Them).

Safety First: What Can Go Wrong

Before diving into methods, understand the risks of deleting or merging fields incorrectly:

• Data loss: Deleting a migrated field without copying its values first erases all issue data stored in that field permanently.
• Broken workflows: Workflows, automation rules, and post-functions referencing a deleted field ID will fail silently or throw errors.
• Scheme mismatches: Screen schemes and field configurations pointing to the wrong field cause fields to disappear from issue views.
• Type conflicts: If the original and migrated fields have different types (e.g., text vs. select list), a direct merge will fail or corrupt data.

Method 1: Manual Cleanup Using the Jira UI

This method requires no tools or scripts. It works for small instances with fewer than 20 duplicate pairs, but becomes impractical at scale.

Step 1: List All Custom Fields

Navigate to Settings > Issues > Custom fields. Scroll through the full list and note every field with a "(migrated)" suffix. For larger instances, use the REST API to export all fields:

GET /rest/api/3/customFields

This returns a JSON array with every custom field's ID, name, type, and creation date. Filter for fields containing "(migrated)" in the name.

Step 2: Match Each Migrated Field to Its Original

For each field named "X (migrated)", find the corresponding original field simply named "X". Compare:

• Field type -- Must match for a safe merge (text, select list, date picker, etc.)
• Description -- Identical descriptions suggest the same field was duplicated
• Creation date -- The original is typically created before the migrated copy

Step 3: Count Issues Per Field

Before touching any field, run a JQL query to count issues referencing each variant:

cf = "Field Name (migrated)"

Note the issue count. If the migrated field has more populated values than the original, you will need to copy data in that direction instead.

Step 4: Copy Values from Migrated to Original

If the original field is empty (or has fewer values), copy data from the migrated field into it. You can do this via:

• Jira Automation rules -- Create a rule that triggers on issue update and copies the migrated field value to the original. Run it once per affected project.
• Bulk edit -- Use Jira's bulk operation feature to update issues in batches of 200-500. This avoids API rate limits.
• REST API with pagination -- For programmatic control, iterate through issues using cursor-based pagination and update each field individually.

Step 5: Update All Configurations

This is the most time-consuming step. Every configuration that references the migrated field must be updated to point to the original:

• Field configurations -- Check each field configuration scheme and update the field mapping.
• Screen schemes -- Remove the migrated field from screens and add the original in its place.
• Workflow post-functions -- Update any transitions that set or read the migrated field.
• Automation rules -- Search for all automation rules referencing the migrated field ID and update them.
• JQL filters and dashboards -- Update saved filters, gadgets, and reports that use the old field.

Step 6: Delete the Migrated Field

Once you have verified that all data has been copied and all configurations updated, delete the "(migrated)" field from Settings > Issues > Custom fields. Start with fields that have zero associated issues to minimize risk.

Step 7: Verify

Run a final scan of your custom field list to confirm all "(migrated)" suffixes are gone. Spot-check a sample of issues to ensure data integrity and that fields appear correctly on issue views.

Method 2: Automated Cleanup Using REST API Scripts

If you are comfortable with scripting, the Jira REST API lets you automate much of the manual process. This approach is faster than Method 1 but requires programming knowledge and careful error handling.

Step 1: Discover Duplicate Pairs

Pull all custom fields via the API and programmatically match pairs by stripping "(migrated)" from names:

GET /rest/api/3/customFields?maxResults=1000

Write a script that groups fields into pairs where one name equals the other plus "(migrated)".

Step 2: Classify Each Pair

Your script should compare field types and issue counts for each pair:

• SAME TYPE, ORIGINAL EMPTY -- SAFE to merge migrated values into original
• SAME TYPE, ORIGINAL HAS DATA -- REVIEW REQUIRED; manual decision needed per field
• DIFFERENT TYPES -- CONFLICT; cannot merge automatically, keep both fields

Step 3: Batch Update Issues

For SAFE pairs, use the bulk update endpoint to copy values. Process in batches of 100-500 issues and add delays between requests to avoid rate limiting:

PUT /rest/api/3/issue/{issueIdOrKey}
{ "fields": { "customfield_XXXXX": "<value_from_migrated_field>" } }

Step 4: Update Configurations Programmatically

Use the field configuration and screen scheme endpoints to update references. This requires iterating through all schemes, finding fields that match migrated IDs, and replacing them with original IDs.

Step 5: Delete Migrated Fields

Once verified, delete each migrated field via the API:

DELETE /rest/api/3/customField/{customfieldId}

Method 3: Automated Cleanup Using Migration Field Cleanup for Jira

If you have 50+ duplicate fields or thousands of issues, the manual and API approaches become time-consuming and error-prone. This is where a purpose-built tool like Migration Field Cleanup for Jira saves significant time and reduces risk.

The app runs entirely inside your Jira Cloud instance using Atlassian Forge -- no external servers, no data leaves your site. Here is how it works:

• One-click scan -- Instantly detects all "(migrated)" duplicate pairs and groups them automatically.
• Safety classification -- Each pair is classified as SAFE, REVIEW_REQUIRED, or CONFLICT based on field type comparison and issue usage data.
• Issue count per pair -- See exactly how many issues reference each field before deciding which to keep.
• Batch merge with progress bar -- Merge hundreds of field pairs in one operation, watching real-time progress.
• Idempotent operations -- Safe to re-run at any time without side effects.

The app is free to install and scan. Merge operations require a license through the Atlassian Marketplace, but most small-to-medium instances can complete their cleanup within the free scan tier.

Which Method Should You Choose?

Clean Up Migrated Fields Before Configuring New Ones

A common mistake teams make is configuring new custom fields in Cloud before cleaning up the migrated duplicates. This creates a cascading problem: JCMA may create new "(migrated)" copies of your freshly created fields on the next migration run or test.

Resources

• Atlassian: JCMA Duplicates and Tracking Entities
• Atlassian: Resolving Configuration Duplication in Jira Migrations
• JIRA Issue MIG-1163: Better handling of duplicate fields
• Atlassian Confluence: DC to Cloud Migration Guide
• Migration Field Cleanup for Jira - Atlassian Marketplace