Jira Cloud Migration Assistant の移行前チェックリスト

Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。次の点が確認されます。

  • すべてのユーザーに有効で一意のメール アドレスが紐付けられているかどうか

  • プロジェクト名またはキーが Cloud にすでに存在するプロジェクト名またはキーと競合していないこと

  • 移行アシスタントが最新かどうか

ただし、すべてが確認されるわけではないため、移行の開始前に、この移行前チェックリストを一通り確認する必要があります。

はじめる前に

移行前のチェックを完了するには、次のようなアクセス権が必要になる場合があります。

1. ユーザーの移行計画を作成する (必須)

外部ディレクトリ

アクティブな外部ユーザー ベースを同期して、ユーザー戦略の一環としてすべてのユーザーやグループが適切に移行されていることを確認します。また、これによって、移行中にデータが適切なユーザーに引き続きリンクされるようにします。ユーザー移行戦略について詳細をご確認ください

外部 ID プロバイダーを使用してユーザーを管理している場合は、移行前にそれらのユーザーがアクティブで Jira と同期されていることをご確認ください。

Jira Server ユーザー インターフェイスによって同期する

  1. 右上隅の歯車アイコンを選択します。

  2. [ユーザー管理] を選択します。

  3. [ユーザー ディレクトリ] を選択します。

  4. [同期] を選択します。

サポート Zip を使用した検証

Epoch タイムスタンプは https://www.epochconverter.com/ などのサイトで照合できます。

必要なディレクトリがアクティブに設定されていることを確認します。

前回の外部ユーザー同期の検証

1 2 3 4 5 6 7 grep "com.atlassian.crowd.directory.sync.laststartsynctime" <Support Zip Location>/auth-cfg/directoryConfigurationSummary.txt Example Output: com.atlassian.crowd.directory.sync.laststartsynctime: 1586922783853 com.atlassian.crowd.directory.sync.laststartsynctime: 1586911983804 com.atlassian.crowd.directory.sync.laststartsynctime: 1579025414214

アクティブな外部ディレクトリの検証

1 2 3 4 5 6 7 8 9 grep "Active:" <Support Zip Location>/auth-cfg/directoryConfigurationSummary.txt Example Output: Active: true Active: true Active: true Active: false Active: true

Jira Cloud Migration Assistant は次を移行します。

  • すべてのユーザーまたはグループ

  • 選択したプロジェクトに関連するユーザーとグループ

2. Jira Server のバージョンを確認する (必須)

Jira がサポート対象バージョンで実行されていることをご確認ください。サポート対象外のバージョンである場合、Migration Assistant は機能しません。サポート対象バージョンの詳細をご確認ください。

Jira Server ユーザー インターフェイスによって検証する

  1. 右上隅の歯車アイコンを選択します。

  2. [システム] を選択します。

  3. 左側ナビゲーション パネルの [システム情報] を選択します。

  4. Jira バージョンを探します。

サポート Zip 製品バージョン検証によって検証する

1 2 3 4 5 grep "<product name" <Support Zip Location>/application-properties/application.xml Example Output: <product name="Jira" version="8.7.1"/>

3. 無効なメール アドレスや重複したメール アドレスを修正する (必須)

無効なメール アドレスや重複したメール アドレスは Jira Cloud でサポートされていないため、Jira Cloud Migration Assistant で移行できません。移行がブロックされないようにするには、アシスタントを使用してそのようなメールアドレスを特定し、手動で修正します。または、重複したメール アドレスのマージや関連ユーザーの無効化といった推奨オプションのいずれかを適用して、移行時に自動的に修正します。

Jira Cloud Migration Assistant を開きます。

  1. [Assess and prepare users (ユーザーの評価と準備)] カードで、[Begin assessing (評価を開始)] を選択します。空の結果のページに移動します。

  2. 評価を開始するには、[Begin assessing (評価を開始)] を選択します。評価が完了すると、要件を満たしていないメール アドレスの数が表示されます。詳細を表示して、これらのメール アドレスの修正方法を選択できます。

ユーザーの評価と準備に関する詳細を確認する

4. 適切な権限を持っていることを確認する (必須)

移行を実行するユーザーが、次の権限を持っていることを確認します。

  • Server インスタンスのシステム管理者グローバル権限を持っていること

  • 宛先のクラウド サイトに存在すること

  • Cloud の組織管理者ロールを持っていること。古い組織では、サイト管理者ロールを使用できる場合もありますが、これは新しい組織では廃止されています。

  • サーバーの <Jira ホーム ディレクトリ /export ディレクトリに対して必要なディスク アクセス権限を持っている。このディレクトリは、移行プロセス中に一時ファイルを作成するために使用されます。

5. グループ名の競合を確認する (必須)

