• Products
  • Documentation
  • Resources

How the Jira Cloud Migration Assistant links your data

The Jira Cloud Migration Assistant will add data to your cloud site without overwriting existing data. This means you can move to a new or existing cloud site. If the cloud site already has data, the migration assistant might link the data instead of re-migrating it. This page explains how the migration assistant decides what to do with the data.

Records of entities

The Jira Cloud Migration Assistant will save a record of each entity (e.g., workflow or custom field) it migrates for the first time. In subsequent migrations to the same cloud site, the migration assistant checks if it already has a record of that entity and the entities are identical (i.e., they have the same underlying properties).

The migration assistant tracks what has been migrated and what has 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. The migration assistant lets 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 will create a new entity with the original name and a “(migrated)” tag. We will 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 will link your data to the existing entity in the destination site. We will not re-migrate this entity.

Tracking entity changes flowchart

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

  • 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 will create a new entity with the original name and a “(migrated)” tag. We will 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 that exists in the destination site, Priority A will appear as Priority A (migrated) in the destination site after migration.

Preventing unnecessary duplicates flowchart

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

  • 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, make sure you check they are working after migrating.

Multiple duplicates

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 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 cloud site after migration 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.

Last modified on Sep 9, 2021
Cached at 3:39 PM on Oct 18, 2021 |

Additional Help