9 JCMA Limitations to Know Before You Migrate (and Workarounds)

Key Takeaways

JCMA only adds data to Cloud, it never overwrites what is already there, so a name collision becomes a duplicate instead of a merge.
Global permissions, general configuration, avatars and mail handlers are not migrated at all and need manual setup.
Every limitation below has a pre-migration workaround, doing them in order keeps cleanup out of your cutover weekend.

Nine separate Jira Cloud Migration Assistant limitations change what your migration plan actually delivers, and most of them only surface after the cutover weekend.

This list covers the limitations teams hit most often moving from Data Center to Cloud, with the workaround for each one.

How JCMA Treats an Existing Cloud Site

Understanding one behavior explains most of this list. JCMA is additive: it copies entities from Data Center into Cloud without deleting, merging or overwriting anything it finds there. When an entity with the same name already exists in Cloud, JCMA creates a second one and tags it "(migrated)" instead of updating the original.

The same rule applies to projects: a plan for a project that already exists in Cloud will not run again until you remove that copy. There is no inline transformation step either, you cannot rename a workflow, filter or project key inside the plan.

9 Jira Cloud Migration Assistant Limitations and Workarounds

Each item says what JCMA does, then what to do about it before you migrate.

1. Same-name fields become (migrated) duplicates

JCMA copies a Data Center custom field even when a field with the same name already exists in Cloud. It does not merge them, it creates a second field tagged "(migrated)". Run the plan a few times and you get "(migrated 2)", two fields splitting your data while JQL targeting one field ID misses the other.

Workaround: export custom fields from both sites, diff them by name, rename or map the collisions on the source before you run. Anything that still duplicates afterwards needs a merge pass that only fills the original when it is empty. Background in why JCMA creates duplicate fields and how to remove the (migrated) suffix.

2. Project name and key conflicts block the run

The preflight check compares source and destination. If a project with the same name or key already exists in Cloud, that project does not migrate, and the tool will not delete the destination copy to make room.

Workaround: rename on the source first, prefer changing the name over the key, a key change triggers a reindex and breaks board filters, entity links and stored issue links. Update board filters, saved filters and links that reference the old key, then run the plan again.

3. Global settings and global permissions stay behind

Global permissions, general configuration such as timezone and language, customized filter columns and comment reactions are not part of the migration. Your project level permission schemes do move, the site wide ones do not.

Workaround: export the Data Center global permission matrix and general configuration notes, then rebuild them in Cloud right after projects land. Match the site language on both sides too, a language mismatch is a documented cause of fields that arrive misconfigured.

4. Filters with no migrated board stay behind

JCMA migrates filters attached to boards in the plan plus cross project filters that share permissions with selected projects. A favorite filter that belongs to a person, or sits on a board you did not migrate, does not come across by default.

Workaround: export the filter list from Data Center with name, owner and JQL, then recreate the ones people actually use. Check board filters after the run, any JQL that references a project or field you have not migrated yet returns the wrong set until you edit it.

5. System dashboards and unsupported gadgets do not migrate

You choose whether to migrate dashboards connected to the selected projects, a specified list, all dashboards, or none. System dashboards are never migrated, and third party gadgets plus a few Cloud incompatible ones are dropped from the dashboards that do arrive. Re-running a dashboard migration overwrites the Cloud copy of those dashboards and the sprint data their gadgets point at.

Workaround: decide the dashboard option deliberately, inventory gadgets against Atlassian's supported gadget list, and rebuild anything unsupported with a native Cloud gadget.

6. Marketplace app data moves only if the vendor built a path

JCMA assesses your apps and hands off to the app migration flow, but data transfers only for apps that published a migration path. Everything else keeps its data on Data Center while the app itself may install fine in Cloud.

Workaround: run the app assessment early, install the Cloud version of each app on the destination before the data run, then migrate apps one at a time so two apps do not modify the same Cloud objects at once.

7. Automation rules arrive disabled and partially supported

Automation for Jira rules, project and global, migrate when the automation app is enabled on the source, but they land switched off in Cloud. Audit logs, flow actors and global automation settings are not migrated, and several steps have no Cloud equivalent, outgoing webhooks, web requests, publish event and archive actions. Rules that reference several projects only work once every one of those projects has migrated.

Workaround: export an inventory of rules with trigger and action types, plan replacements for the unsupported steps, and enable rules in Cloud only after verifying them one by one.

8. User profiles reset in Cloud

Avatars, per user timezones, user properties and the activity stream do not migrate. Passwords do not migrate either unless you run SSO, so everyone resets on first login. Users deleted on Data Center arrive as Former user, and users in inactive directories are skipped. Groups link by name, which can quietly widen permissions when a Cloud group with the same name already exists.

Workaround: diff group memberships before the run, tell people to expect avatar and password resets, and search for Former user entries after migration to see which attribution failed.

9. Unsupported custom fields and workflow properties are skipped

Some Data Center field types have no Cloud equivalent. JCMA logs an "unsupported custom field" entry and continues, so the field exists but its values do not, and filters or workflow schemes that referenced it can break. Workflow triggers and properties, mail handlers and issue collectors are left out as well.

Workaround: grep atlassian-jira.log for that string before you migrate so you know the full list, recreate the fields in Cloud, then top the values up with a CSV export and import keyed on issue key.

A Pre-Migration Order That Avoids the Surprises

Diff custom fields on both sites by name, rename collisions at the source.
Export filter and dashboard inventories, mark which belong to a board in scope.
Run preflight and clear every project name and key conflict.
Export the automation inventory, flag each unsupported trigger or action.
Export group memberships and the global permission matrix.
Run a test plan on one small project, download the error logs, fix, repeat.
Reserve a post migration block for CSV top ups, filter rebuilds and enabling automation.

Run them in order and these limitations become a checklist, skip them and you hear about it from a stakeholder whose filter stopped returning rows.

Resources

If a test run already produced duplicate fields, that is the one limitation that gets more expensive the longer it waits. Migration Field Cleanup for Jira scans for "(migrated)" and "(migrated 2)" fields, matches them to their originals, shows the affected issue count per pair, and merges in one click, only filling an original that is empty, so Cloud native data is never overwritten. It runs entirely on Forge, and teams of 50 or fewer users can scan and merge free. Install Migration Field Cleanup for Jira from the Atlassian Marketplace.

Ready to clean up duplicate fields?

Install Free →