Cloud サイトのグループ名が Server サイトのいずれのグループとも異なることをご確認ください (意図的にマージしようとしている場合を除く)。Migration Assistant がグループ名の競合を管理する方法をご確認ください

一部の移行シナリオでは、Server サイトにアドオン ユーザーが発生する場合があります。Server の世界においてアドオン ユーザーは一般的ではないため、クラウドに戻す移行の際にいくつかの問題が発生する可能性があります。移行前に、これらのアドオン ユーザーを削除または更新します。

SQL を使用した検証 (Postgres でテスト済み)

次のクエリでこれらのユーザーを見つけて削除するか、メール アドレスを @connect.atlassian.com 以外のものに更新します。

1 2 --ADD-ON USERS - TESTED ON POSTGRESQL select * from cwd_user where lower_email_address like '%connect.atlassian.com%';

6. ファイアウォールの許可ルールを更新する (必須)

移行アシスタントは移行を実行するためにアトラシアンのドメインに接続します。ファイアウォールまたはリバース プロキシによってドメインがブロックされると、移行は失敗します。移行の実行前に、Atlassian Cloud 製品の IP アドレスとドメインがセキュリティ ルールによってブロックされていないことを確認します。

Cloud 製品によって使用される IP アドレスとドメインについて詳細をご確認ください

7. アプリの移行方法を決定する (必須)

Jira Cloud Migration Assistant によってアプリ データを移行できます。移行するアプリの Marketplace パートナー (アプリ ベンダー) に連絡して、構築した移行パスが Jira Cloud Migration Assistant をサポートしているかどうかを確認したうえで、データの効率的な移行方法についてアドバイスを求めましょう。 

アプリの評価と移行について詳細をご確認ください

8. パブリック アクセス設定を確認する (必須)

Jira Server または Jira Cloud サイトをインターネットに公開するように構成できます。コンテンツを意図的に公開する場合を除いて、プロジェクト権限を確認する必要があります。Jira Server に公開しているプロジェクトがある場合は、Cloud に移行する前にそれらの匿名アクセスのセットアップを削除します。移行後、これらのプロジェクトはいつでも公開できます。

SQL を使用した検証 (Postgres でテスト済み)

プロジェクト

これによっていずれかの権限が [すべてのユーザー] に設定されているプロジェクトにフラグが付けられます。

1 2 3 4 5 6 7 8 9 10 11 SELECT p.id, p.pname, ps.name, sp.permission_key FROM project p INNER JOIN nodeassociation na ON p.id = na.source_node_id INNER JOIN schemepermissions sp ON na.sink_node_id = sp.scheme INNER JOIN permissionscheme ps ON na.sink_node_id = ps.id WHERE na.source_node_entity = 'Project' AND na.sink_node_entity = 'PermissionScheme' AND sp.perm_type='group' AND sp.perm_parameter is null;

フィルター

"全員で共有" 共有タイプ (グローバル) のフィルターの一覧を取得します。

1 2 3 4 5 // get list of filters which has share type as "share with everyone" (i.e. global) SELECT sr.filtername, sp.sharetype AS current_share_state, sr.username AS owner_name, sr.reqcontent AS JQL FROM searchrequest sr INNER JOIN sharepermissions sp ON sp.entityid = sr.id WHERE sp.sharetype='global' and sp.entitytype ='SearchRequest';

アジャイルボード

"全員で共有" 共有タイプ (グローバルなど) のアジャイル ボードのリストを取得します。

1 2 3 4 5 6 // get list of Agile boards which has share type as "share with everyone" (i.e. global) SELECT DISTINCT "rv"."NAME" as "Board Name", sr.filtername, sp.sharetype AS current_share_state, sr.username AS owner_name FROM "AO_60DB71_RAPIDVIEW" as rv INNER JOIN searchrequest sr ON sr.id = rv."SAVED_FILTER_ID" INNER JOIN sharepermissions sp ON sp.entityid = sr.id WHERE sp.sharetype='global' and sp.entitytype ='SearchRequest'; 

ダッシュボード

"全員で共有" 共有タイプ (グローバル) のダッシュボードの一覧を取得します。

1 2 3 4 5 6 // get list of Dashboard which has share type as "share with everyone" (i.e. global) SELECT DISTINCT pp.id as Dashboard_Id, pp.pagename AS Dashboard_name, sp.sharetype AS current_share_state, pp.username AS owner_name FROM portalpage pp INNER JOIN sharepermissions sp ON sp.entityid = pp.id WHERE sp.sharetype='global' and sp.entitytype ='PortalPage' ORDER BY pp.id;

9. Server のセットアップを確認する (必須)

アプリケーション メモリ (JVM ヒープ サイズ)

