• Products
  • Documentation
  • Resources

How data is linked between instances

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

You can copy data from one instance of Jira or Confluence, known as the source, to another instance called the destination, without overwriting any existing data. The destination can be a new instance or an instance with existing data. To avoid duplication when you copy data multiple times, we’ll try to link any previously copied data.

However, there is an exception with Epic and Story issue types. In a specific scenario, when you copy 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 when and how data is linked between cloud sites.

Records of entities

When you copy data, we save a record of each entity, such as workflow or custom field, during the initial copy. In the subsequent copies to the same destination, we check the records for existing or identical (meaning they have the same underlying properties)entities.

We track what’s been copied and what’s changed during the copy. This prevents:

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

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

Tracking changes to entities

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

This is why we keep track of entity field content and ensure it stays consistent each time you copy data. You can recopy a shared configuration entity if it has been:

  • deleted from the destination

  • modified in the source or destination

If an entity in your copied product data has the same name as an entity in the destination, we'll create a new entity with the original name and a "(copied)" tag. We’ll then copy your data along with this new entity.

For example, your copy data has an entity named Screen A that has been modified and there is another entity with the same name in the destination site, Screen A will be renamed to Screen A (copied) after you finish copying.

If an entity in your copy data has not been deleted from the destination or the entity has not been modified, we’ll link your data to existing entities at their destinations. We will not recopy 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 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.

When copying product data, if an entity with the same name exists in the destination but has different underlying fields, a new entity will be created with the original name and a "(copied)" tag. We’ll then copy your data along with this new entity. 

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

preventing duplicate

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 copying product data.

Multiple duplicates

Multiple duplicates of an entity may be created for several reasons. These will appear as Custom field A (copied), Custom field A ( copied 2), Custom field A (copied 3), and so on.

Duplicates may be caused by:

  • a default entity existing in both the source and destination instances

  • the source instance or cloud instance being reset during the copy

  • some data is deleted during the copy

We recommend performing your tests on a separate instance from your production environment to avoid duplicates during copying.

 

Additional Help