Key Takeaways
- The field type is the strongest signal for whether two fields can be merged, a matching name means nothing when the underlying types differ.
- Several Data Center field types have no Cloud equivalent, JCMA logs them as unsupported and the field arrives present but empty.
- Use the type as the first filter in cleanup, merge same-type pairs and send every type mismatch to manual review.
Ask five admins what a cascading select field is and you will get four answers. After a migration that guesswork gets expensive, because the field type, not the field name, decides whether two fields can ever be merged without corrupting values.
This reference walks the custom field types you will meet in Cloud after a Data Center migration, what each one does, and how its type shapes the cleanup decision. Keep it open next to your field list.
Why the Field Type Decides Everything
When JCMA hits a name collision it copies the field and tags the copy "(migrated)". Two fields with the same name are not the same field. One may be a single select and the other a multiple choice, or one a short text and the other a paragraph. Merge those blindly and every value either fails silently or lands in the wrong shape.
The type is the first thing to compare. Same type means the merge is usually safe. Different type means stop and fix it by hand. That single rule keeps most cleanups out of trouble, and the rest of this guide fills in the detail behind it.
The Custom Field Types You Will Meet
Text types
Short text holds a single line. Paragraph holds free text across multiple lines. Rich text is a Cloud style editor field with formatting. All three carry string data and merge cleanly when the types match.
Workaround: before merging, check the field description and any length limit. A short text that held issue numbers merges fine, but a paragraph that held structured notes can lose line breaks when funneled into a single line field, so confirm both sides are the same type first.
Number and date types
Number and Story Points hold numeric values. Date Picker and Date Time Picker hold timestamps. Numbers merge cleanly when the precision matches, dates depend on timezone handling between the two sites.
Workaround: for date pairs, spot check a few values in both fields before merging so you catch a day shift from a timezone difference. For numbers, confirm neither field rounds decimals differently.
Option types
The option family covers Select List (single choice), Select List (multiple choices), Radio Buttons, Checkboxes and Cascading Select. They store a fixed set of choices, and each field carries its own option list. Cascading Select adds a parent and child tree on top of that.
Workaround: merging two option fields means reconciling the option lists, not just the values. Compare the option sets first, add any missing option to the target field, then merge. For cascading select, review the parent and child tree, a flat merge will drop the child level.
People and group pickers
User Picker (single and multiple) and Group Picker store references to accounts and groups. They move only when the referenced account exists in Cloud.
Workaround: verify the users and groups are present in Cloud before merging. A picker field can look empty after migration simply because the account was skipped, in which case merging does nothing useful until the user is restored.
Relationship and system linked types
Epic Link, Parent Link, Sprint, Rank and Team are system fields tied to Jira behavior rather than to a value you type. JCMA handles most of them, but they can still duplicate after a re-run and then split the relationship data.
Workaround: do not merge system linked fields by hand. Fix the hierarchy configuration and use the native parent relationship instead, the steps are in the issue type hierarchy guide.
Calculated and app-provided types
Scripted fields from ScriptRunner, JMCF and similar apps compute their value on the fly. Most have no direct Cloud equivalent, and JCMA cannot carry the script across.
Workaround: treat these as rebuild items, not merge items. Note what each script produced, find a native Cloud field or an app that covers the same logic, then migrate the historical values with a CSV import keyed on issue key.
A Quick Reference for Post Migration Cleanup
| Field type | Merge behavior | What to do |
|---|---|---|
| Short text / Paragraph | Safe when both sides match | Merge, then confirm no formatting loss |
| Rich text | Safe with another rich text field | Merge, check embedded formatting |
| Number / Story Points | Safe when precision matches | Merge, spot check decimals |
| Date / Date Time | Usually safe | Merge, watch timezone shifts |
| Select (single / multiple) | Safe after option lists match | Union the options, then merge |
| Cascading Select | Safe with another cascading field | Review parent and child tree first |
| User / Group Picker | Safe if the account exists | Verify users, then merge |
| Epic Link / Parent Link | Do not merge by hand | Fix hierarchy, use the native link |
| Scripted (app provided) | Different schema, unsafe | Rebuild in Cloud, import values via CSV |
How to Check a Field's Type
The plainest route is the field configuration page in Cloud, which names the type under each field. For a whole site at once, call the field endpoint and read the schema block, the response spells out the type and the custom type key for every field on the instance.
If you would rather script the whole audit, the REST API guide walks through the call, the JSON shape and a loop that counts issues per field so you know which pairs carry data.
Resources
- What Is JCMA? Why Jira Cloud Migration Assistant Creates Duplicate Fields
- How to Merge Duplicate Custom Fields Safely
- How to Remove the (migrated) Suffix from Jira Custom Fields
- Using the Jira Cloud REST API to Audit Custom Fields
- Atlassian: Troubleshoot migration with Jira Cloud Migration Assistant
Type checking is the part admins skip and then regret. Migration Helper reads the schema of both fields in a pair, flags the ones that match, and blocks the ones that do not, so a same-name trap never turns into a data loss story. 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 →