Cloud 移行を計画する
Atlassian Server 製品の移行準備に役立つドキュメント。
Jira Cloud Migration Assistant の移行前チェックリスト
Jira Cloud Migration Assistant 1.7.3 以降へのアップグレード
より安定した信頼性の高い移行体験を提供するために、添付ファイルやその他のメディア ファイルの移行方法を改善しました。
2022 年 9 月 19 日以降、今後のすべての移行ニーズに合わせて、Jira Cloud Migration Assistant 1.7.3 以降にアップグレードすることをお勧めします。
2023 年 1 月 31 日以降は、Jira Cloud Migration Assistant 1.7.1 以前をご利用いただけなくなります。
このお知らせとアップグレード方法に関する詳細をご確認ください。
さらなる詳細や技術的な懸念については、お問い合わせください。
Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。次の点が確認されます。
すべてのユーザーに有効で一意のメール アドレスが紐付けられているかどうか
プロジェクト名またはキーが Cloud にすでに存在するプロジェクト名またはキーと競合していないこと
移行アシスタントが最新かどうか
ただし、すべてが確認されるわけではないため、移行の開始前に、この移行前チェックリストを一通り確認する必要があります。
はじめる前に
移行前のチェックを完了するには、次のようなアクセス権が必要になる場合があります。
Jira Server または Cloud ユーザー インターフェイスへのアクセス
解凍された Jira サポート ZIP にアクセスする。サポート ZIP ファイルの作成方法をご確認ください
解凍された Jira XML バックアップにアクセスする。XML バックアップの作成方法をご確認ください
SQL クエリをソース インスタンスで実行する方法
1. ユーザーの移行計画を作成する (必須)
外部ディレクトリ
アクティブな外部ユーザー ベースを同期して、ユーザー戦略の一環としてすべてのユーザーやグループが適切に移行されていることを確認します。また、これによって、移行中にデータが適切なユーザーに引き続きリンクされるようにします。ユーザー移行戦略について詳細をご確認ください
外部 ID プロバイダーを使用してユーザーを管理している場合は、移行前にそれらのユーザーがアクティブで Jira と同期されていることをご確認ください。
Jira Server ユーザー インターフェイスによって同期する
右上隅の歯車アイコンを選択します。
[ユーザー管理] を選択します。
[ユーザー ディレクトリ] を選択します。
[同期] を選択します。
サポート 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: trueJira Cloud Migration Assistant は次を移行します。
すべてのユーザーまたはグループ
選択したプロジェクトに関連するユーザーとグループ
2. Jira Server のバージョンを確認する (必須)
Jira がサポート対象バージョンで実行されていることをご確認ください。サポート対象外のバージョンである場合、Migration Assistant は機能しません。サポート対象バージョンについて確認する
Jira Server ユーザー インターフェイスによって検証する
右上隅の歯車アイコンを選択します。
[システム] を選択します。
左側ナビゲーション パネルの [システム情報] を選択します。
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 を開きます。
[Assess and prepare users (ユーザーの評価と準備)] カードで、[Begin assessing (評価を開始)] を選択します。空の結果のページに移動します。
評価を開始するには、[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 ユーザー インターフェイスによって検証する
サーバーのタイムゾーンを確認するには、次の手順に従います。
右上隅の歯車アイコンを選択します。
[システム] を選択します。
左側ナビゲーション パネルの [システム情報] を選択します。
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. 共有されている設定名の重複を修正する (推奨)
移行の競合を防ぐために、Cloud サイトの共有設定と同名の Server インスタンスの共有設定 (ワークフローまたは権限スキーム) の名前を変更します。競合が見つかった場合は、移行中に設定の名前が変更されることがあります。Migration Assistant がデータをリンクする方法をご確認ください
12. ストレージの上限を超えていないことを確認する (推奨)
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク スペースと Cloud 内のストレージと制限に関する情報を確認してください。Cloud ストレージについて詳細をご確認ください
13. Server インスタンスを準備する (推奨)
Server データが正常に移行されるように、データベース整合性チェッカー (Jira Server のネイティブ機能) と Atlassian Marketplace の Integrity Check for Jira アプリによって、データのステータスを確認します。
他のチェックおよび実行すべきアクションは次のとおりです。
すべての必須フィールドに値があって null ではない
移行したいアーカイブ済みのプロジェクトを再有効化していること
移行した非アクティブなユーザー ディレクトリを再有効化していること
サーバー インスタンスのクリーンアップについて詳細をご確認ください
14. 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 を使用している場合は、移行前にそれを設定し、ユーザーを最適に移行する方法について詳細を確認する必要があります。ユーザー移行戦略について詳細をご確認ください
15. データをバックアップする (推奨)
移行を実行する前に、現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある場合は、同様に Jira Cloud サイトもバックアップします。
16. テスト移行を実行する (推奨)
テスト移行を実行してから本番環境に移行することを強くお勧めします。
17. 移行プランをサポートに通知する (推奨)
週末や祝日に移行する、または Cloud 上のユーザーが 1,000 人を超える場合は、1 ～ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を確保したうえで、移行をサポートします。
詳細情報とサポート
移行をサポートする多数のチャネルをご用意しています。
移行計画に関する情報は、Atlassian Migration Program の Web サイトをご覧ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
ピア アドバイスについては、アトラシアン コミュニティでご質問ください。
専門家によるガイダンスについては、アトラシアン パートナーでご相談ください。
追加のサポートが必要な場合は「Cloud 移行ガイド」をご確認、またはライブ チャットによる Q&A を含む Cloud 移行デモにご登録ください。
この内容はお役に立ちましたか?