Cloud 移行を計画する
Atlassian Server 製品の移行準備に役立つドキュメント。
Jira Cloud Migration Assistant の移行前チェックリスト
Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。次の点が確認されます。
すべてのユーザーに有効で一意のメール アドレスが紐付けられているかどうか
プロジェクト名またはキーが Cloud にすでに存在するプロジェクト名またはキーと競合していないこと
移行アシスタントが最新かどうか
ただし、すべてが確認されるわけではないため、移行の開始前に次のリストによってチェックを行う必要があります。
移行前のチェックを完了するには、次のようなアクセス権が必要になる場合があります。
Jira Server または Cloud ユーザー インターフェイスへのアクセス
未解凍の Jira サポート Zip へのアクセス
未解凍の Jira XML バックアップへのアクセス
SQL クエリをソース インスタンスで実行する方法
1. ユーザーの移行計画を作成する (必須)
外部ディレクトリ
アクティブな外部ユーザー ベースを同期して、ユーザー移行戦略の一環としてすべてのユーザーやグループが適切に移行されていることをご確認ください。また、これによって、移行中にデータが適切なユーザーに引き続きリンクされるようにします。
外部 ID プロバイダーによってユーザーを管理している場合は、移行前にそれらのユーザーがアクティブで内部ユーザー ベースと同期されていることをご確認ください。
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 で移行できません。エラーを回避するには、移行前にメール アドレスの重複を見つけて修正する必要があります。ユーザー情報が LDAP サーバーで管理されている場合は、移行前にそこでメールを更新して Jira と同期する必要があります。ユーザー情報をローカルで管理している場合は、Jira Server または Data Center のユーザー インターフェイスでそれらを修正できます。
SQL を使用した検証 (Postgres でテスト済み)
次のクエリを使用して、重複しているメール アドレス (存在する場合)、これらのアドレスの重複回数、そのメール アドレスに割り当てられたユーザーを見つけられます。
1
2
select lower_email_address, count(lower_email_address), array_agg(user_name) as "Users with Dupe E-Mail"
from cwd_user group by lower_email_address having count(lower_email_address) > 1;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 のドメインに接続します。ファイアウォールまたはリバース プロキシによってドメインがブロックされると、移行は失敗します。移行前に、Atlassian Cloud 製品の IP アドレスとドメインがセキュリティ ルールによってブロックされていないことを確認します。
7. アプリの移行方法を決定する (必須)
Jira Cloud Migration Assistant によってアプリ データを移行できます。移行するアプリの Marketplace パートナー (アプリ ベンダー) にお問い合わせして構築した移行パスが Jira Cloud Migration Assistant をサポートしているかどうかを確認したうえで、データの効率的な移行方法についてアドバイスを求めましょう。これには、Portfolio for Jira などのアトラシアン製アプリが含まれます。Portfolio for Jira を移行する必要がある場合は、関連する機能リクエストをウォッチすると最新情報を受け取れます。
Jira Cloud では Portfolio はスタンドアロン アプリとして提供されていませんが、Jira Software Cloud Premium の Advanced Roadmaps として機能を利用できます。
8. パブリック アクセス設定を確認する (必須)
Jira Server または Jira Cloud サイトをインターネットに公開するように構成できます。コンテンツを意図的に公開する場合を除いて、プロジェクト権限を確認する必要があります。Jira Server に公開しているプロジェクトがある場合は、Cloud に移行する前にそれらの匿名アクセスのセットアップを削除します。移行後、これらのプロジェクトはいつでも公開できます。
SQL を使用した検証 (Postgres でテスト済み)
プロジェクト
これによって、プロジェクトの閲覧権限がすべてのユーザーに設定されているプロジェクトを見つけられます。
1
2
3
4
5
6
7
8
9
10
11
12
13
// get list of project permission schemes which has share type as "Anyone" (i.e. open)
SELECT p.id, p.pname, ps.name 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.permission_key='BROWSE_PROJECTS'
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 で発生する場合があります。これを防ぐためには「Jira アプリケーション メモリの容量を増やす」に記載されているパラメーターを確認して、アプリが 4GB 以上のヒープ割り当てで実行されていることをご確認ください。
また、オープンなファイルの制限を確認します。32768 になるべく近い数が理想的です。システムに設定されるオープンなファイルの数は、Linux ディストリビューションに応じて異なる場合があります。これをシステム コマンド経由で確認する方法が不明な場合は、サポート Zip を作成して application-properties/application.xml ファイルを開き、<max-file-descriptor> を検索します。この数が 32768 に近い場合は、必要に応じて調整します。詳細については、「Too many open files エラー」ドキュメントでご確認ください。これは、Windows を実行している場合には適用されません。
サポート 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 インスタンスの共有設定 (ワークフローまたは権限スキーム) の名前を変更します。競合が見つかった場合は、移行中に設定の名前が変更されることがあります。
12. ストレージの上限を超えていないことを確認する (推奨)
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク領域と Cloud ストレージのドキュメントをご確認ください。
13. Server インスタンスを準備する (推奨)
Server データが正常に移行されるように、データベース整合性チェッカー (Jira Server のネイティブ機能) と Atlassian Marketplace の Integrity Check for Jira アプリによって、データのステータスを確認します。
他のチェックおよび実行すべきアクションは次のとおりです。
すべての必須フィールドに値があって null ではない
移行したいアーカイブ済みのプロジェクトを再有効化していること
移行した非アクティブなユーザー ディレクトリを再有効化していること
データのクリーンアップに関する詳細については「移行前にサーバー インスタンスをクリーンアップする」をご参照ください。
14. Cloud サイトを準備する (推奨)
Cloud サイトのセットアップ時には次の点を考慮します。
Jira Service Management (旧 Jira Service Desk) を除いて、Cloud サイトでは Server サイトと同じ Jira 製品が有効にされている必要があります。たとえば、Server サイトに Jira Core と Jira Software がある場合は、Jira Core プロジェクトを移行しない場合でも Cloud サイト上で両方が必要になります。これは、すべてのユーザーとグループを正常に移行するためです。移行後にこれらの製品を使用しない場合は、関連製品の無料トライアルをセットアップしてから移行後に無効にします。
Cloud サイトの言語が、Server サイトの言語と同じであることを確認します。言語が異なる場合は、一部のフィールドが適切に移行されない場合があります。
Atlassian Access を使用している場合は、移行前にユーザー移行戦略を決定して Atlassian Access をセットアップする必要があります。
15. データをバックアップする (推奨)
移行を実行する前に、現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある場合は、同様に Jira Cloud サイトもバックアップします。
16. テスト移行を実行する (推奨)
テスト移行を実行してから本番環境に移行することを強くお勧めします。移行テストのガイダンスをご確認ください。
17. 移行プランをサポートに通知する (推奨)
週末や祝日に移行する、または Cloud のユーザーが 1,000 人を超える場合は、1 ～ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を用意して移行をサポートします。
詳細情報とサポート
移行をサポートする多数のチャネルをご用意しています。
移行計画に関する情報は、Atlassian Migration Program の Web サイトをご覧ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
ピア アドバイスについては、アトラシアン コミュニティでご質問ください。
専門家によるガイダンスについては、アトラシアン パートナーでご相談ください。
追加のサポートが必要な場合は「Cloud 移行ガイド」をご確認、またはライブ チャットによる Q&A を含む Cloud 移行デモにご登録ください。
この内容はお役に立ちましたか?