Plan your Cloud migration
Documents to help you prepare to migrate your Atlassian Server products.
Perform a cloud-to-cloud migration for Jira
Who can do this?
Organization admins
Site administrators
When you add teams or reorganize your existing teams, you may need to move your Jira users and projects from one instance of your Jira to another.
Some project types such as team managed-managed projects and Jira Service Management projects aren't supported yet. Learn more about what we migrate and what we don’t
To assess the impact of your migration and make decisions about your cloud-to-cloud data movement, review the soft limits for cloud-to-cloud migration for Jira.
Before you start a cloud-to-cloud migration, learn about:
Access the cloud-to-cloud migration feature
To start migrating your data, log in to the cloud site you want to migrate your users and projects from. This will be your source from where you’ll move your data.
Select Settings ⚙️ in the top right corner of the screen.
Select System.
Select Migrate cloud site from the left navigation menu.
We’re gradually rolling out this feature, so it may not appear for a few days, or longer if you have Release Tracks enabled.
The Migration overview screen shows you details about your source site, including the number of projects, users, groups, Jira Service Management customer accounts, and apps on your site.
From this screen you can:
select Start reading to read our documentation outlining important things you need to know before migrating.
select Plan your migration from the left navigation menu to access our documentation at any point during your migration.
select Go to dashboard to start the migration or view active and expired migrations.
Create a migration
Once you’re ready to begin migrating, Go to dashboard. This will take you to the Migration dashboard, which you can also access from the left navigation menu.
The dashboard lets you see all your migrations in one place. It will be empty until you create a new migration. To do so, select Create new migration.
Before you proceed, make sure your destination site has the same Jira products as your source site, even if you won’t be migrating data from the other products. Make sure your destination site also has the same user-installed apps as your source site. We don’t migrate app data yet, but this will reduce your chance of encountering any errors. To migrate app data, you’ll need to contact each Marketplace Partner directly.
3. Select your destination site
First, enter a name for your migration. This will help you identify the migration on the dashboard if you need to create more than one migration.
Next, select the cloud site you want to migrate your users and projects to, known as the destination site. To migrate to a site within the same organization, you need to be a site admin for the destination site. To migrate to a site in a different organization, you need to be an organization admin for both the organization that your destination site belongs to and the source site. Learn more about admin permissions
If you want to migrate to a new site, create a new site and add it to your organization.
Once you’ve selected your destination site, select Choose projects to add projects to your migration.
4. Choose projects to migrate
You can choose to migrate all or some of your projects. All issues, attachments, and configurations related to the projects you select will be migrated.
Users and groups are automatically added to your migration. Currently, we migrate users and groups separately, which means users won’t be added to groups and they won’t have product or project access. You’ll need to manually add users to groups after migration.
Once you’ve selected projects, select Check for conflicts to proceed.
5. Select group membership
You can choose to:
Preserve group membership, which means users will be migrated along with their groups. If there’s a group with the same name on the destination, the two groups will be merged, and migrated users will automatically be granted permissions of the destination groups. This means that users may get unwanted permissions. We’ll check if there are groups with the same names in the next step.
Add users to groups separately, which means users won’t be added to groups after they are migrated. You’ll need to manually add users to groups after the migration is complete to grant them product access.
Once you’ve selected the desired option, select Check for conflicts.
6. Check for conflicts
Before you can run your migration, we run checks to confirm that your destination site is correctly set up for your migration and to identify potential conflicts or unwanted settings. When you reach this step, we also save your migration, and it will appear on the dashboard.
At this point, you can proceed to review your migration, but if the checks resulted in any warnings or errors, you’ll need to resolve them before you can run your migration.
What we check for:
Your destination site should have the same Jira products as your source site, even if you won’t be migrating data from the other products. This will reduce the chance of your migration failing. If there’s a product you don’t want to use after migrating, set up a free trial for that product, then deactivate the trial after your migration is complete.
The user limit on your destination site won’t be exceeded after migration. The number of users with product access after migrating should be less than the maximum allowed under the plan on your destination site. There is no limit to the number of customer accounts you can migrate on a Jira Service Management Free plan. If you need to increase the user limit, upgrade your plan.
Projects don’t already exist on your destination site. All projects on your destination site must have unique names and project keys after migration. This includes the history of any changed or old project keys. If duplicate projects are found, you’ll need to change the project name or key on your source site, delete the duplicate projects on your destination site, or remove the affected projects from your migration.
Projects aren’t available to the public, unless you’ve allowed anonymous or public access. We migrate project permissions as they’re configured on your source site. In some cases, your project permissions may allow public access, which means anyone on the internet can access your projects and related data in the destination site after they’ve been migrated. If you don’t want to allow people to access this data in your destination site without logging in, update the permissions on your source site before migrating.
While we run checks for common problems, you might encounter other problems during your migration that we don’t check for. Every cloud site is different so we recommend checking your data before migrating to reduce the chance of your migration failing.
7. Review your migration
On this screen, you’ll see a summary of your migration. This summary will outline how you’ve configured your migration, how many projects you’ve selected, and provide an estimated time required to complete your migration. Below the summary, you’ll see a breakdown of the projects you’ve selected.
Users, groups, Jira Service Management customer accounts, and individual projects are all marked with a pre-migration status, indicating whether that entity is ready for migration. There are three possible pre-migration statuses.
Status | What it means |
|---|---|
Ready | You’re good to go! You have no warnings or errors to resolve, and you can proceed to run your migration. |
Check | We found a problem in our checks with the users, groups, or a specific project in your migration. You can proceed to run your migration, but we recommend you review the warning. |
Fix | We found a problem in our checks with the users, groups, or a specific project in your migration. You’ll need to resolve the error before you can run your migration. |
If you have errors from the previous step that you haven’t resolved, you’ll need to go back to do so by selecting View errors and warnings at the top of the screen or Back at the bottom of the screen. Check and Fix statuses are all related to warnings and errors from the previous step.
If your source site is in use, we recommend you always check for conflicts before you run your migration, even if there were no warnings or errors to resolve the last time a check was run. This is to make sure the latest changes to your source site are checked. Select Rerun checks from the Review migration screen, or Check for conflicts from the More actions (•••) menu on the dashboard.
Once you've resolved all warnings and errors and reviewed your migration, you can proceed to run your migration.
8. Run your migration
Once you run your migration, you’ll be redirected to the dashboard. Use the dashboard to view the progress and status of all your migrations.
Select the More actions (•••) menu to access quick actions for any migration, including to:
run the migration
edit the migration (add or remove projects from saved migrations)
check for conflicts
go to the destination site
To see the detailed progress of any migration, select View details for that migration. On the View details screen, you’ll see the progress of users, groups, and individual projects.
While a migration is running, the migration status of users, groups, Jira Service Management customer accounts, and projects will keep changing. There are five possible migration statuses.
Status | What it means |
|---|---|
Queued | This entity is next in queue to be migrated. |
Running | This entity is currently being migrated. |
Complete | This entity was successfully migrated. |
Incomplete | This entity was partially migrated. For example, this could mean 10 out of 15 users were migrated. |
Failed | This entity could not be migrated. |
If your migration has not finished, making changes to or deleting entities on your source site or destination site will cause your migration to fail. To prevent this from happening, make sure all migrations from the same source site to the same destination site are finished, before cleaning up or making changes on either site.
After your migration
Onboard your users
All users and groups, and customer accounts are migrated during a cloud-to-cloud migration. All active and inactive users are migrated, and content associated with deleted users is also migrated.
Users won’t get an email notification when they’re migrated to another site. When you’re ready, you can invite your users by going to Administration > Users > Resend invite from your destination site. Alternatively, you can also give users a link to the destination site and they will be able to log in directly. Learn more about inviting users
Decide to keep or cancel your source site
Once you’ve completed your migration, we recommend keeping the source site for a few months before cancelling your site subscription.
If you’re concerned about additional billing, you can cancel your site subscription by going to Administration > Billing > Manage subscriptions and selecting Cancel subscription for the site you want to cancel.
Was this helpful?