• Products
  • Documentation
  • Resources

How cloud-to-cloud migration links data between sites

Starting January, 2024, we’re renaming the Jira cloud-to-cloud migration feature to Copy product data. We’re moving this feature to Atlassian Administration at admin.atlassian.com in a unified experience along with Confluence cloud-to-cloud data copy.

We’re rolling out the change slowly, so if you aren’t able to access this feature by logging into your Jira Cloud and selecting System > Settings > Migrate cloud site, we recommend you go to admin.atlassian.com, and select:

Settings > Data management Copy product data

You’ll need to have organization administrator permissions to access and use the Copy product data feature.

Learn more about this change

 

In most cases, a cloud-to-cloud migration moves data from one instance of your cloud product to another without overwriting any existing data. However, there is an exception with Epic and Story issue types. In a specific scenario, when you migrate data, we overwrite these issue types. Read more about this exception with Epic and Story issue types and how to manage them

This page explains how we manage entities when you migrate more than once to an instance of your cloud.

Records of entities

In cloud-to-cloud migrations, we save a record of each entity (e.g., workflow or custom field) that is being migrated for the first time. In subsequent migrations to the same destination site, we check if a record of that entity already exists and if the entities are identical (meaning they have the same underlying properties).

We track what’s been migrated and what’s changed between migrations. This prevents:

  • shared configuration (workflows, custom fields, schemes, etc.) of a project not matching between source and destination sites

  • unnecessary duplicates (i.e., multiple copies of the same entity)

Tracking changes to entities

An entity can be deleted or modified after we’ve migrated that entity. For example, a custom field may be deleted in the destination site, or a new custom field option may be added in the source site.

This is why we keep track of entity field content and ensure it stays consistent over different migrations. We’ll let you re-migrate a shared configuration entity if the entity has been:

  • deleted from the destination site

  • modified in the source or destination site

If an entity in your migration has the same name as an entity in the destination site, we'll create a new entity with the original name and a “(migrated)” tag. We’ll then migrate your data along with this new entity.

For example, if an entity called Screen A in your migration has the same name as an entity in the destination site, and the entity has been modified, Screen A will appear as Screen A (migrated) in the destination site after migration.

If an entity in your migration has not been deleted from the destination site or the entity has not been modified, we’ll link your data to the existing entity in the destination site. We won’t re-migrate this entity.

Tracking changes to entities flowchart

We’ll roll out this logic for all entities. Currently, this logic only applies to these entities:

Jira

  • Issue type

  • Issue type scheme

  • Custom field

  • Custom field scheme

  • Field configuration

  • Field configuration scheme

  • Screen

  • Screen scheme

  • Issue type screen scheme

  • Permission scheme

  • Issue security level

  • Issue security scheme

  • Filter

  • Workflow

  • Workflow scheme

Preventing unnecessary duplicates

We’re currently rolling out changes that will merge two entities only if their underlying fields are identical. For example, the Priority entity will only be merged if the name and color fields are identical.

If an entity in your migration has the same name as an entity in the destination site, and the underlying fields are not identical, we’ll create a new entity with the original name and a “(migrated)” tag. We’ll then migrate your data along with this new entity. 

For example, if an entity called Priority A is being migrated and it’s not identical to the entity also called Priority A that exists in the destination site, Priority A from the source site will appear as Priority A (migrated) in the destination site after migration.

Preventing unnecessary duplicates flowchart

We’ll roll out this logic for all entities. Currently, this logic only applies to these entities:

Jira

  • Issue status

  • Priority

  • Resolution

  • Issue type link

  • Project category

  • Project role

  • Issue type

  • Issue type scheme

If you have JQL filters or quick filters that rely on these entities, check that they’re still working after migrating.

Multiple duplicates

Multiple duplicates of an entity may be created 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 the source and destination sites

  • the source site or cloud site being reset between migrations

  • some data being deleted between migrations

We recommend performing your tests in a separate site to your production migration to avoid duplicates.

Additional Help