nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How do we handle ID conflicts in custom fields and workflows during multi-instance consolidation int

Utkarsh Agarwal

We are consolidating multiple Jira Server/DC instances into a single Jira Cloud site. Each instance contains overlapping configurations:

Custom fields with identical display names but different internal IDs and context scopes.
Workflows that have the same name but different statuses, transitions, or conditions.
Screen schemes, field configurations, and permission schemes with similar names but different setups.
Project roles named the same but with different group/user assignments.
Global objects like priorities or resolutions defined differently per instance.

We’re encountering issues where:

JCMA assigns new IDs, causing duplication or unintended overrides
Same-named fields/workflows are misleadingly merged or duplicated
Automation rules, filters, and dashboards break due to mapping mismatches
Significant admin overhead is needed to manually clean or refactor configurations after migration

Questions:

Is there a recommended strategy for identifying and resolving config/ID conflicts before running JCMA?
Are there any tools or scripts to compare field/workflow definitions across instances?

Comments

David Cowley

We moved a large server instance (10,000+ users, 100+ projects, 300+ spaces) in October of last year. We engaged with a vendor partner (Praecipio) and during the assessment phase they were able to identify the areas of conflict for us with their own migration scripts. We then needed to make decisions on how to resolve the conflicts, which they then mostly actioned (we did some of it).

This all went into Confluence to identify the problems and the chosen action. Anything that could be done prior to migration was done prior to migration, anything that couldn't ended up as part of the runbook for the migration weekend or as a post-migration activity for resolution.

We had a positive experience.

I am not aware of any Atlassian built tools or publicly accessible scripts that could speed up the process for you. If you're able to, I'd recommend reaching out to an Atlassian partner and see what they can offer you. Even if all you engage them to do is the assessment phase to help you identify all the conflicts you need to resolve before using JCMA for migration yourself, you'll likely save substation time and internal resources which should result in an overall return on investment.

Having multiple instances (which wasn't in scope of our migration) I would think would just make that assessment even more valuable.

Kirana AB

Hi Team,

During a Jira Data Center to Cloud migration, it’s a known issue that duplicate entities can be created if the same names exist in both environments. However, we can avoid some of these duplicates by aligning configurations as part of pre-migration cleanup. Below are key recommendations:

Statuses: Ensure the same name and category (e.g., To Do, In Progress, Done) exist in both instances.

Issue Types: Names and hierarchy (e.g., standard vs. sub-task) should match between source and target.

Priorities: Align name, icon, and description to avoid duplication.

Project Roles: Make sure roles have the same name and description in both environments.

For custom fields, Jira Cloud treats them as separate entities. There’s currently no native way to merge matching fields automatically. This cleanup is recommended as a post-migration task using the bulk update functionality in Jira Cloud.

Gaurav Chavda

I believe different JCMA instances in Jira DC will store their internal data separately and operate independently. This will surely creates a confusion in consolidation use cases. In such situation JCMA may not entertain all the use cases. You may need to setup cloud identical to source before performing the migration. Although JCMA will probably avoid creating duplicate setup (as per the documentation).

There are 3rd party integration/migration platforms which can help you to visualize fields and help with consolidation but migrating configurations comes on you, they just move the data, not the configuration or metadata.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-cloud

cloud-migration

cloud-migration-assistant