この記事は セゾン情報システムズ Advent Calendar 2021 2日目の記事です。
2021/11/30に開催された#49 Tokyo Atlassian Community Online MeetUpに登壇してきました。
その資料から抜粋してJira移行時のハマりポイントを紹介します。
前提
移行方式はJira Cloud Migration Assistantを採用しました。
Jira Cloud Migration Assistantは移行先のデータを上書きしないので段階的な実現できます。
その反面、一部対応していないデータも存在しますので事前に確認が必要です。
移行されないデータは以下で確認ができます。
特に、フィルターやダッシュボード、複数のプロジェクトを横断しているボード、通知スキームなどは注意が必要です。
ハマりポイント①
移行先環境でアカウントにJira権限が付与されない
Jira Cloud Migration Assistantでは移行するプロジェクトを選択し、ユーザーとグループの移行オプションを指定します。
画像のように選択すると、そのプロジェクトに関連するユーザーおよびグループのみを移行する設定になります。
本来Jiraにアクセス権のあるユーザーは「jira-software-users」グループに所属していますが、「jira-software-users」そのものは対象のプロジェクトロールに含まれていないため、ユーザーは「jira-software-users」に参加していない状態で移行されます。
ゆえに移行先環境では「jira-software-users」に所属しておらず、Jiraにアクセスできません。
解決方法
移行前にプロジェクトのロールに「jira-software-users」を含める必要があります。
もしくはすべてのユーザー、グループを移行する「All users and groups from the jira dorectory」を選択しましょう。
ハマりポイント②
一部課題タイプが移行先でマッピングされず、新規で作成されてしまう
移行元Serverの規定言語が日本語だったため、Epicが「エピック」で作成されており、マッピングができなかった（Epicの場合はエピックリンクなども外れてしまう）
Softwareタイプのストーリーやバグでも発生するので注意してください。
解決方法
Server側の課題タイプ名を英語表記に変更
JQL等に影響があったのでユーザーへの周知
ハマりポイント③
移行先環境で特定のリソースに(migrated)が付与されて重複してしまう
Migration Assistantは移行済みのエンティティ情報を保持しています
そのため以下のようなデータは重複する可能性があります
- 元のサイトと移行先サイトの両方に存在するデフォルト エンティティ
- 移行間でリセットされた移行テーブル
- 移行間で削除された一部のデータ
解決策
検証環境と本番移行先は分けてテストするか、検証終了後にCloudのリセットを実施する
重複してしまったリソースは移行完了後に手動でマージする
ハマりポイント④
段階的移行の場合、ServerとCloudの並行期間が発生するため、移行済みのプロジェクトは更新を止めたい
移行元でプロジェクトへの参照権限のみに絞った権限スキームを作成し、移行済みのプロジェクトに適用する
おわりに
これから移行を実施する方、移行を検討している方の参考になれば幸いです。