How to Migrate Jira Data Center to Cloud With Your Existing Data

The question people actually ask before an Atlassian Cloud migration is rarely whether it can be done. It is what happens to everything they already have. Years of issues. Attachments nobody has opened since the people who uploaded them left. Permission schemes that grew one exception at a time. Apps that half the organisation depends on and nobody owns.

The honest answer is that your data is not one thing, and it does not move as one thing. It is at least six different problems wearing the same word, and migrations go wrong in the categories people assume are automatic.

What Actually Moves, And What Only Looks Like It Does

Migrating a Jira Data Center instance to Cloud means doing three different things at once, and the plan should say which is happening to each part of your estate. Some data is transferred — it arrives in Cloud recognisably the same. Some is rebuilt — the concept exists on both sides but the implementation does not carry across, so someone recreates it. Some is left behind — kept in a read-only archive because moving it costs more than it is worth. Treating all three as a single transfer step is the most common reason a migration that was supposedly finished still has people doing manual work weeks later.

Issues And History: The Part That Behaves

Issues, their comments, their status transitions and their change history are the part of the migration that generally works as advertised. If your concern is that a decade of ticket history will be lost, it is the wrong thing to worry about.

The caveat is that history is only as portable as the things it references. A change history entry that says a custom field moved from one value to another is meaningless if that custom field was retired during the migration. This is the argument for deciding what to retire before you move rather than during — a field removed beforehand is a clean decision, and a field removed midway is a gap in the record.

Attachments Move On Their Own Schedule

Attachments are usually the largest thing you own by volume and they do not travel inside the issues that reference them. They are copied as their own body of work, which means they can be incomplete while everything else looks finished.

Two things are worth doing before the first real attempt. Find out how much attachment data you actually hold, because most organisations guess low by a wide margin. Then find the files that no longer belong to a live issue — attachments on projects that were archived, or on issues deleted after the file was uploaded. Those are pure transfer cost with no destination.

The failure mode to plan for is the quiet one: a transfer that completes, reports no errors, and is missing a subset of files. Attachment counts should be compared before and after as a deliberate step, not assumed.

Users Are Where Migrations Actually Break

Identity is the category that causes the most rework, because a Data Center instance and a Cloud site do not think about users the same way. Data Center users may come from a directory you control. Cloud users belong to an Atlassian account tied to an email address, and that address is the join key.

Three situations cause most of the damage:

• The same person, two identities. Someone whose email changed after a name change or a corporate rebrand can arrive as two users, with their history split between them.
• Deactivated users who still own things. People who left the organisation are frequently still the owner of filters, dashboards, automation rules and scheme entries. Deactivating a user does not reassign what they owned.
• Group names that mean nothing in Cloud. Groups inherited from an external directory often lose their meaning when identity moves, and permissions built on them stop describing anyone.

Resolve identity before anything else moves. It is the one category where fixing it afterwards means touching every other category again.

Permissions Are Rebuilt, And That Is Correct

There is a strong instinct to reproduce the existing permission model exactly, on the reasoning that it is what people are used to and reproducing it avoids an argument. Resist it.

Cloud's permission and project model is not the Data Center model with different buttons, and an accumulated set of schemes with one-off exceptions is usually documenting decisions nobody would make again. A migration is one of the few moments an organisation will tolerate revisiting access, because everyone already expects something to change. Rebuilding on intent — who should see what, and why — takes less time than reverse-engineering a scheme that grew by accident.

The exception is any access rule that exists to satisfy a regulator or an audit obligation. Those are requirements, not accumulated habit, and they get carried across deliberately and evidenced.

App Data Is The Risk That Changes The Plan

Everything above is about effort. Marketplace apps are different, because they can change what is possible rather than how long it takes.

For each app carrying data of its own, there are only a few outcomes. The vendor offers a Cloud version and a supported path for the data. The vendor offers a Cloud version but the data does not come with it. There is no Cloud version and a different product has to take over the job. Or the app turns out to be unused, and the answer is to switch it off.

Establish which of those applies to every data-bearing app before the migration approach is settled, not after. An app with no Cloud path and live data is not a task to schedule — it is a decision about whether that capability continues to exist, and it belongs to whoever owns the process, not to the migration team.

Decide Move, Rebuild Or Archive — Per Category

The single most useful artefact going into a migration is a list of everything you hold with one of three words next to it.

• Move — it transfers, and you will verify it arrived.
• Rebuild — the concept survives, the implementation does not, and someone is named to recreate it.
• Archive — it stays behind in a read-only form, reachable if anyone asks, and it stops being your problem on cutover day.

Archive is the option teams forget they have. Projects closed years ago, instances kept alive purely so a finance team can answer an occasional question, whole product areas that were discontinued — none of that needs to be live in Cloud. It needs to be retrievable. Those are different requirements with very different costs, and conflating them is how migrations end up carrying their entire history forward for the sake of a handful of lookups a year.

How To Tell The Data Actually Arrived

A migration is not finished when the transfer reports success. It is finished when someone has checked, against numbers recorded beforehand, that what was supposed to arrive did.

• Issue counts per project, captured before and compared after — not a total, which hides one project gaining what another lost.
• Attachment counts and total size, for the same reason.
• A named person opening a sample of old issues and confirming the history reads correctly, including comments and transitions.
• Every automation rule accounted for as migrated, rebuilt or deliberately dropped — an automation that silently stops running produces no error, just work that quietly stops happening.
• Integrations exercised rather than inspected. A webhook that points at the old instance looks configured and does nothing.

Record those counts before cutover. After cutover, the old instance is often already gone, and there is nothing left to compare against.

How do you migrate Jira Data Center to Cloud with existing data?

Sort what you hold into three groups rather than treating it as one transfer. Issues, comments and change history move across largely intact. Attachments move too, but separately and more slowly, so their counts have to be verified rather than assumed. Users, permissions, automation and app data are rebuilt rather than copied, because Cloud does not model them the same way — and identity should be resolved first, since every other category depends on it. Anything that only needs to be retrievable rather than live belongs in a read-only archive instead of the migration. The categories that break are the ones people assume are automatic.

Where To Start

Before scoping anything, get an inventory: projects with their issue and attachment counts, every data-bearing app with its vendor's Cloud position, and a list of things owned by people who no longer work there. That inventory decides the shape of the migration. Without it, any plan is a guess with a schedule attached.

We have run this for organisations carrying long instance histories, including a public sector organisation moving off a legacy Atlassian Server instance. If you want a view of which parts of your estate are going to be awkward, that is what our Atlassian Cloud migration work starts with.