Merging two Jira Data Center instances: what actually collides

The trigger is almost always the same: a merger, an acquisition, or a reorganisation. Two companies, two Jira Data Center instances, and a mandate to become one. Someone asks whether you can just merge them, and the honest first answer is that there is no merge button — and the reason there isn't is the whole story.

Why there is no button

A Jira instance is not a database you can UNION with another. Every project sits on top of a web of instance-global configuration: workflow, permission, notification, issue-type and field-configuration schemes, screens, custom fields, statuses, resolutions, priorities, and the users and groups behind all of it. Two instances built those webs independently, so the same name means different things on each side and the same thing has different names. Merging is not moving issues. It is reconciling two configuration models and then moving the data through the reconciliation.

That is why "just merge them" is a project, and why the work is mostly decisions, not clicks.

What collides

This is the table to read before promising anyone a date.

None of that is exotic. All of it is invisible until you try the move and something is quietly wrong.

The two real approaches

There is no third. You either use what Jira ships, or you buy a tool that does the reconciliation for you.

Native project import restores a single project's data — issues, comments, attachments, worklogs — from a full XML backup of the other instance. The part people get wrong is that it does not carry the configuration with it. The target must already hold the matching configuration the project needs — workflows, statuses, issue types, custom fields, schemes — and the importer validates against that and stops on anything that does not line up, rather than inventing it for you. (It can create some missing custom fields; it will not rebuild your schemes.) The standard practice is to pre-create the project on the target with the correct configuration, then import the data into it. It is free, built in, and for a small merge into a well-prepared target it is enough. On two mature, divergent instances, that pre-reconciliation of configuration is most of the work — which is exactly the point.

A configuration-management app such as Configuration Manager for Jira exists to do the part the native path leaves to you: it moves configuration and data together, previews what will collide, and lets you choose how each conflict resolves. It costs a licence and a learning curve, and on a genuine two-instance merge it usually pays for itself in the reconciliation it automates.

The decision is mostly size and mess. A handful of clean projects: pre-build the config and use native import. Two mature instances with years of divergent configuration: a proper migration tool, or you will spend longer preparing the target by hand than the merge ever saved.

Users are where it bites

The configuration is finite; the identity problem is the one that surprises people. When you build the identity map, key on email rather than username — usernames collide across instances and emails usually do not — but know that the native importer itself matches on username and needs each user to already exist on the target or be creatable, so the mapping is work you do up front. The person who changed companies and appears under two emails, and the shared or service accounts that are not people at all, are yours to resolve by hand. If either side authenticated against an external directory — LDAP, Crowd, an SSO provider — the merged instance needs one reconciled source of truth before anyone logs in, not after.

Deactivated users still own issues, filters and dashboards, and those references have to land somewhere. Get this wrong and assignees, reporters and @mentions remap to the wrong people, which is both a data-integrity problem and, depending on what those issues contain, a confidentiality one.

The silent gap: app data and automation

Two things are routinely missing in production. First, Marketplace-app data: a project import moves core Jira records — issues, comments, worklogs, and test cases that are themselves issues — but not the data apps keep in their own storage. Structure hierarchies, Tempo's worklog attributes, Xray or Zephyr test steps and executions, Assets/Insight objects: each needs its own app's supported export and import, and some cannot be moved cleanly. Second, automation and ScriptRunner: a project import does not carry them at all — they are inventoried and recreated separately — and any rule or script that hard-codes a source-instance project, field or scheme ID has to be re-pointed once those IDs change on the target. Inventory both before the merge, not after the first missing worklog.

Rehearse it, then do it

Nobody should learn what collides by importing into production. Clone the target instance to staging, run the merge there, and diff the result against both originals: issue counts per project, custom field values on a sample, workflow states, user mappings, a full open-and-check of one representative project. Only when the staging run is boring do you schedule the real cutover — with a change freeze on both instances during the move, because issues created mid-import are issues lost.

If "move to Cloud" is also on the table

Sometimes the merge mandate arrives bundled with a move to Atlassian Cloud. Do not attempt both in one step. The Jira Cloud Migration Assistant can pull several Data Center instances into a single Cloud site in sequence, linking incoming objects to existing ones by its own rules — and, on some managed issue types, overwriting when names collide — which is powerful but rule-based, not a generic "merge everything" button. Consolidating on Data Center first and then migrating the single clean instance is the other order. Deciding which before you start is the difference between one hard project and two tangled ones.

What we actually do

We are not an Atlassian Solution Partner, which means we have no licences to upsell and no reason to recommend a bigger migration than the merge needs. What we do is the reconciliation engineering: inventory both instances, map the conflicts, choose the approach that fits the mess, rehearse it on staging, and run the cutover — the same estates whose configuration drift shows up in the SLAs we audit. The button does not exist because the decisions cannot be automated, and the decisions are the job.