Documents to help prepare you to migrate your Atlassian server products.
Articles to help assess your migration costs license status.
Learn about migration timelines, roadmaps, app and Atlassian Access with these resources.
Look up resources on Jira and Confluence cloud, data hosting regions, LDAP, and ADFS.
Pre-migration checklists for Jira, Confluence, and Bitbucket.
A collection of topics that help prepare you to migrate your apps to the cloud.
Native tools and resources that will help with your migration.
Documents to help you use Jira Site Import to migrate to cloud.
Documents that walk you through using the Confluence Cloud Migration Assistant to migrate to cloud.
Resources to help get started and testing after you migrate.
If the cloud site already has data, the Jira Cloud Migration Assistant might link the data instead of re-migrating it. This page explains how the migration tool decides what to do with the data.
Records of entities
The Jira Cloud Migration Assistant will save a record of each entity (i.e., workflow or custom field) it migrates for the first time. In subsequent migrations to the same cloud site, the migration assistant will check to see if it already has a record of that entity.
Handling duplicate entities
If an entity in your migration has the same name as an entity in the cloud site, and we have a record of migrating it, we will link your data to the existing entity in the destination site. We will not re-migrate this entity. If you don’t want this to happen you’ll need to contact our support team and request that the records of past migrations be deleted.
If an entity in your migration has the same name as an entity in the cloud site, and we don't have a record of migrating it, we will modify the name by adding (migrated) to avoid duplicates. We will then migrate your data along with this modified entity. For example, an entity called Custom field A will be renamed to Custom field A (migrated) after migration. This rule is true for all entities except Resolution, which we will not migrate at all. Instead, we will link your data from the server site to the existing entity in the cloud site. This is because Resolution is a default entity in cloud.
If you have JQL filters or quick filters that rely on these entities, make sure you check they are working after migrating.
Multiple duplicates may be created for an entity for a number of reasons. These will appear as Custom field A (migrated), Custom field A (migrated 2), Custom field A (migrated 3), and so on.
Duplicates may be caused by:
A default entity existing in both your source and destination sites
The migration table resetting between migrations
Some data being deleted between migrations
We recommend performing your tests in a separate site to your production migration to avoid duplicates. If you are still seeing multiple duplicates in your cloud site after migration, contact our support team who can help you identify why this is happening. However, any changes that need to be made to the cloud site can only be performed by site admins.
Users and groups
User migration uses the same logic. If a user's email address already exists in the destination site, it will not be re-migrated. Learn more about user migration
Server groups that already exist in the destination site will be merged. This means that some users may receive escalated permissions through the migration. Learn more about how groups and permissions are migrated
More information and support
We have a number of channels available to help you with your migration.
Was this helpful?