How we link your data during migration

A cloud-to-cloud migration will migrate data from one cloud site to another without overwriting any existing data. This means you can migrate data to a new site or a site with existing data. To avoid duplication when you migrate multiple times, we’ll try to link any data that’s already been migrated. This page explains when and how data is linked between cloud sites.

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.

Expand to see a diagram of this process

Open

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.

Expand to see a diagram of this process

Open

 

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

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 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. Any changes that need to be made to the destination cloud site after migration can only be performed by site admins.