Jira Cloud Migration Assistant がデータをリンクする仕組み
ほとんどの場合、Jira Cloud Migration Assistant は、既存のデータを上書きすることなく、クラウド・サイトにデータを追加します。ただし、管理対象の課題タイプのエピックとストーリーに関しては例外があり、移行時に移行先サイトにある同じ元の名前の既存の課題タイプを上書きすることができます。つまり、新規や既存のクラウド・サイトにデータを移行できますが、このような課題タイプを使用している場合は、この特定のシナリオを想定して計画を立てることが重要です。クラウド・サイトにすでにデータがある場合、Migration Assistant はデータを再移行するのではなく、データへリンク付けすることがあります。このページでは、Migration Assistant がデータの処理方法を決定する仕組みについて説明します。
エンティティのレコード
Jira Cloud Migration Assistant は、初回に移行する各エンティティの記録 (ワークフローやカスタム フィールドなど) を保存します。同じクラウド サイトへの移行が再度行われた場合、Migration Assistant はそのエンティティの記録がすでにあるかどうか、エンティティが同一であるかどうか (つまり同じ基礎となるプロパティを持つかどうか) を確認します。
Migration Assistant は、移行された内容と移行間で何が変更されたかを追跡します。これによって次を防止できます。
元のサイトと移行先のサイト間で一致しないプロジェクトの構成の共有 (ワークフロー、カスタム フィールド、スキームなど)
不要な重複 (同じエンティティの複数のコピーなど)
エンティティの変更を追跡する
エンティティは移行後に、削除または変更される可能性があります。たとえば、移行先サイトでカスタム フィールドが削除されたり、元のサイトで新しいカスタム フィールド オプションが追加されたりする場合があります。
そのため、エンティティ フィールドの内容を追跡して、異なる移行の間で確実な一貫性を維持するようにしています。Migration Assistant では、エンティティが次の状態の場合に、共有構成エンティティを再移行できるようになりました。
移行先サイトから削除された場合
元のサイトまたは移行先サイトで変更された場合
移行に含まれるエンティティが移行先サイトのエンティティと同じ名前である場合は、元の名前と「(移行済み)」タグが付いた新しいエンティティが作成されます。その後、この新しいエンティティと併せてデータが移行されます。
たとえば、「画面 A」という名前のエンティティが移行に含まれており、移行先サイトにあるエンティティも同名であることからエンティティが変更された場合、「画面 A」は移行後に「画面 A (移行済み)」として移行サイトに表示されます。
移行に含まれるエンティティが移行先サイトから削除されていない、またはエンティティが変更されていない場合は、移行先サイトの既存のエンティティにデータをリンクします。このエンティティは再移行されません。
このロジックをすべてのエンティティに展開します。現在、このロジックは次のエンティティにのみ適用されます。
カスタム フィールド
カスタム フィールド スキーム
フィールド設定
フィールド設定スキーム
画面
画面スキーム
課題タイプ画面スキーム
権限スキーム
課題セキュリティ レベル
課題セキュリティスキーム
フィルター
ワークフロー
ワークフロースキーム
不要な重複を防止する
現在、基になるフィールドが同一の場合にのみ 2 つのエンティティをマージする変更を展開しています。たとえば、優先エンティティは名前フィールドと色フィールドが同じ場合にのみマージされます。
移行に含まれるエンティティが移行先サイトのエンティティと同名であり、基になるフィールドが一致しない場合は、元の名前と「(移行済み)」タグが付いた新しいエンティティが作成されます。 その後、この新しいエンティティと併せてデータが移行されます。
たとえば、「優先度 A」というエンティティが移行中であり、移行先サイトに存在するエンティティと同一でない場合、「優先度 A」は移行後に「優先度 A (移行済み)」として移行先サイトに表示されます。
サーバーからクラウドへの移行の課題タイプが、移行先のクラウド サイトの管理対象課題タイプと同じ名前の場合、新しい課題タイプは作成されません。サーバーは信頼できる情報源と見なされるため、移行先サイトの課題タイプの名前はサーバーの名前と一致するように更新されます。
この問題を回避するには、Server/Data Center インスタンスで管理対象外の課題タイプを新規作成し、対象の課題をすべて一括編集して新しい課題タイプにしてから移行します。こうすることで、クラウド内の既存の管理対象課題タイプは変更されず、新しい管理対象外タイプの課題も表示されます。
このロジックをすべてのエンティティに展開します。現在、このロジックは次のエンティティにのみ適用されます。
課題のステータス
優先度
ソリューション
課題タイプ リンク
Project Category
プロジェクトロール
課題タイプ
課題タイプ スキーム
カスタム フィールドのオプション
これらのエンティティに依存している JQL フィルターまたはクイック フィルターがある場合、移行後にそれらが機能していることを確認してください。
移行時に名前が変更されたエピックまたはストーリーの課題タイプを処理する
Jira Cloud Migration Assistant は通常、既存のデータを上書きせずにクラウド サイトにデータを追加しますが、上書きが発生する可能性がある特定のシナリオがあります。それは、エピックやストーリーなど、名前が変更された管理対象の課題タイプを移行する場合です。
たとえば、インスタンス A (移行元) とインスタンス B (移行先) の 2 つのインスタンスがあるとします。インスタンス A では、課題タイプの名前を「ストーリー」から「ユーザー ストーリー」に変更しました。このとき、すでに「ストーリー」課題タイプがあるインスタンス B に移行すると、この課題タイプは「ユーザー ストーリー」で上書きされます。複製は作成されず、元の課題タイプが置き換えられます。
移行時に課題タイプが上書きされないようにするには：
オプション 1 - 移行前：
ソース・インスタンスで、「設定」>「課題」に移動します。
「課題タイプ」を選択します。
「課題タイプを追加」を選択し、希望の名前で標準の課題タイプを作成します。
一括編集機能を使用して、関連するすべての課題をこの新しい課題タイプに変更します。
オプション 2 - 移行後：
移行先のクラウド・サイトで、「設定」>「課題」に移動します。
「課題タイプ」を選択します。
上書きされた課題タイプを探し、「編集」を選択します。
課題タイプの名前を元の名前に戻します。
複数の重複
さまざまな理由によって、1 つのエンティティに対して複数の重複が作成される場合があります。これらは、カスタム フィールド A (migrated)、カスタム フィールド A (migrated 2)、カスタム フィールド A (migrated 3) のように表示されます。
重複は、以下の理由により発生する可能性があります。
元のサイトと移行先サイトの両方に存在するデフォルト エンティティ
移行の合間にリセットされるサーバー インスタンスまたはクラウド サイト
移行間で削除された一部のデータ
重複を避けるために、本番環境の移行とは別のサイトでテストを実行することをお勧めします。ただし、移行後のクラウド サイトへの必要な変更は、サイト管理者のみが実行できます。
ユーザーとグループ
ユーザー移行でも同じロジックが使用されます。ユーザーのメール アドレスが移行先サイトにすでに存在する場合、再移行されません。ユーザー移行の詳細について、確認してください。
移行先サイトにすでに存在するサーバー グループはマージされます。そのため、一部のユーザーの権限は移行を通してエスカレートされる可能性があります。グループと権限の移行方法をご確認ください。
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
移行の詳細な計画情報や FAQ については、Atlassian Cloud 移行センターを参照してください。
技術的な問題が発生していたり、戦略やベスト プラクティスで支援が必要な場合、お問い合わせください
また、アトラシアン コミュニティもご利用ください。
エキスパートによる支援が必要な場合、アトラシアン パートナーにご相談ください。
この内容はお役に立ちましたか?