Jira Cloud Migration Assistant の移行前チェックリスト
Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。ただし、すべてが確認されるわけではないため、移行の開始前に、この移行前チェックリストを一通り確認する必要があります。
はじめる前に
You may need:
access to the Jira Data Center or Cloud user interface
解凍された Jira サポート ZIP にアクセスする。サポート ZIP ファイルの作成方法をご確認ください
解凍された Jira XML バックアップにアクセスする。XML バックアップの作成方法をご確認ください
SQL クエリをソース インスタンスで実行する方法
特定のタイプのスケジュールされたバックグラウンド プロセスの実行が原因で、移行中または移行前のチェック中にパフォーマンスが長時間低下することがあります。移行を開始する際には、Jira Data Center でスケジュールされたジョブのうち、不要なものや重要でないものをすべて停止することをお勧めします。こうした影響は、必ずしも特定のジョブによるものではなく、多くの場合、移行期間中に実行される複数のジョブが累積的に影響します。ジョブを特定して無効にする方法をご確認ください。
Use the table below to run through all the items in the pre-migration checklist.
タイプ | 操作 |
---|---|
(必須) | |
(必須) | |
(必須) | |
(必須) | |
(必須) | |
(必須) | |
(必須) | |
(必須) | |
(必須) | |
(必須) | |
推奨 | |
推奨 | 12. Identify all the projects linked to Advanced Roadmaps plans |
推奨 | |
推奨 | |
推奨 | |
推奨 | |
推奨 | |
推奨 | |
任意 | |
推奨 | |
推奨 | |
推奨 | |
推奨 |
1. ユーザーの移行計画を作成する (必須)
外部ディレクトリ
アクティブな外部ユーザー ベースを同期して、ユーザー戦略の一環としてすべてのユーザーやグループが適切に移行されていることを確認します。また、これによって、移行中にデータが適切なユーザーに引き続きリンクされるようにします。ユーザー移行戦略について詳細をご確認ください
外部 ID プロバイダーを使用してユーザーを管理している場合は、移行前にそれらのユーザーがアクティブで Jira と同期されていることをご確認ください。
Sync using the Jira Data Center user interface
右上隅の歯車アイコンを選択します。
[ユーザー管理] を選択します。
[ユーザー ディレクトリ] を選択します。
[同期] を選択します。
サポート Zip を使用した検証
Epoch タイムスタンプは https://www.epochconverter.com/ などのサイトで照合できます。
必要なディレクトリがアクティブに設定されていることを確認します。
前回の外部ユーザー同期の検証
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
アクティブな外部ディレクトリの検証
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. Check your Jira Data Center version [mandatory]
Jira がサポート対象バージョンで実行されていることをご確認ください。サポート対象外のバージョンである場合、Migration Assistant は機能しません。サポート対象バージョンの詳細をご確認ください。
Jira Server ユーザー インターフェイスによって検証する
右上隅の歯車アイコンを選択します。
[システム] を選択します。
左側ナビゲーション パネルの [システム情報] を選択します。
Jira バージョンを探します。
サポート Zip 製品バージョン検証によって検証する
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 を開きます。
[Assess and prepare users (ユーザーの評価と準備)] カードで、[Begin assessing (評価を開始)] を選択します。これにより、空の結果のページが開きます。
評価を開始するには、[ Begin assessing (評価を開始)] を選択します。 評価が完了すると、要件を満たしていないメール アドレスの数が表示されます。詳細を表示して、これらのメール アドレスの修正方法を選択できます。
4. 適切な権限を持っていることを確認する (必須)
移行を実行するユーザーが、次の権限を持っていることを確認します。
has the System admin permission on the Data Center instance
宛先のクラウド サイトに存在すること
Jira Cloud の組織の管理者ロールを持っている
サーバーの <Jira ホーム ディレクトリ /export ディレクトリに対して必要なディスク アクセス権限を持っている。このディレクトリは、移行プロセス中に一時ファイルを作成するために使用されます。
すべてのボードとフィルターを移行する前に、次のことを確認してください。移行を実行する管理者ユーザーは、移行対象として選択されたすべてのプロジェクトに対するプロジェクトの参照権限を持っている必要があります。
5. グループ名の競合を確認する (必須)
Make sure the groups in your Cloud site don't have the same name as any groups in your Data Center, unless you're intentionally trying to merge them. Learn how the Migration Assistant manages group name conflicts
Additionally, there might be some migration scenarios that result in your Data Center instance ending up with Marketplace app users. Marketplace app users are not common in the Data Center world and they might cause a few issues during the migration to Cloud. Before migrating, delete or update any of these users.
SQL を使用した検証 (Postgres でテスト済み)
次のクエリでこれらのユーザーを見つけて削除するか、メール アドレスを @connect.atlassian.com 以外のものに更新します。
--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. アプリの移行方法を決定する (必須)
You can migrate app data using the Jira Cloud Migration Assistant. Contact the Marketplace Partner (app vendor) for the Marketplace apps you want to migrate to check if the migration path they have built supports the Jira Cloud Migration Assistant, and for advice on how to migrate their data efficiently.
8. パブリック アクセス設定を確認する (必須)
You can configure your Jira Data Center or Jira Cloud instance to be publicly available to the internet. Unless you intentionally want your content to be public, you should review your project permissions. If you have projects that are publicly available in Jira Server, remove their anonymous access setup before migrating to Cloud. You can always make these projects public again after migrating.
移行前に、すべての公開エンティティの権限をログイン済みのユーザーのみに変更します。「移行前のチェック」画面に、この変更に関する警告が表示されます。
SQL を使用した検証 (Postgres でテスト済み)
プロジェクト
これによっていずれかの権限が [すべてのユーザー] に設定されているプロジェクトにフラグが付けられます。
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;
フィルター
"全員で共有" 共有タイプ (グローバル) のフィルターの一覧を取得します。
// 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';
アジャイルボード
"全員で共有" 共有タイプ (グローバルなど) のアジャイル ボードのリストを取得します。
// 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';
ダッシュボード
"全員で共有" 共有タイプ (グローバル) のダッシュボードの一覧を取得します。
// 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. Review your Data Center setup [mandatory]
アプリケーション メモリ (JVM ヒープ サイズ)
Depending on the number of issues or projects to be migrated, Jira Data Center might experience an OutOfMemory error that can crash the entire migration. To prevent this, ensure that your application is running with at least 4GBs of Heap Allocation. Learn how to increase Jira's application memory
一般的なインスタンス データセットのサイズとリソース (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 以上であることを確認します。
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 に近いことを確認します。
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 (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。
JVM_MINIMUM_MEMORY="4096m"
JVM_MAXIMUM_MEMORY="4096m"
Windows - サービスとして実行していない
/jira-installation-directory/bin/setenv.bat ファイルに移動し、次の両方のパラメーターが 4096m または 4g (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。
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. Check if you’ve exceeded character limit for Jira Cloud [mandatory]
Jira Cloud doesn’t support more than 32,767 characters for both description and comments in issues (work item in cloud).
You can use the page to view workarounds and queries to find affected issues.
11. Advanced Roadmaps の共有チームを確認する (推奨)
Jira Cloud に移行するカスタマーには、メンバーシップが必要なアトラシアン チームに変換される共有チームがあります。アトラシアン チームの詳細をご確認ください。
移行時に、メンバーがいないチームには既定メンバーが割り当てられます。このメンバーは、組織管理者権限とチーム管理アクセス権のいずれか、または両方を持つユーザーです。
チームへの予期しない変更を避けるため、移行前に共有チームを確認することをおすすめします。
SQL を使用してメンバーがいないチームを見つける (Postgres でテスト済み)
こうすることで、メンバーがいない共有チームが見つかります。
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 app_user on p."JIRA_USER_ID" = app_user."user_key"
inner join cwd_user cu on app_user."lower_user_name" = cu."lower_user_name"
where active = 1)
and "SHAREABLE" = true;
その後、<Jira base url>/secure/TeamManagement.jspa
のチーム管理ページを使用して個々のチームを見つけ、必要に応じてメンバーシップを調整できます。
12. Identify all the projects linked to Advanced Roadmaps plans [recommended]
プロジェクトを選択する前に、Advanced Roadmaps プランにリンクされているすべてのプロジェクトを特定できます。次の API リクエストを使用します。
API リクエスト
GET:/rest/migration/latest/advanced-roadmaps/all-plan-projects-map
curl を使用した API 呼び出しの例
curl -u {username}:{password} https://{your-server-base-url}/rest/migration/latest/advanced-roadmaps/all-plan-projects-map
レスポンスの例
API を呼び出すと、JSON レスポンスが次の形式で生成されます。
[
{
"planId": 1,
"projectKeys": [
"ABSHI",
"ABNFI",
"AAUDXA"
]
},
{
"planId": 2,
"projectKeys": [
"AKERIA",
"ALTRAA",
"ACAPI",
"ACPMI",
"ACICRA"
]
},
{
"planId": 4,
"projectKeys": [
"AKERIA",
"ALTRAA",
"AMNUA",
"ASAE",
"AMTEE"
]
},
{
"planId": 5,
"projectKeys": [
"ASILA",
"ASOTIA",
"ASRESA"
]
},
{
"planId": 6,
"projectKeys": [
"ASSTS",
"ANNUS",
"ANIKEA"
]
},
{
"planId": 7,
"projectKeys": [
"ASACSA",
"BADOI",
"AVERS"
]
},
{
"planId": 8,
"projectKeys": [
"BBVISA"
]
}
]
この JSON レスポンスには、Advanced Roadmaps プランの ID 、およびインスタンス内の各プランに関連付けられているプロジェクト キーが含まれています。関連付けは課題ソースに由来するものであり、プロジェクト、ボード、またはフィルターにリンクできます。
13. Fix any duplicate shared configuration names [recommended]
To avoid migration conflicts, rename shared configuration (workflows or permission schemes) in your Data Center instance that have the same name as shared configuration in your Cloud site. If we find a conflict we may alter the name of the configuration during migration. Learn how the Migration Assistant links your data
14. Account for free disk space on your Data Center [recommended]
Ensure your Data Center instance has enough disk space for migration. The space needed will depend on your Jira instance size and migration specifics. Account for additional storage for temporary files created during migration.
詳細は、以下のドキュメントを参照してください。
15. Check you won't exceed storage limits on cloud [recommended]
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク スペースと Cloud 内のストレージと制限に関する情報を確認してください。Cloud ストレージについて詳細をご確認ください
16. Prepare your Data Center instance [recommended]
To ensure that your Data Center data migrates successfully, check the status of your data using the Database Integrity Checker (native to Jira Data Center) and the Integrity Check for Jira Marketplace app.
他のチェックおよび実行すべきアクションは次のとおりです。
すべての必須フィールドに値があって null ではない
移行した非アクティブなユーザー ディレクトリを再有効化していること
サーバー インスタンスのクリーンアップについて詳細をご確認ください
カスタム フィールドの説明に埋め込まれた HTML または JavaScript コードを修正する
Jira Cloud doesn't allow HTML or JavaScript code to be embedded in custom field descriptions as this can be an attack vector for Cross-site scripting (XSS) and other security vulnerabilities. You need to either adjust or remove these fields in Jira Data Center before migrating. You can identify these custom fields in Jira Data Center using the queries mentioned in the document How to identify fields with custom JavaScript in their description.
17. Prepare your Cloud site [recommended]
クラウド サイトのセットアップ時には次の点を考慮します。
Your cloud site must have the same Jira apps (previously, products) as your Data Center instance, for example Jira Software and Jira Service Management. This is required if you have user groups with access to all those apps. This is so that all your users and groups migrate successfully.
Ensure that the language of your cloud site is the same as the language on your Data Center site. Some fields may not migrate properly if the languages are different.
Atlassian Guard Standard をご利用の場合は、移行前にそれをセットアップし、ユーザーを最適に移行する方法に関する詳細を確認する必要があります。ユーザー移行戦略の詳細をご確認ください。
Atlassian Guard Premium をご利用の場合は、コンテンツ スキャンの検出ルールのリストをご確認ください。Guard Detect は、各課題が Cloud に移行されるたびに、クレジット カード番号、銀行口座、認証情報などの機密データをスキャンします。これは便利ですが、機密データに関するアラートが非常に多くなる可能性があります。現在、アラートを一括管理するツールを提供していないため、移行中に必要のない検出ルールを一時的にオフにすることをお勧めします。検出される機密データについてご確認ください。
18. Fix external application integrations [recommended]
After performing a Data Center to Cloud migration through Jira Cloud Migration Assistant (JCMA), the IDs of entities like issueId, projectId, commentId, etc. change in cloud.
これらの ID を使用して外部統合を行っていたとしても、移行後は機能しなくなります。移行後、こうした統合を修正することをおすすめします。
クラウド移行ツール (CTT) は、クラウドへの移行後に外部アプリ統合を修正するのに役立つ API とツールのセットです。これらのツールは、テスト段階で統合する必要があります。
19. Prepare Jira Align for the migration [optional]
Jira Align を使用する場合は、移行前、移行中、移行後に追加の手順を完了する必要があります。その中には、Jira Align サポート チームとの協力が必要な作業もありますので、移行タイムラインについてお知らせいただく必要もあります。
20. Back up your data [recommended]
Before you run a migration, we recommend that you back up your current Jira Data Center. If your destination Cloud site has existing data, back up your Jira Cloud site as well.
21. Run a test migration [recommended]
テスト移行を実行してから本番環境に移行することを強くお勧めします。
ステージング環境を使用してテスト移行を実行する場合、本番データをステージング環境にコピーする前に、ステージングの Server ID ([管理] > [システム] > [システム情報]) を保存してください。本番を複製後の最後のステップで、ステージングの Server ID を保存された値に更新します。
22. Notify support of your migration plan [recommended]
週末や祝日に移行する、または Cloud 上のユーザーが 1,000 人を超える場合は、1 ~ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を確保したうえで、移行をサポートします。
23. Check your network bandwidth [recommended]
本番環境への移行の直前に、サーバーでネットワーク テストを実行して、ネットワークが正常であることを確認することをお勧めします (ダウンロード、アップロード、転送帯域幅)。
速度テストを実行するために推奨される CLI ツール: Speedtest CLI: コマンド ラインのインターネット速度テスト
本番環境に追加のセキュリティ制御がないことを確認してください (例: Egress トラフィック スキャナー)。Atlassian Cloud 環境へのデータ アップロードが遅くなる可能性があります。
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
移行計画に関する情報は、Atlassian Migration Program の Web サイトをご覧ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
ピア アドバイスについては、アトラシアン コミュニティでご質問ください。
専門家によるガイダンスについては、アトラシアン パートナーでご相談ください。
追加のサポートが必要な場合は「Cloud 移行ガイド」をご確認、またはライブ チャットによる Q&A を含む Cloud 移行デモにご登録ください。
この内容はお役に立ちましたか?