移行する課題またはプロジェクトの数によっては、移行全体をクラッシュさせる可能性がある OutOfMemory エラーが Jira Server で発生する場合があります。これを防ぐためには、アプリケーションが 4GB 以上のヒープ割り当てで実行されていることを確認します。Jira のアプリケーション メモリを増やす方法についてご確認ください

一般的なインスタンス データセットのサイズとリソース (CPU コア、RAM、ヒープ) に基づくベンチマーク

次の表は、インスタンスのサイズ プロファイルの定義を示しています。

特大

32 CPU、64 GB RAM、31 GB ヒープ

16 CPU、32 GB RAM、16 GB ヒープ

8 CPU、16 GB RAM、8 GB ヒープ

4 CPU、8 GB RAM、4 GB ヒープ

大と特大は、データセットのサイズとそれに対応するインスタンス プロファイルの最大値/最小値への近さに基づいて選択できます。

AWS でのエンタープライズ Jira インスタンスの推奨インフラストラクチャ」もご覧ください。

開いているファイル数の上限

また、オープンなファイルの制限を確認します。32768 になるべく近い数が理想的です。システムに設定されるオープンなファイルの数は、Linux ディストリビューションに応じて異なる場合があります。これをシステム コマンド経由で確認する方法が不明な場合は、サポート Zip を作成し、application-properties/application.xml ファイルを開いて、<max-file-descriptor> を検索します。必要に応じて値を調整します。これは、Windows を実行している場合には適用されません

「Too many open files」エラーの詳細をご確認ください。

サポート Zip を使用した検証

アプリケーション メモリ (JVM ヒープ サイズ)

Xmx および Xms の値が 4096m または 4g 以上であることを確認します。

1 2 3 4 5 grep -i "xmx"" <Support Zip Location>/application-properties/application.xml Example Output: <JVM-Input-Arguments>-Djava.awt.headless=true -Datlassian.standalone=JIRA -Dorg.apache.jasper.runtime.BodyContentImpl.LIMIT_BUFFER=true -Xms4g -Xmx4g

開いているファイル数の上限

<max-file-descriptor> の値が 32768 に近いことを確認します。

1 2 3 4 5 grep -i "<max-file-descriptor>"" <Support Zip Location>/application-properties/application.xml Example Output: <max-file-descriptor>32,000</max-file-descriptor>

ヒープ サイズを検証する別の方法

Linux

