Documents to help you prepare to migrate your Atlassian Server products.
A collection of topics that help prepare you to migrate your apps to the Cloud.
Ensure you’re ready to migrate with these pre-migration checklists for Jira, Confluence, and Bitbucket Server or Data Center.
Documents that walk you through using the Confluence Cloud Migration Assistant to migrate to Cloud.
Documents that walk you through using the Bitbucket Cloud Migration Assistant to migrate to Cloud.
Documents to help you use Jira Site Import to migrate to Cloud.
Resources to help get started and testing after you migrate.
Everything you need to know about moving your data from one cloud site to another.
Cloud-to-cloud migration is currently in beta
This feature may not function as a generally available feature and may contain stability issues and inaccuracies. There are a few issue fields, configurations, and other project types that aren't supported.
If you have done server-to-cloud migrations before, then using this feature may cause data loss. Depending on your needs, you may need to consider other ways to move data between Jira Cloud sites. Learn about other methods and their limitations. To assess how these methods impact your requirements, contact support.
Cloud-to-cloud migration helps you move users and Jira Software and Jira Work Management projects from one cloud site to another. In a cloud-to-cloud migration, data is copied from one cloud site to another. You can perform a cloud-to-cloud migration when you want to:
combine data across two or more cloud sites
split a cloud site into multiple cloud sites
duplicate a cloud site
copy specific projects from one cloud site to another
You need to be an organization admin or a site admin to access the feature and perform a cloud-to-cloud migration for Jira.
Before you start a cloud-to-cloud migration
Prepare your sites for a cloud-to-cloud migration to reduce your chance of encountering any errors and understand how migration may affect your billing.
1. Access the cloud-to-cloud migration feature
To begin a cloud-to-cloud migration, you need to log in to the cloud site you want to migrate your users and projects from, known as the source site.
Select Settings ⚙️ in the top right corner of the screen.
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, 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. You can also select Plan your migration from the left navigation menu to access our documentation at any point during your migration.
2. Create a migration
Once you’re ready to begin migrating, select Go to dashboard. This will take you to the Migration dashboard, which can also be accessed 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.
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.
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.
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. 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 has 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. 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.
6. 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, 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.
What it means
You’re good to go! You have no warnings or errors to resolve, and you can proceed to run your migration.
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.
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.
7. 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, and projects will keep changing. There are five possible migration statuses.
What it means
This entity is next in queue to be migrated.
This entity is currently being migrated.
This entity was successfully migrated.
This entity was partially migrated. For example, this could mean 10 out of 15 users were migrated.
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
We migrate users and groups separately, which means you’ll need to add users to their relevant groups after migration to give them product access. Learn more about giving users product access
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. Learn more about cancelling subscriptions
Continue with public access doesn’t resolve errors (MIG-648)
This bug occurs when proceeding to Continue with public access for a project from the Check for conflicts screen. After confirming, unresolved errors and warnings remain on the Review migration screen. Clicking View errors and warnings will return the user to the public access warning. On the migration dashboard, the progress of this migration will show Some checks failed.
Incorrect number of issues is shown during project selection (MIG-650)
This bug occurs when an issue is added to a project after a migration has been saved. The number of issues in that project doesn't update correctly in the table on the Choose projects screen.
Was this helpful?