How to Merge Jira Instances After a Merger or Reorganization

[#1]

If your organization just went through a merger, acquisition, or internal reorganization, there's a good chance you're now staring at two, three, or even five separate Jira instances — each with its own projects, workflows, custom fields, and years of history. Someone in leadership has said the words ‘let's consolidate,’ and now it's your job to figure out how.

I wanted to share a practical rundown of what it actually takes to merge Jira instances cleanly, along with the traps that tend to blow up timelines.

Why teams end up needing to consolidate multiple Jira instances

A few common triggers:

• Mergers and Acquisitions activity — two companies, two Atlassian tenants, one combined org chart
• Divisional sprawl — different business units set up their own instances over the years with no central IT oversight
• Cloud migration cleanup — someone finally wants to get off three legacy Server/Data Center instances and standardize on one Cloud site
• License and cost consolidation — paying for multiple site subscriptions instead of one tiered plan starts to look wasteful

Whatever the trigger, the underlying problem is the same: you need one source of truth for issue tracking, and right now you have several.

Step 1: Audit before you touch anything

Before any migration tooling gets involved, inventory each instance:

• Number of projects, and which are actually active vs. inactive
• Custom fields — you will have duplicates with different names doing the same job, and that needs to be resolved before migration, not after
• Workflows and their statuses/transitions
• Permission schemes and groups
• Installed apps/marketplace add-ons and whether equivalents exist on the target instance
• Automation rules
• Issue volume and attachment size (this affects migration time and cost)

This step feels slow, but it's the difference between a controlled consolidation and a multi-month fire drill.

Step 2: Decide on your target instance and structure

You generally have two paths when you consolidate multiple Jira instances:

1. Pick a ‘surviving’ instance and migrate everything else into it
2. Stand up a brand-new instance and migrate all instances into it in parallel

Path 1 is faster and cheaper if one instance is clearly the better-configured, higher-volume one. Path 2 is cleaner if all your existing instances have accumulated years of configuration debt and you want a fresh, standardized setup — but it's more work upfront.

Either way, decide early:

• Will projects be merged into shared schemes, or keep separate schemes per legacy org?
• How will you handle overlapping project keys?
• What's your naming convention going forward?

Step 3: Map and reconcile configuration

This is where most of the real effort goes:

• Custom fields: merge duplicates, retire the losers, document field mappings
• Workflows: you don't need to force every team onto one workflow, but you do want to reduce the total count. Fewer, well-designed shared workflows beat 40 near-identical ones.
• Schemes: permission, notification, and screen schemes should be rationalized, not just imported wholesale
• Users and groups: reconcile identities, especially if the merging companies used different identity providers

Step 4: Choose your migration method

Depending on scale and complexity:

• Atlassian's built-in Cloud migration tooling (site-to-site migration, or the Jira Cloud Migration Assistant) works well for Server/Data Center → Cloud or Cloud → Cloud moves with manageable data volumes
• CSV import is good for smaller projects but painful at scale and error-prone with attachments, comments, and history
• Third-party migration app from the Marketplace: a specialized tool built for organization mergers, making them better equipped to handle bulk project migrations, preserve historical data, and map fields accurately.

Always run a test migration with a representative subset of data first. Don't find out your automation rules broke after you've already migrated 50,000 issues.

Step 5: Plan the cutover and communication

Technical merge aside, the human side matters just as much:

• Give each affected team a clear cutover date and a ‘what changes for you’ summary
• Preserve issue history and comments — nothing kills trust in a migration faster than losing context on old tickets
• Keep the legacy instance in read-only mode for a defined window post-migration rather than deleting it immediately, in case something was missed
• Train users on any workflow or field changes before go-live, not after

Possible Customizations for Jira Service Management Merges

For JSM consolidation projects, with the Atlassian Migration Tool, you can request customizations tailored to complex migration requirements, including:

• Multi-project and issue type routing — Map different ticket types to the right Jira Service Management projects and issue types.
• CC to Request Participants mapping — Preserve collaborators and CC relationships.
• Issue link preservation — Retain Jira issue relationships or migrate them as clickable links.
• Confluence KB alignment — Consolidate knowledge base content into the right Spaces while preserving structure and organization.

Custom migration configurations help ensure your Jira or JSM merge retains the data relationships and structure your teams rely on.

Final thought

Consolidating Jira instances after a merger or reorganization is rarely just a technical migration — it's an opportunity to clean up years of configuration sprawl and standardize how your combined organization actually works. Take the time to audit and reconcile the configuration properly, and the migration itself becomes a lot less scary.

Has anyone here gone through a large-scale Jira consolidation recently? Curious what migration tool worked well for you, and what you'd do differently next time.