/jira-installation-directory/bin/setenv.sh ファイルに移動し、次の両方のパラメーターが 4096m または 4g (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。

1 2 JVM_MINIMUM_MEMORY="4096m" JVM_MAXIMUM_MEMORY="4096m"

Windows - サービスとして実行していない

/jira-installation-directory/bin/setenv.bat ファイルに移動し、次の両方のパラメーターが 4096m または 4g (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。

1 2 JVM_MINIMUM_MEMORY="4096m" JVM_MAXIMUM_MEMORY="4096m"

Windows - サービスとして実行

Jira のアプリケーション メモリを増やす方法についてご確認ください

データベース接続プール

Jira は Apache Commons DBCP に基づく DBCP (データベース接続プール) によって、基盤となるデータベースへの Jira のアクセスを管理します。Jira がデータベースにアクセスする (読み込みまたは書き込みを行う) 必要がある際は、データベース接続が必要になります。

通常の使用では、Jira のデータベース接続プールは正常に動作する可能性があります。しかし、Jira Cloud Migration Assistant を追加すると、データベース接続プールのサイズが適切でない場合にプールが枯渇する可能性があります。

その場合、Jira のパフォーマンスに大きな影響が及び、移行アシスタントだけでなく、アプリ全体に影響します。通常の回避策は、データベース接続プールのサイズを増やすことです。

修正

既定では、Jira の DB 接続プールの最大サイズは 20 です。一般的な解決策は、その数を 10 ずつ増やして、Jira と Migration Assistant の両方に対応するように接続プールを微調整することです。DB 接続プールの最大サイズを 40 まで増やせば、移行のニーズに十分に対応できるはずです。

DB 接続プールを操作してサイズを大きくするには、以下の参照リンクをご覧ください。

10. Advanced Roadmaps の共有チームを確認する(推奨)

Jira Cloud に移行するカスタマーには、メンバーシップが必要なアトラシアン チームに変換される共有チームがあります。アトラシアン チームの詳細をご確認ください

移行時に、メンバーがいないチームには既定メンバーが割り当てられます。このメンバーは、組織管理者権限とチーム管理アクセス権のいずれか、または両方を持つユーザーです。

チームへの予期しない変更を避けるため、移行前に共有チームを確認することをおすすめします。

SQL を使用してメンバーがいないチームを見つける (Postgres でテスト済み)

こうすることで、メンバーがいない共有チームが見つかります。

1 2 3 4 5 6 7 8 select "TITLE" from "AO_82B313_TEAM" where "ID" not in (select distinct "TEAM_ID" from "AO_82B313_RESOURCE" r inner join "AO_82B313_PERSON" p on r."PERSON_ID" = p."ID" inner join cwd_user cu on p."JIRA_USER_ID" = cu.user_name where active = 1) and "SHAREABLE" = true;

その後、<Jira base url>/secure/TeamManagement.jspa のチーム管理ページを使用して個々のチームを見つけ、必要に応じてメンバーシップを調整できます。

11. 共有されている設定名の重複を修正する(推奨)

移行の競合を防ぐために、Cloud サイトの共有設定と同名の Server インスタンスの共有設定 (ワークフローまたは権限スキーム) の名前を変更します。競合が見つかった場合は、移行中に設定の名前が変更されることがあります。Migration Assistant がデータをリンクする方法をご確認ください

12. Server または DC の空きディスク容量を考慮する [推奨]

移行に十分なディスク容量がサーバーまたは DC にあることを確認してください。必要な容量は、Jira インスタンスのサイズと移行の仕様によって異なります。移行中に作成される一時ファイル用の追加ストレージを考慮に入れてください。

詳細は、以下のドキュメントを参照してください。

13. クラウド上のストレージ上限を超えないことを確認する [推奨]

アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク スペースと Cloud 内のストレージと制限に関する情報を確認してください。Cloud ストレージについて詳細をご確認ください

14. Server インスタンスを準備する (推奨)

Server データが正常に移行されるように、データベース整合性チェッカー (Jira Server のネイティブ機能) と Atlassian Marketplace の Integrity Check for Jira アプリによって、データのステータスを確認します。

他のチェックおよび実行すべきアクションは次のとおりです。

  • すべての必須フィールドに値があって null ではない

  • 移行したいアーカイブ済みのプロジェクトを再有効化していること

  • 移行した非アクティブなユーザー ディレクトリを再有効化していること

サーバー インスタンスのクリーンアップについて詳細をご確認ください

カスタム フィールドの説明に埋め込まれた HTML または JavaScript コードを修正する

Jira Cloud 製品では、HTML や JavaScript コードをカスタム フィールドの説明に埋め込むことは許可されていません。こうしたコードは、Cross-site Scripting (XSS) などのセキュリティ脆弱性の攻撃ベクトルになる可能性があるためです。移行する前に、Jira Server でこうしたフィールドを調整または削除する必要があります。Jira Server の該当するカスタム フィールドは、ドキュメント「説明にカスタム JavaScript が含まれるフィールドを識別する方法」に記載されているクエリを使用して特定できます。

15. Cloud サイトを準備する (推奨)

Cloud サイトのセットアップ時には次の点を考慮します。

  • 各 Jira 製品への製品アクセスを持つグループが存在する場合、該当する製品が Cloud サイトと Server サイトの両方で有効化されている必要があります。たとえば、Server サイトに Jira Core と Jira Software がある場合は、Jira Core プロジェクトを移行しない場合でも、Cloud サイト上で Jira Work Management (旧 Jira Core) と Jira Software の両方が必要になります。これは、すべてのユーザーとグループを正常に移行するためです。 

    注意: Jira Software または Jira Service Management のライセンスがある場合は、Jira Work Management を無料で利用できます。

  • Cloud サイトの言語が、Server サイトの言語と同じであることを確認します。言語が異なる場合は、一部のフィールドが適切に移行されない場合があります。

  • Atlassian Access を使用している場合は、移行前にそれを設定し、ユーザーを最適に移行する方法について詳細を確認する必要があります。ユーザー移行戦略の詳細をご確認ください。

16. 移行に向けて Jira Align を準備する (オプション)

Jira Align を使用する場合は、移行前、移行中、移行後に追加の手順を完了する必要があります。その中には、Jira Align サポート チームとの協力が必要な作業もありますので、移行タイムラインについてお知らせいただく必要もあります。

Jira Align を移行する方法をご確認ください

17. データをバックアップする (推奨)

移行を実行する前に、現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある場合は、同様に Jira Cloud サイトもバックアップします。

18. テスト移行を実行する [推奨]

テスト移行を実行してから本番環境に移行することを強くお勧めします。

移行のテストについて詳細をご確認ください

19. 移行プランをサポートに通知する [推奨]

週末や祝日に移行する、または Cloud 上のユーザーが 1,000 人を超える場合は、1 ~ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を確保したうえで、移行をサポートします。

20. ネットワークの帯域幅を確認してください

詳細情報とサポート

移行をサポートする多数のチャンネルをご用意しています。

その他のヘルプ