Is a Jira Cloud migration just copying your data over?
Mostly no, and the copying is the generic part you can plan the least for. Atlassian’s free migration assistant moves your projects, users and their work to Cloud on its own. The culprits are your site’s own customizations. critical apps without a migration path, boards that stay behind, misaligned email addresses, domains that need verifying and sheer volumes that strain cloud limits. Every site has its own challenges that you need to plan and prepare for.
We cover below the most common and biggest pitfalls and also discuss when you can safely run the migration yourself.
Key takeaways
- Atlassian’s free migration assistant moves your data for you, but it’s rarely enough.
- Confer with stakeholders to decide what should migrate. Later, base your tests on those decisions.
- Apps can migrate only if the vendor set a migration path for them. Viter.io can support when that’s not the case.
- Map your scripts and custom code, check how each translates to Cloud, and consider Forge apps where needed.
- Clean your user base before migration. Handle everything around domains and login with extra care.
- If you graze the Cloud configuration limits, it’s more of a business issue than a technical one.
- Use a sandbox for testing. Orient your team around the new UI.
- If your migration is simple enough, you can skip most of these steps and go directly to a test migration.
What can you cross off the migration plan on day one?
The data copy, and the early detective work. Atlassian’s own survey of migrated customers found 40 percent calling the move easier than expected and a third calling it faster (Atlassian on its migration tooling). The assistant tool moves your data (projects, users and their work) at no cost, and runs checks on your apps, users’ email addresses and domains. Every flag from the pre-flight checks points to a decision you need to make.
Jira only ships with it from 8.14, older versions install it from the Marketplace. If you don’t see it on your DC site, follow the install instructions to install it. You can choose to run a full migration, or just copy parts of the data, for a step-by-step approach.
What stays behind even when the copy succeeds?
Though the migration assistant does a lot of the heavy lifting, it also leaves plenty behind. The first step is to decide what is worth the effort to migrate: often, past configurations and requirements are no longer needed and can be left out. Atlassian publishes the full list of what its assistant will not carry (what isn’t migrated); read it before you start setting up your migration! For some items on it, a manual fix post-migration is enough. A board can be rebuilt in the new site in minutes, and a filter can be recreated by the person who uses it. Atlassian also keeps closing the gap, shipping cloud capabilities that used to be DC-only. Still, complex areas like security settings, scripts and apps require more delicate attention when the migration path goes through them.
Which apps can you migrate, and what happens when it’s not possible?
Only the ones whose vendors built a migration path. The assistant assesses every installed app and reports one of three verdicts: yes, no, or not sure (assessing your apps). A "no" does not stop the migration, but it does start a project: the data in that app has to be rebuilt in its cloud version, exported in some way, or left behind. Run the assessment early to understand your operational risk. And before treating any "no" as a problem, check whether the app still earns its place. Most instances carry more apps than anyone remembers installing, and every app you drop cuts both the migration work and the future subscription bill.
Where do your custom scripts go?
They don’t go — they get rebuilt. Scripts as you knew them on DC don’t exist in Cloud (unless you are moving scripts in ScriptRunner, and even then they need to be rebuilt). Start by analyzing the need behind the script. With all the advancement that has gone into Cloud, your functionality may already exist out of the box. Automations, workflow validators and permissions may already account for what you need. Logic that finds no home anywhere in Cloud can become a Forge app (it’s custom code serving your cloud site, running on Atlassian’s infrastructure, and we will happily discuss it with you).
What happens to your users, their emails and sign-in?
They all pass through one gate: the email address. In Cloud every person is an Atlassian account keyed on a unique address, and the assistant assesses each one before anything moves. Invalid and duplicated addresses cannot migrate at all; the assessment has you edit them, merge the duplicates, or deactivate those users for the run. An address that already has an Atlassian account isn’t copied — the assistant links all of that user’s data to the existing account. Then verify your domains (a DNS record proves they’re yours), which turns those accounts into managed accounts you can actually administer.
The assistant does not invite any user to the newly migrated site, so when and how people learn about the new site is another decision on your migration path.
Sign-in comes last: SSO runs through Atlassian Guard, a separate subscription, and it only applies to accounts on domains you’ve verified. And if your setup spans multiple domains, or several sites merging into one, the identity work compounds — that’s where running it alone carries real risk, and where our service and support earn their keep.
Will your data volume block the move?
Almost certainly not. Nothing in Cloud refuses a site for being big: the 18-million-work-item and 8,400-project figures Atlassian publishes are recommendations. What actually needs checking sits elsewhere. Storage is a plan feature — 250 GB on Standard, unlimited above it (cloud plans). The hard limits are about configuration density, not data: fields per project, statuses per workflow, permission grants and the like (Atlassian’s cloud limits). Migrated sites get six months of grace on those, which makes the migration itself the natural deadline for the config cleanup DC never forced on you. To note, if you are hitting the caps on Cloud, it’s a business-value signal and a discussion waiting in the fold.
How do you test the migration?
Even if the migration process completed successfully, it still does not guarantee that things went according to plan. So, what is the plan? In the design and decision process of the migration, stakeholders should have pitched in on what’s critical for them (or at least on whether some configurations and entities should be migrated).
The business flows that must work on day one post-migration are your test plan. Together with your team, allocate the time slot to test.
A crucial point here — the UI in the cloud is very different from what your team was used to on your DC site. It’s definitely worth taking the time to orient them on how to navigate around Jira before they go into the tests. Otherwise, the team will probably come back with "X is gone" and "I don’t see Y anymore" — when it just might be that they don’t know how to access it.
Your tests should run in a sandbox environment. You get one free with Premium or Enterprise, or you can set up a dummy site for this.
A word of caution — Guard, user claiming and domain verification operate at the organization level, not the site level. Done incorrectly in a test, they can have serious implications for your production environment. Pay close attention here.
Should you move everything, or decide first what moves?
Both are legitimate migrations; they just distribute the work differently — one pushes it after the cutover, the other before.
| Carry everything that can travel | Decide first what moves | |
|---|---|---|
| What travels | Every project, board and app with a path | The projects, configuration and apps still in use |
| Work before the date | Point the assistant at the site | An audit of projects, apps and users |
| What you inherit | Whatever was broken is now broken in Cloud | Fewer moving parts, each one checked |
| The month after | Cleanup under pressure, in a live site | Cleanup already done, in the old site |
The choice is per project, not all or nothing — the assistant moves whichever slice you give it.
Can you run the migration yourself?
Though there are multiple risks to address in a migration, they may not apply to you. If your site configuration is simple enough to pass with green flags on the pre-flight check, go right ahead and move into the test stage.
Most DC sites, though, are layered with customizations and require specific attention to detail, awareness to dependencies, and solutions that don’t come out of any box.
If you are unsure, the test results will definitively tell you where your migration stands.
Your mission, as is ours, is to make sure all is running smoothly on your first day post-migration!
Frequently asked questions
How long does a Jira Cloud migration take?
What happens to our old site during the move?
What does the migration actually cost?
Can two Jira Cloud sites be merged into one?
What can’t we undo once we’ve migrated?
Do deactivated users stay deactivated in Cloud?
Can permissions change during the migration?
Should we fix our messy automation rules before or after the move?
That smooth first day post-migration starts with one conversation. Tell us where your site stands — apps, users, deadline, or just a hunch that it’s time — and we’ll tell you honestly how much of the road you can walk alone. hello@viter.io.