インスタンス間でのデータのリンク方法

You can transfer 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 transfer data multiple times, we’ll try to link any previously transferred data.

However, there is an exception with Epic and Story work types. In a specific scenario, when you transfer data, we overwrite these work types. Read more about this exception with Epic and Story work types and how to manage them

このページでは、クラウド サイト間でデータがいつどのようにリンクされるかを説明します。

エンティティのレコード

When you transfer 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 data transfer. This prevents:

  • ソースと宛先の間で一致しないプロジェクトの共有設定 (ワークフロー、カスタム フィールド、スキームなど)

  • 不要な重複 (同じエンティティの複数のコピーなど)

エンティティの変更を追跡する

エンティティはコピー後に、削除または変更される可能性があります。たとえば、宛先でカスタム フィールドが削除される、ソースで新しいカスタム フィールド オプションが追加されるなどです。

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

  • 宛先から削除された場合

  • ソースまたは宛先で変更された場合

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

For example, your transferred 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 (migrated) after you finish the data transfer.

If an entity in your transferred 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.

エンティティの変更を追跡するフローチャート

このロジックをすべてのエンティティに展開します。現在、このロジックは次のエンティティにのみ適用されます。

Jira

  • 作業タイプ

  • Work type scheme

  • カスタム フィールド

  • カスタム フィールド スキーム

  • フィールド設定

  • フィールド設定スキーム

  • 画面

  • 画面スキーム

  • Work type screen scheme

  • 権限スキーム

  • 作業項目セキュリティ レベル

  • Work item security scheme

  • フィルター

  • ワークフロー

  • ワークフロースキーム

不要な重複を防止する

基になるフィールドが同一の場合にのみ 2 つのエンティティをマージする変更を展開しています。たとえば、[優先度] エンティティは名前フィールドと色フィールドが同じ場合にのみマージされます。

When transferring app 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 "(migrated)" tag. We’ll then transfer your data along with this new entity. 

For example, if an entity called Priority A is being transferred 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 (migrated) in the destination after transferring app data.

重複を防止する

このロジックをすべてのエンティティに展開します。現在、このロジックは次のエンティティにのみ適用されます。

Jira

  • 作業項目ステータス

  • 優先度

  • ソリューション

  • Work type link

  • Project Category

  • プロジェクトロール

  • 作業タイプ

  • Work type scheme

  • カスタム フィールドのオプション

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

複数の重複

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

重複は、以下の理由により発生する可能性があります。

  • 既定のエンティティがソース インスタンスと宛先インスタンスの両方に存在する

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

  • some data is deleted during the transfer

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

 

さらにヘルプが必要ですか?

アトラシアン コミュニティをご利用ください。