Merge Duplicate Custom Fields Without Losing Data: The Complete Guide for Jira Admins

You open Jira's custom field admin screen and your jaw drops. What you expected to be a clean instance with 80 fields now shows over 300, many of them duplicates created by JCMA, test migrations, or teams working in silos. You know you need to merge these duplicates, but every method you find online comes with warnings about data loss.

This guide gives you a complete decision framework and step-by-step methods for merging duplicate custom fields safely, so your team gets a cleaner Jira without losing a single piece of issue data. 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).

The Hidden Cost of Duplicate Fields

Duplicate custom fields are not just a cosmetic annoyance. They create real operational, performance, and compliance problems that compound over time.

Why duplicates exist beyond JCMA

While JCMA is the most common source of duplicates (creating fields with a "(migrated)" suffix when a same-named field already exists in Cloud), it's far from the only cause. Here are the other ways your instance accumulates duplicate fields:

• Organic growth across teams: Different project teams create their own "Priority," "Status," or "Component" fields without knowing others exist. Each team solves a real problem, they just solve it redundantly.
• Multiple migration phases: Large organizations often migrate in waves. Wave 1 creates the original duplicates. Wave 2 may create new ones if teams added fields between migrations.
• Test and dry-run migrations: Teams run test migrations to validate their process. These create temporary duplicate fields that are rarely cleaned up before production migration.
• Default Cloud fields matching DC names: Jira Cloud ships with many default custom fields. If a Data Center field shares the same name, JCMA treats them as different and creates a "(migrated)" copy.

The 700-field limit urgency

In March 2026, Atlassian enforced a hard cap of 700 custom fields per Jira Cloud instance. This is not a soft warning, it's a guardrail that blocks new field creation entirely once reached. See the full details in Atlassian's documentation on data limits and guardrails.

Many admins underestimate how close they are to this limit. In an internal survey, one admin reported: "I guessed somewhere between 50 and 100 custom fields. Then I opened the admin screen and found 400." Duplicates alone can push you past the threshold without any new legitimate fields being added.

Real-world performance impact

Atlassian's own scaling tests revealed significant performance degradation as field counts grow. An instance with 2,800 custom fields showed dramatically slower response times compared to one with 1,400 fields. The most dramatic case: one customer went from 12-13 second issue creation times down to approximately 2 seconds after a thorough duplicate cleanup.

That's not just a speed improvement, it's the difference between a usable system and one that frustrates your entire team into abandoning Jira altogether.

Why Jira Has No Native Merge Tool

You might wonder: if duplicate fields are such a widespread problem, why doesn't Atlassian provide a built-in merge tool? The answer lies in Atlassian's design philosophy and the inherent risks of merging.

Non-destructive by default

Atlassian has consistently designed Jira to avoid destructive operations. Deleting or overwriting data, even when it seems obvious that two fields are duplicates, carries a risk of data loss that Atlassian is unwilling to accept as the default behavior. This is why their knowledge base offers workarounds (CSV import, automation rules) rather than a proper merge tool.

Same name does not mean same field

Two fields named "Priority" might look identical at first glance but differ in critical ways: different field types, different contexts (project vs. global), different workflow configurations, or different data stored in each. A naive merge tool could silently overwrite one field's values with another's, causing irreversible data loss.

Atlassian's own KB acknowledges this gap directly: "Two or more custom fields have the same name in Jira" provides workarounds but explicitly notes that no native merge functionality exists.

The Safe Merge Decision Framework

Before you touch any field, you need a decision framework. Not every duplicate pair should be merged, some are better hidden or deleted outright. Here's how to classify each pair:

The key insight: merge is only appropriate for SAFE pairs. For REVIEW_REQUIRED pairs, you need human judgment. For CONFLICT pairs, merging would cause more harm than good, renaming and hiding is the safer approach.

If you're also cleaning up "(migrated)" suffixes after a JCMA migration, see our guide: How to Remove (migrated) Suffix from Jira Custom Fields After DC-to-Cloud Migration.

Step-by-Step Methods for Merging Duplicates

