A Jira Cloud migration is a transformation, not a move
Ask an IT team to move a long-lived Jira instance and you will hear about risk, because they have earned that wariness. The migrations that go smoothly are the ones where the hard thinking happened first, and that thinking is where the real value is.
When a team decides to move from Data Center to Cloud, the first instinct is usually to make the move as small as possible. Copy everything across exactly as it is, change nothing, get back to work. The people pushing for that are not being lazy. They are protecting against risk, and the surest way to protect against risk, on paper, is to change as little as you can. I understand the logic. I just think it leads somewhere most teams do not want to go, which is the same instance they have now, in a more expensive home, with the move itself bolted on as a cost.
A Jira instance that has been live for years is a record of every decision the organization ever made under pressure. There is a workflow for an exception that came up once. There is a custom field that exists because someone won an argument about it. There is a permission scheme that three admins ago made sense and that nobody now fully understands. None of that arrived by plan. It accreted. A migration is one of the few moments when everyone is willing to look at all of it at the same time, which is exactly the moment most teams decide not to.
What lifting everything unchanged actually costs
Lift-and-shift optimizes for a single thing, which is minimizing change on the day of the move. As a goal for that one day, it works. As a goal for the migration, it is the wrong one, because the schemes nobody uses come along, and so does the 30-status workflow built around a reorg, and so do the four priority fields that mean four different things to four teams. You have spent budget and weekends to arrive at the place you started.
The opposite mistake is just as real, and it is worth naming so nobody hears me arguing for it. You do not stop everything and redesign the whole instance from scratch. That swallows the project and earns the wariness the IT team had in the first place. The work is to carry over only what earns its place, and to decide what earns its place deliberately, before anyone touches production.
The app catalog tells you what you depend on
The clearest place this shows up is your Marketplace apps. Data Center and Cloud do not share an app catalog one to one, so every app has to be inventoried and mapped. Does it have a Cloud equivalent. Is there a native capability now that makes it redundant. Does it simply not exist on Cloud at all. That audit feels like overhead the first time you see the list, and it is closer to a gift, because it is a complete account of everything your instance depends on, assembled for you by the constraint of the move. The honest question is not how to replace each app. It is which of those dependencies you still want to be carrying a year from now.
The same is true of configuration. The workflows and schemes you carry forward should reflect how teams work now, not how they worked three reorgs ago. Simplifying the riskiest configuration before the move, rather than reproducing it faithfully, is what turns the cutover from a leap into a confirmation.
A migration is the rare moment the whole organization is willing to look in the mirror at the same time. You can clean up what you see, or photograph it and hang the same picture somewhere new.
Carry the history, not the mess
There is a distinction that matters here, because “clean up” can sound like “throw things away,” and that is not it. Issues, history, attachments, and permissions should land intact. The board a team opens the first Monday on Cloud should look like the work that is actually in the room, with its past attached, not like an archaeology dig and not like a fresh empty project that erased everyone’s context. Carrying history over with integrity is non-negotiable. Carrying dysfunction over is the part that is optional, and the two get confused far more often than they should.
What a smooth migration is made of
A migration done well is almost boring on cutover day, and the boredom is the tell. It is boring because the work that could have gone wrong already happened, earlier, when it was cheap to change. Scope was agreed so the cleanup had edges and did not expand into the whole instance. Apps were rationalized against that inventory. The risky configuration was simplified rather than reproduced. A dry run was completed, so the cutover was a thing the team had already watched work once. And people were told well in advance what would change and why, because the surest way to recreate old habits is to move a tool out from under people without telling them it moved.
That last point is the one teams skip, and it is the one that determines whether the new instance gets used as intended or worked around. The technical migration can be flawless and still fail if the people on the other side of it were not brought along.
So when an IT team is wary of a migration, my answer is not to talk them out of the caution. The caution is correct. It is to point it at the right moment. Do the hard thinking up front, decide what earns its place, validate it against a dry run, and the move becomes the safe and unremarkable part. That is the whole idea behind how we run these, and it is of a piece with the rest of our Atlassian practice: tools shaped around how your teams actually work, not the other way around.
If you want to see what earns its place before you move, see where delivery is getting stuck.