What Does JCMA Actually Migrate? A Field-by-Field Breakdown

Ask ten admins what gets migrated with the Jira Cloud Migration Assistant and you will get ten different answers, because the real list is long, specific, and split across several Atlassian pages.

Here is that list, field by field, followed by what stays behind on Data Center, so you can plan the gap instead of discovering it in week one.

What Gets Migrated with the Jira Cloud Migration Assistant: Configuration

JCMA moves the structural bones of a Jira instance. Projects carry their name, key, type, category, description, lead, default assignee and project roles. Issue type schemes, screens and screen schemes, workflows and workflow schemes, field configuration schemes, permission schemes, issue security schemes, priorities and priority schemes all come across with the projects that reference them.

Notification schemes migrate with a caveat worth knowing: only system events with their default notifications are carried over. User defined custom notifications and custom events are not, so any project that relied on a custom notification rule needs a review afterwards.

Workflow functions migrate as a full list, but workflow triggers and workflow properties do not. If a workflow depends on a property for its behavior, expect that behavior to change in Cloud.

Custom fields migrate, with type limits

JCMA migrates the common custom field types with their values: text, multi line text, read only text, date, number, labels, environment, URL, radio button, checkbox, select list single choice, multiple choice and cascading select, user pickers single and multiple, project picker, and story points. Select lists keep their options, cascading selects keep both levels, and field configurations and contexts move with them.

Field types with no Cloud equivalent are the exception. JCMA logs an "unsupported custom field" message for those and skips the value, and anything referencing the field, a filter, a workflow scheme, a screen, can stop working. The fix is the documented one: recreate the field in Cloud, then fill the values with a CSV export and import that includes issue key and summary.

One more quirk of the additive design: a Data Center field whose name already matches a field in Cloud arrives as a new field tagged "(migrated)". The values land in the new field, not the one your Cloud users already point their JQL at.

What Does JCMA Actually Migrate for Issue Data

This is the part users check first, and it is the strongest part of the tool.

Issue fields, content and collaboration

• Core fields: summary, description, issue type, issue number, status, resolution, labels, due date, creator, reporter, assignee, subtasks, priority, issue rank and original and remaining estimates.
• Content: comments including comments restricted by issue security, attachments, work logs and time spent, issue history, issue key history and issue links with their link types.
• Collaboration: watchers, votes and @mentions.
• Agile data: sprints with their status and dates, epic link, epic name, epic color and epic status, flagged, steps and environment.
• Versions: affects versions and fix versions, including the version data that dashboard gadgets reference.
• Archived issues: supported on JCMA 1.10.16 and later, which increases total issue count and therefore run time.

History and links across batches

Issue history has one edge case: a history entry that points at a missing link or attachment is not migrated, and it updates later if you migrate the referenced project in a later batch. The same logic applies to issue links across batches, links to projects you have not migrated yet are simply absent until those projects land.

Boards, Dashboards and Filters

JCMA migrates project boards with their name, administrators, filter and permissions, location, column names and status mapping, quick filters, swimlanes, sprint permissions, card colors and time statistic settings. Cross project boards and filters that share permissions with migrated projects come along too, and you can include boards that belong to inactive users.

Sprints migrate as part of boards and dashboards, so plan which of those you include if sprint history matters to you.

Dashboards are optional, choose dashboards connected to the selected projects, a specified list, all of them, or none. System dashboards are not migrated, and third party gadgets are dropped from the dashboards that do come over.

Filters attached to a migrated board migrate. Filters with no migrated board behind them do not, by default. Export your filter inventory from Data Center before you run so the favorites your team actually opens can be recreated.

Users, Groups and Permissions

You can migrate users ahead of the data migration or as part of a plan, either all of them or only those referenced in the projects in scope. Groups migrate too, and they are linked to existing Cloud groups by name, which is where permission escalation hides, a Cloud group that already exists keeps its members and gains the migrating ones.

What to expect on the user side

• Deleted Data Center users arrive as Former user, only when they are connected to migrated projects.
• Disabled users arrive active but with no product access, so they do not add to your bill.
• Avatars, per user timezones, user properties and activity stream do not migrate, people re upload avatars and reset passwords unless you run SSO.
• Global site permissions and general configuration are not migrated, rebuild them yourself.
• Jira Core product access permissions for groups do not carry over, re assign app access in Cloud.

What JCMA Does Not Migrate

Keep this list next to your plan, everything here is manual work:

• Global permissions, general configuration, customized filter columns and comment reactions.
• Mail handlers, issue collectors and links to entities that were not included in the plan.
• System dashboards, project shortcuts and standard issue type icons.
• Workflow triggers and workflow properties.
• Custom field language translations and asset related field variants.
• Filters with no migrated board, unless you export and recreate them.
• Marketplace app data, unless the vendor published a migration path.
• Automation audit logs, flow actors and global automation settings, plus automation steps such as outgoing webhooks and web requests.
• Services from Server or Data Center, and Advanced Roadmaps classic plans, scenarios and saved views.

How to Verify What Actually Landed

Three checks close the loop. Download the migration error logs and search for "unsupported custom field", that is your CSV top up list. Run a JQL search in Cloud for the phrase "(migrated)", every hit is a duplicate field your filters and dashboards should be repointed at. Then spot check one project field by field against the source, comments, attachments, work log and links are the usual suspects.

Resources worth keeping open: our guide to JCMA duplicate fields, the merge walkthrough for duplicate custom fields, and the post migration checklist. Atlassian maintains the canonical reference at What gets migrated with the Jira Cloud Migration Assistant.

If the JQL check does turn up duplicates, that is the cleanup with the most leverage. Migration Field Cleanup for Jira scans for "(migrated)" and "(migrated 2)" fields, matches them to the originals, compares schemas, shows how many issues each pair holds, and merges in one click, copying a value only when the original field is empty, so nothing Cloud native is overwritten. It is Forge only, nothing leaves your Jira instance, and teams of 50 or fewer users can scan and merge for free. See it on the Atlassian Marketplace.