• 製品
  • 関連ドキュメント
  • リソース
製品
関連ドキュメント
リソース
アトラシアン サポート
/
移行に関するリソース
/
移行前チェックリスト

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

Jira Cloud Migration Assistant 1.7.3 以降にアップグレードして、確実に移行しましょう

Jira Cloud Migration Assistant の以前の全バージョンのサポートを終了します。

次のバージョンは使用できません。

  • Jira Cloud Migration Assistant 1.7.1 以前

アトラシアンは移行ツールを改善し、既存の機能を拡張しています。移行をよりスムーズかつ安定して実施するには、リリースから 6 週間以内に 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 のサイト管理者権限を持っていること

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 のセットアップを確認する (必須)

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

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

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

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 のアプリケーション メモリを増やす方法についてご確認ください

10. Server のタイムゾーンを確認する (Cloud サイトを統合する場合は必須)

Jira Cloud サイトをマージするために移行アシスタントを使用している場合、課題のタイムスタンプのタイムゾーンがわずかに変わることがあります。Jira Cloud は UTC を使用します。Jira Server インスタンスがこれ以外のタイムゾーンを使用している場合、UTC との時差に基づいて時間が変更されます。

回避策として、Jira Server インスタンスの -Duser.timezone=UTC にシステム フラグを追加します。この回避策について詳細をご確認ください

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

サーバーのタイムゾーンを確認するには、次の手順に従います。

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

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

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

  4. jvm.system.timezone を探します。

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

また、次のクエリで Server のタイムゾーンを検証できます。

1 2 3 4 5 grep "<jvm.system.timezone>" <Support Zip Location>/application-properties/application.xml Example Output: <jvm.system.timezone>America/New_York</jvm.system.timezone>

11. 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 のチーム管理ページを使用して個々のチームを見つけ、必要に応じてメンバーシップを調整できます。

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

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

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 Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある場合は、同様に Jira Cloud サイトもバックアップします。

17. テスト移行を実行する (推奨)

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

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

18. 移行プランをサポートに通知する (推奨)

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

Cloud の移行のサポートについて詳細をご確認ください

詳細情報とサポート

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

その他のヘルプ

このページの内容はじめる前に1. ユーザーの移行計画を作成する (必須)外部ディレクトリJira Server ユーザー インターフェイスによって同期するサポート Zip を使用した検証前回の外部ユーザー同期の検証アクティブな外部ディレクトリの検証2. Jira Server のバージョンを確認する (必須)Jira Server ユーザー インターフェイスによって検証するサポート Zip 製品バージョン検証によって検証する3. 無効なメール アドレスや重複したメール アドレスを修正する (必須)4. 適切な権限を持っていることを確認する (必須)5. グループ名の競合を確認する (必須)SQL を使用した検証 (Postgres でテスト済み)6. ファイアウォールの許可ルールを更新する (必須)7. アプリの移行方法を決定する (必須)8. パブリック アクセス設定を確認する (必須)SQL を使用した検証 (Postgres でテスト済み)9. Server のセットアップを確認する (必須)サポート Zip を使用した検証ヒープ サイズを検証する別の方法10. Server のタイムゾーンを確認する (Cloud サイトを統合する場合は必須)Jira Server ユーザー インターフェイスによって検証するサポート Zip を使用した検証11. Advanced Roadmaps の共有チームを確認する (推奨)SQL を使用してメンバーがいないチームを見つける (Postgres でテスト済み)12. 共有されている設定名の重複を修正する (推奨)13. ストレージの上限を超えていないことを確認する (推奨)14. Server インスタンスを準備する (推奨)カスタム フィールドの説明に埋め込まれた HTML または JavaScript コードを修正する 15. Cloud サイトを準備する (推奨)16. データをバックアップする (推奨)17. テスト移行を実行する (推奨)18. 移行プランをサポートに通知する (推奨)詳細情報とサポート
コミュニティ質問、ディスカッション、記事