Cloud 移行を計画する
Atlassian Server 製品の移行準備に役立つドキュメント。
Jira サイト インポートの移行前チェックリスト
サーバーからクラウドへの移行のためのサイト インポートは終了します
2023 年 11 月、サーバーからクラウドへの移行のためのサイト インポートの提供が終了します。
すべてのお客様に Jira Cloud Migration Assistant のご利用をおすすめします。Migration Assistant では、プロジェクトごとの移行、またはすべてのデータの一括移行を選択できます。
すべてのデータを一括で移行する新しいオプションでは、サイト インポートがサポートしているものと同じデータ タイプを、よりシームレスに、かつ高い信頼性をもって移行できます。移行アシスタントの詳細についてご確認ください。
1 人から 1,000 人までのユーザーを移行する場合、サイト インポートによるサーバーからクラウドへの移行のご利用はすでに中止されています。1,000 人を超えるユーザーの移行を検討している場合は、2023 年 11 月に終了となるまで、サイト インポートを引き続きご利用になれます。
Jira Server または Data Center のライセンス ユーザー数を表示するには、「Jira アプリのライセンス付与」ページの「ライセンス ユーザー数の表示」セクションをご確認ください。このお知らせの詳細については、コミュニティ投稿をご覧ください。
これらの変更に関する技術的な懸念がある場合は、アトラシアンまでお問い合わせください。
Jira サイト インポート用のチェックリストを始める前に、ニーズに合った適切な移行方法を選択していることをご確認ください。Jira Server から Jira Cloud への移行を最も簡単で信頼性の高い方法にするために積極的に投資しているため、ほとんどの移行には Jira Cloud Migration Assistant をお勧めします。Cloud 移行方法について詳細をご確認ください
移行前のチェックを完了するには、次のアクセス権が必要な場合があります。
Jira Server または Cloud のユーザー インターフェイス
解凍された Jira サポート ZIP。サポート ZIP ファイルの作成方法をご確認ください
解凍された Jira XML バックアップ。XML バックアップの作成方法をご確認ください
ソース インスタンスでの SQL クエリの実行
1. Jira Server のバージョンを確認する (必須)
インポートが機能するには、バックアップ XML ファイルがサポート対象のバージョンの Jira Server または Data Center から取得されたものである必要があります。サポート対象バージョンについて詳細をご確認ください
Jira Server の UI を使用した検証
アプリケーションの右上にある歯車アイコンをクリックします。
[システム] を選択します
左側のナビゲーション パネルにある [システム情報] を選択します
最後に、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"/>XML バックアップ ファイルを使用して検証
ビルド番号と Jira バージョンを照合できます。Jira Server のビルドとバージョンについて詳細をご確認ください
製品バージョンの検証
1
2
3
4
5
grep 'Build #' <Backup File Location>/entities.xml
Example Output:
Build # : 1001182. XML ファイルが有効であることを確認する (必須)
entities.xml と activeobjects.xml の両方が有効な XML ファイルであることを確認します。複雑な環境を持つ大規模なお客様の環境からのエクスポートでは、XML 構造が無効になる場合があります。
XML バックアップ ファイルを使用して検証
次のクエリを使用して、ファイルが有効であるかどうかを確認します。
1
2
xmllint --noout <Backup File Location>/entities.xml
xmllint --noout <Backup File Location>/activeobjects.xml : 100118コマンドで出力が返されない場合、ファイルは有効です。例外が発生した場合、フォーマット エラーのある箇所が示されます。
3. XML ファイルの構造を確認する (必須)
バックアップ ファイルがインポート用として適切に構築されていることを確認します。
インスタンスが大規模な場合は、Cloud バックアップ ファイルを次のように分割することをお勧めします。
activeobjects.xml と entities.xml を含むデータベース ファイル
添付ファイルやその他のメディア用の個別のファイル
これによってタイムアウト エラーを防いだり、インポート時の問題のリスクを軽減したりすることができます。Cloud バックアップ ファイルの分割について詳細をご確認ください
.xml ファイルの合計サイズは、圧縮してインポートする前の段階で、10GB 以下である必要があります。それ以上のサイズのファイルをインポートする場合は、サポートにお問い合わせください。
XML バックアップ ファイルを使用して検証
メディアやその他の添付ファイルからデータを分離するかどうかに応じて、階層が次の関連する形式に一致するかどうかを確認します。
添付ファイルとデータ
1
2
3
4
5
6
7
JIRA-backup-XXXXXX
├── activeobjects.xml
├── entities.xml
├── data
│ ├── attachments
│ └── avatars
└── logos添付ファイルと他のメディアのみ
1
2
3
4
5
6
7
8
9
10
media-only-X.zip
└─── data
├── attachments
│ ├── ProjectKey
│ │ └── 10000
│ │ ├── IssueKey-1
│ │ ├── IssueKey-2
│ │ └── IssueKey-3
│ └─── ProjectKey2
└── avatars4. 失敗したアップグレード タスクを確認する (必須)
Jira Server に、アップグレードに失敗したタスク、またはアップグレードが保留中となっているタスクがある場合は、Cloud へのインポートが失敗することがあります。
XML バックアップ ファイルを使用して検証
クラウドへのインポートを試みる前に、以下を実行してアップグレードに失敗したタスクを特定します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
grep '<UpgradeHistory' <Backup File Location>/entities.xml | awk 'BEGIN{ORS="\n"};{print $2}{print $5"\n"}'
Example Output:
id="10000"
status="complete"
id="10100"
status="complete"
id="10101"
status="complete"
id="10104"
status="complete"
id="10105"
status="failed"
1
2
3
4
5
6
7
8
9
10
11
12
grep '<UpgradeTaskHistory' <Backup File Location>/entities.xml | awk 'BEGIN{ORS="\n"};{print $2}{print $5"\n"}'
Example Output:
id="10000"
status="complete"
id="10100"
status="complete"
id="10101"
status="complete"
id="10104"
status="complete"
id="10105"
status="failed"任意のアップグレード タスクが "failed" を返す場合、回避策として、それらを "complete" に更新するか、失敗したアップグレード タスクをまとめて削除します。要素を削除する際には、結果となる XML 構造が有効であることを確認します。
変更を加えたら、ファイルを保存して再度圧縮し、元のバックアップ ファイルと同じファイル構造を保持するようにします。
5. 重複しているユーザー メールや無効なユーザー メールを確認する (必須)
インポートに失敗する最も一般的な理由の 1 つは、メールが重複していたり、無効だったりすることです。インポート チェックでは重複しているメールや無効なメールが確認されますが、これによって時間がかかるインポートまたはアップロードに失敗したり、大規模なお客様の場合は保守時間がかかったりする場合があります。ベスト プラクティスは、このようなメール アドレスを事前に確認することです。
XML バックアップ ファイルを使用して検証
重複ユーザー
以下を実行して、重複メールを特定します (メールの左側に 2 以上の数が表示される)。
1
2
3
4
5
6
7
grep 'lowerEmailAddress="' <Backup File Location>/entities.xml |
awk -F\lowerEmailAddress=\" '{print $2}' | cut -d\" -f1 | sort | uniq -с
Example Output:
1 felix.test@test.com
2 fixed.test@test.com
1 florian.test@test.com以下は db の追加クエリです (上記と同じ機能を持つ)。
1
2
3
4
5
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;重複が見つかった場合、ソース インスタンスでそれらを修正するか entities.xml を編集して一意にします。
さらに、アドオン ユーザーが存在する場合は、移行時に問題が発生する可能性があります。Cloud にインポートする前にアドオン ユーザーをクリーン アップすることで、この問題を回避できます。
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. テスト中に Cloud で受信メール ハンドラーを無効にする (必須)
初期設定では、受信メール ハンドラーはインポート後に有効になります。これによって、Cloud のメール ハンドラーが Server のメール ハンドラーの代わりにメールを処理する可能性があります。メールが誤って処理されないように、テスト中はこれらの機能を無効にすることを強くお勧めします。
以下を実行できます。
[Jira 設定] > [システム] の順にクリックします。
[グローバル メール設定] を選択して、[メールのプル機能] と [メールのプロセス機能] をオフにします。
[受信メール] を選択して、すべてのメール サーバーとハンドラーを削除します。
Jira Service Management を使用している場合は、[設定] > [製品] > [メール リクエスト] の順に移動して、[メール アドレス] セクションが空であることを確認します。
7. 無効な文字や処理されていない文字を確認する (必須)
古いバージョンの Jira では、制御文字を含むテキストをコピーして Jira 課題のフィールドに貼り付けることができました。Jira のバックアップ形式は XML であり、XML ではほとんどの制御文字が保存されないため、これによって問題が発生します。制御文字を含む XML が Jira にインポートされると、不可逆なエラーが発生してインポートに失敗します。
これを防ぐには、entities.xml ファイルと activeobjects.xml ファイルの両方の XML バックアップから無効な文字を削除します。無効な文字の削除について詳細をご確認ください
8. 重複しているワークフローを修正する (必須)
バックアップ ファイルに同じ名前のワークフローがある場合は、インポートに失敗することがあります。製品設計によって、ユーザー インターフェイスからワークフローを作成した場合、それらは別の名前を持つ可能性があります。ただし、ワークフロー名に大文字と小文字が異なる同じ名前がある場合 (例:「workflow1」と「WORKFLOW1」)、インポートの失敗につながる可能性があります。
XML バックアップ ファイルを使用して検証
ワークフローの重複
次のクエリを使用して、ワークフローのすべての名前が一意であることを確認します。
1
2
3
4
5
6
7
8
9
10
11
12
13
cat <Backup File Location>/entities.xml | grep '<Workflow id="' | cut -d " " -f7- | sort | uniq -c
Example Output:
1 name="Software Simplified Workflow for Project SER">
1 name="Software Simplified Workflow for Project SKP">
1 name="Software Simplified Workflow for Project TES">
1 name="TEST: Change Management workflow for Jira Service Desk">
1 name="TEST: Incident Management workflow for Jira Service Desk">
1 name="TEST: Jira Service Desk default workflow">
1 name="TEST: Problem Management workflow for Jira Service Desk">
1 name="TEST: Service Request Fulfilment with Approvals workflow for Jira Service Desk">
1 name="TEST: Service Request Fulfilment workflow for Jira Service Desk">
1 name="company-managed default workflow">出力のそれぞれのワークフロー名が一意である (名前の左側に 1 が表示されている) ことを確認します。重複が見つかった場合は、ソース インスタンスでそれらを修正するか entities.xml を編集して一意にします。
9. 重複クラスター ジョブを見つける (必須)
バックアップ ファイルに同じ ID の重複クラスター ジョブがある場合は、インポートに失敗することがあります。このレポートの記載に従って、インポート前にクラスター ジョブに重複 ID がないことを確認する必要があります。
SQL を使用した検証 (Postgres でテスト済み)
クラスタ ジョブの重複を見つける
次のクエリを使用して、重複しているクラスタ ジョブを見つけます。
1
2
3
SELECT * FROM clusteredjob
WHERE job_id in
(SELECT job_id FROM clusteredjob GROUP BY job_id HAVING COUNT(*)>1)ソース インスタンスでの移行
Jira をシャット ダウンして、データベースを適切にバックアップする
重複しているエントリのいずれかを削除します。
1delete from clusteredjob where id =XXXXX;Jira を再起動する
XML バックアップ ファイルを使用して検証
最初に、次のクエリを実行します。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
grep 'ClusteredJob id="' <Backup File Location>/entities.xml | cut -d "=" -f2 | sort | uniq -c
Example Output:
1 "10001" jobId
1 "10107" jobId
1 "10201" jobId
1 "10202" jobId
1 "10204" jobId
1 "10205" jobId
1 "10300" jobId
1 "10301" jobId
1 "10302" jobId
1 "10303" jobId
1 "10304" jobId
1 "10307" jobId
1 "10308" jobId
1 "10309" jobId
1 "10311" jobId出力のそれぞれの名前が一意である (名前の左側に 1 が表示されている) ことを確認します。重複が見つかった場合は、ソース インスタンスでそれらを修正するか entities.xml を編集して一意にします。
10. 添付ファイル名の長さを確認する (必須)
バックアップに 250 文字を超えるファイル名を持つ添付ファイルがある場合、インポートに失敗することがあります。
SQL を使用した検証 (Postgres でテスト済み)
次のクエリは、250 文字を超える添付ファイルを識別します。
1
2
3
SELECT id,issueid, char_length(filename)
FROM fileattachment
WHERE char_length(filename) > 250XML バックアップ ファイルを使用して検証
次のコマンドで、250 文字を超えるファイル名が返されないことを確認します。0 と表示されるはずです。
1
2
3
4
5
grep <Backup File Location>/entities.xml | cut -d\ -f9 | awk 'length > 250 {print ;}' | wc -l
Example Output:
0 250 文字を超えるファイルを見つけたら、それを entities.xml で特定して filename フィールドを [XXXXX.txt] に名称変更します。
11. パブリック アクセス設定を確認する (必須)
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;12. Cloud ユーザーの上限を超えていないことを確認する (必須)
Server から移行するユーザーと、Cloud にすでに存在するユーザーの合計がサブスクリプション ユーザー階層を超えないようにします。たとえば、51 ～ 100 ユーザーのサブスクリプションを契約しているときに 110 人のアクティブなユーザーをインポートしようとすると、移行は失敗します。
これを解決するには、次のいずれかの方法に従ってください:
ユーザー数の上限が大きいプランを登録する
移行前にユーザーの数を減らす
アトラシアン サポートに問い合わせて、移行前に製品へのアクセス権がないユーザーをインポートする
SQL を使用した検証 (Postgres でテスト済み)
SQL クエリを使用して、ライセンスを持つユーザー数を取得できます。これらの SQL クエリの使用方法をご確認ください
サポート Zip を使用した検証
移行を実行する前に次のクエリによって、移行するユーザーの数とご利用の Cloud プランのユーザーの上限を検証します。必要に応じて、ユーザー数を削減、Cloud プランをアップグレード、またはサブスクリプションへのユーザー数を追加します。
1
2
3
4
grep "<Users>" <Support Zip Location>/application-properties/application.xml
Example Output:
<Users>2205</Users>13. 添付ファイルのサイズを確認する (推奨)
Jira Cloud へのインポートに多数の添付ファイル (未圧縮で 20GB 以上) が含まれる場合、遅延やタイムアウトが発生する可能性があります。データベース バックアップ (entities.xml および activeobjects.xml ファイル) をインポートしてからメディア (添付ファイル、プロジェクト アバター、およびロゴ) を個別にインポートすることをお勧めします。メディアのお別のインポートについて詳細をご確認ください
SQL を使用した検証 (Postgres でテスト済み)
次の 1 つめのクエリは、データベースの添付ファイルの全体的なサイズを識別します。さらに評価する必要がある場合は、2 番目のクエリでプロジェクトごとにそれらを分割します。
1
2
3
4
5
6
7
8
9
10
11
select round(sum(filesize)/1024/1024,2)
as "Total Attachment Size(MB)"
from fileattachment
join jiraissue on jiraissue.id = fileattachment.issueid;
select round(sum(filesize)/1024/1024,2)
as "Size(MB) by Project", project.pname as "Project Name"
from fileattachment
join jiraissue on jiraissue.id = fileattachment.issueid
join project on project.id = jiraissue.project group by project.pname order by "Size(MB) by Project" desc;14. 孤立データを確認する (推奨)
バックアップ内に孤立データがある場合、インポートが失敗することがあります。一般的なシナリオとして null プロジェクト キーがあります。孤立データについて詳細をご確認ください
XML バックアップ ファイルを使用して検証
孤立データの一部を特定しましょう。出力に空白行がある場合は null のプロジェクト キーが存在する可能性が高いため、key 値が空にならないようにこれを修正する必要があります。Cloud にインポート前に、entities.xml で修正します。
XML の有効性の検証
1
2
3
4
5
6
7
8
xmlstarlet sel -t -v "/entity-engine-xml/Project/@key" -n <Backup File Location>/entities.xml
Example Output:
SER
SKP
TEST15. ストレージの上限を超えていないことを確認する (推奨)
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク スペースと Cloud 内のストレージと制限に関する情報を確認してください。Cloud ストレージについて詳細をご確認ください
16. データをバックアップする (推奨)
移行や本ガイドで推奨されているいずれかの更新を実行する前に、復元ポイントを確保できるように現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある際は、移行後に何らかの理由で変更を元に戻す必要が発生した場合に備えて、同様に Jira Cloud サイトもバックアップします。これはベスト プラクティスであり、メンテナンスを元に戻す必要が発生した場合に備えて復元ポイントを追加します。
17. テスト移行を実行する (推奨)
テスト移行を実行してから本番環境に移行することを強くお勧めします。移行のテストについて詳細をご確認ください
18. 移行プランをサポートに通知する (推奨)
週末や祝日に移行する、または Cloud 上のユーザーが 1,000 人を超える場合は、1 ～ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を確保したうえで、移行をサポートします。移行のサポートについて詳細をご確認ください
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
移行計画に関する情報は、Atlassian Migration Program の Web サイトをご覧ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
ピア アドバイスについては、アトラシアン コミュニティでご質問ください。
専門家によるガイダンスについては、アトラシアン パートナーでご相談ください。
追加のサポートが必要な場合は「Cloud 移行ガイド」をご確認、またはライブ チャットによる Q&A を含む Cloud 移行デモにご登録ください。
この内容はお役に立ちましたか?