Five methods exist for merging duplicate custom fields, ranging from Atlassian's official workarounds to purpose-built tools. Each has different risk profiles and suitability depending on your instance size.

Method 1: CSV Import (Atlassian's Official Approach)

This is the method described in Atlassian's KB article on merging two custom fields into one. The process involves exporting field data, manually merging it in a spreadsheet, and re-importing.

1. Export: Use Jira's export feature or REST API to pull all issues containing values from both duplicate fields into CSV format.
2. Merge in spreadsheet: Open the CSV, create a merged column that combines values from both fields (prioritizing non-empty cells), and save as new CSV.
3. Re-import: Import the merged data back into Jira, targeting only the surviving field.

Method 2: Jira Automation Rules (Atlassian's Official Approach)

Atlassian also recommends using automation rules as a workaround. You create a scheduled rule that checks each issue and copies values from the duplicate field into the surviving field.

1. Create an automation rule with a schedule trigger (e.g., daily at 2 AM).
2. Add conditions: "Issue has value in Field A" AND "Field B is empty."
3. Add the action: Edit issue, set Field B to the value of Field A.

Method 3: ScriptRunner Built-in Scripts (Data Center / Server)

If you are on Jira Data Center or Server with ScriptRunner installed, the built-in "Copy Custom Field Values" script provides a powerful way to merge fields programmatically.

1. Navigate to: Settings > Add-ons > ScriptRunner > Console > Built-in Scripts.
2. Select: "Copy Custom Field Values."
3. Configure: Source field, target field, and optional JQL filter to limit scope.

Method 4: REST API with Pagination

For teams comfortable with programming, the Jira REST API offers full control over the merge process. This approach works in both Cloud and Data Center.

1. Pull all custom fields via GET /rest/api/3/customFields and identify duplicate pairs.
2. For each SAFE pair, iterate through issues using cursor-based pagination: GET /rest/api/3/search?jql=cf[FIELD_A] is not empty&maxResults=100.
3. Update each issue via PUT /rest/api/3/issue/{issueIdOrKey}, setting the target field value from the source field.
4. Add delays between requests to respect rate limits (typically 100-300 requests per minute in Cloud).

Method 5: Migration Field Cleanup for Jira (JCMA)

Migration Field Cleanup for Jira is a purpose-built Forge app that automates the entire duplicate field workflow inside your Jira Cloud instance. No external servers, no data leaves your site.

• One-click scan: Instantly identifies all duplicate custom fields and groups them into pairs.
• Smart matching: Automatically matches fields by name similarity, type, and description, not just exact name matches.
• Safety classification: Each pair is classified as SAFE, REVIEW_REQUIRED, or CONFLICT based on field type comparison and issue usage data.
• 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.
• Zero data loss guarantee: The app checks if the target field is empty before writing, it never overwrites existing Cloud data.

The 7 Critical Pitfalls (And How to Avoid Them)

Even with the right method, merging duplicate fields carries risks. Here are the seven most common pitfalls and how to avoid each one.

Pitfall 1: Overwriting Existing Cloud Data

The problem: You merge values from a migrated field into the original, not realizing that your team has been entering data into the original since migration. The merge overwrites all those post-migration entries.

The fix: Always check if the target (original) field is empty before writing to it. If it has values, do not overwrite, instead, copy from original into migrated, or keep both fields and rename one for clarity.

Pitfall 2: Type Mismatches Between Field Pairs

The problem: Two fields named "Priority" but with different types (one is a select list, the other is free text). A merge attempt will fail or corrupt data.

The fix: Validate field types before merging. Only merge pairs where both fields have identical types. For CONFLICT pairs, rename and hide rather than merge.

Pitfall 3: Breaking Workflows and Automation Rules

The problem: After merging and deleting a field, workflows, automation rules, or post-functions that referenced the old field ID break silently. Issues may fail to transition or lose critical data.

The fix: Before deleting any field, search for all references: workflow schemes, automation rules (search by field name in rule conditions), and screen configurations. Update each reference before deletion.

Pitfall 4: Not Checking Issue Usage Before Merging

The problem: You assume the field without a "(migrated)" suffix is always the original with more data. In reality, the migrated copy may have accumulated more values over time.

The fix: Run JQL queries against both fields to count issues with populated values. Let the data guide your merge direction, not assumptions about naming conventions.

Pitfall 5: Cascading Duplicate Creation

The problem: You spend weeks cleaning up duplicates, then add new custom fields before running a test migration. JCMA creates new "(migrated)" copies of your freshly created fields, undoing all your work.

The fix: Complete your cleanup BEFORE adding new custom fields. See our post-migration checklist for the full sequence: JCMA Post-Migration Checklist.

Pitfall 6: JQL Filter Breakage After Field Renaming/Deletion

The problem: Saved filters, dashboards, and gadgets that reference a specific field ID stop returning results after the field is merged or deleted. Users lose access to reports they depend on daily.

The fix: Before merging, export all saved JQL filters and dashboard configurations. After the merge, update each filter to reference the surviving field ID. Test every dashboard gadget that uses the affected fields.

Pitfall 7: Context Issues with Migrated Fields Becoming Unsearchable

The problem: After merging, some migrated fields may lose their context (project or issue type associations), making them unsearchable even though data exists in them. This is particularly common when fields were created with narrow contexts.

The fix: After merging, verify that the surviving field has the correct context for all projects and issue types where it was previously used. Add missing contexts as needed via Field Configuration Schemes.

What Happens After the Merge

Merging duplicate fields is not a single operation, it triggers a chain of downstream effects that you need to address systematically.

Issue history implications

Jira's issue history tracks changes by field ID, not by field name. After a merge, the historical record will show that values appeared in the surviving field at the time of the merge, it loses attribution to the original source (whether that was a DC migration or an earlier Cloud entry). This is generally acceptable but important to document for audit purposes.

Dashboard and report rebuilds

Any dashboard gadget, report, or filter that referenced the deleted field's ID will break. You need to update each one to point to the surviving field's ID. This is often the most time-consuming post-merge task.

Automation rule updates

Search your entire automation library for rules that reference either field in the merged pair. Update conditions, actions, and notifications to use the surviving field ID. Test each updated rule in a sandbox project first.

Screen and field configuration updates

Remove the deleted field from all screens where it appeared. Ensure the surviving field appears on the correct screens for each issue type. Review Field Configuration Schemes to confirm the surviving field is included in all relevant configurations.

Prevention, How to Avoid Duplicates Going Forward

Cleaning up duplicates is expensive and risky. Preventing them from happening again is far cheaper. Here are the governance practices that keep your field count manageable.

Implement a reuse-before-create policy

Require every team to search existing custom fields before creating new ones. A simple JQL search for the intended field name across all projects reveals whether a suitable field already exists. Make this a mandatory step in your field creation workflow.

Establish field naming conventions

Standardize naming with clear prefixes or suffixes that indicate purpose and ownership: [TEAM] FieldName, proj_FieldName, or a shared taxonomy document. This makes duplicates immediately visible during the search-before-create step.

Practice context discipline

Only apply custom fields to the projects and issue types that actually need them. Overly broad contexts (e.g., applying a field to all projects when only one needs it) increase the chance of confusion and duplicate creation by other teams.

Complete cleanup before adding new fields

This cannot be overstated. If you are planning to add new custom fields, complete your duplicate field cleanup first. Adding new fields while duplicates still exist creates a moving target that makes future cleanup harder.

Resources

• Atlassian KB: How to Merge Two Custom Fields Into One (CSV and Automation workarounds)
• Atlassian: JCMA Duplicates and Tracking Entities
• Atlassian: Resolving Configuration Duplication in Jira Migrations (Pre-Migration Checks)
• Atlassian KB: Two or More Custom Fields Have the Same Name
• Atlassian: Data Limits and Guardrails (700-Field Limit)
• JCMA Creates Duplicate Fields (And How to Fix Them)
• How to Remove (migrated) Suffix from Jira Custom Fields