Cloud 移行を計画する
Atlassian Server 製品の移行準備に役立つドキュメント。
サーバーからクラウドへの移行のためのサイト インポートは終了します
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 クエリの実行
インポートが機能するには、バックアップ XML ファイルがサポート対象のバージョンの Jira Server または Data Center から取得されたものである必要があります。サポート対象バージョンについて詳細をご確認ください
アプリケーションの右上にある歯車アイコンをクリックします。
[システム] を選択します
左側のナビゲーション パネルにある [システム情報] を選択します
最後に、Jira のバージョンを確認します
1
2
3
4
5
grep "<product name" <Support Zip Location>/application-properties/application.xml
Example Output:
<product name="Jira" version="8.7.1"/>
ビルド番号と Jira バージョンを照合できます。Jira Server のビルドとバージョンについて詳細をご確認ください
1
2
3
4
5
grep 'Build #' <Backup File Location>/entities.xml
Example Output:
Build # : 100118
entities.xml と activeobjects.xml の両方が有効な XML ファイルであることを確認します。複雑な環境を持つ大規模なお客様の環境からのエクスポートでは、XML 構造が無効になる場合があります。
次のクエリを使用して、ファイルが有効であるかどうかを確認します。
1
2
xmllint --noout <Backup File Location>/entities.xml
xmllint --noout <Backup File Location>/activeobjects.xml : 100118
コマンドで出力が返されない場合、ファイルは有効です。例外が発生した場合、フォーマット エラーのある箇所が示されます。
バックアップ ファイルがインポート用として適切に構築されていることを確認します。
インスタンスが大規模な場合は、Cloud バックアップ ファイルを次のように分割することをお勧めします。
activeobjects.xml と entities.xml を含むデータベース ファイル
添付ファイルやその他のメディア用の個別のファイル
これによってタイムアウト エラーを防いだり、インポート時の問題のリスクを軽減したりすることができます。Cloud バックアップ ファイルの分割について詳細をご確認ください
.xml ファイルの合計サイズは、圧縮してインポートする前の段階で、10GB 以下である必要があります。それ以上のサイズのファイルをインポートする場合は、サポートにお問い合わせください。
メディアやその他の添付ファイルからデータを分離するかどうかに応じて、階層が次の関連する形式に一致するかどうかを確認します。
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
└── avatars
Jira Server に、アップグレードに失敗したタスク、またはアップグレードが保留中となっているタスクがある場合は、Cloud へのインポートが失敗することがあります。
クラウドへのインポートを試みる前に、以下を実行してアップグレードに失敗したタスクを特定します。
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 構造が有効であることを確認します。
変更を加えたら、ファイルを保存して再度圧縮し、元のバックアップ ファイルと同じファイル構造を保持するようにします。
インポートに失敗する最も一般的な理由の 1 つは、メールが重複していたり、無効だったりすることです。インポート チェックでは重複しているメールや無効なメールが確認されますが、これによって時間がかかるインポートまたはアップロードに失敗したり、大規模なお客様の場合は保守時間がかかったりする場合があります。ベスト プラクティスは、このようなメール アドレスを事前に確認することです。
以下を実行して、重複メールを特定します (メールの左側に 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 にインポートする前にアドオン ユーザーをクリーン アップすることで、この問題を回避できます。
次のクエリによってこのような条件を満たすユーザーを見つけてメールをソースで削除または更新し、@connect.atlassian.com 以外を設定するようにします。
1
2
--ADD-ON USERS - TESTED ON POSTGRESQL
select * from cwd_user where lower_email_address like 'connect.atlassian.com';
初期設定では、受信メール ハンドラーはインポート後に有効になります。これによって、Cloud のメール ハンドラーが Server のメール ハンドラーの代わりにメールを処理する可能性があります。メールが誤って処理されないように、テスト中はこれらの機能を無効にすることを強くお勧めします。
以下を実行できます。
[Jira 設定] > [システム] の順にクリックします。
[グローバル メール設定] を選択して、[メールのプル機能] と [メールのプロセス機能] をオフにします。
[受信メール] を選択して、すべてのメール サーバーとハンドラーを削除します。
Jira Service Management を使用している場合は、[設定] > [製品] > [メール リクエスト] の順に移動して、[メール アドレス] セクションが空であることを確認します。
古いバージョンの Jira では、制御文字を含むテキストをコピーして Jira 課題のフィールドに貼り付けることができました。Jira のバックアップ形式は XML であり、XML ではほとんどの制御文字が保存されないため、これによって問題が発生します。制御文字を含む XML が Jira にインポートされると、不可逆なエラーが発生してインポートに失敗します。
これを防ぐには、entities.xml ファイルと activeobjects.xml ファイルの両方の XML バックアップから無効な文字を削除します。無効な文字の削除について詳細をご確認ください
バックアップ ファイルに同じ名前のワークフローがある場合は、インポートに失敗することがあります。製品設計によって、ユーザー インターフェイスからワークフローを作成した場合、それらは別の名前を持つ可能性があります。ただし、ワークフロー名に大文字と小文字が異なる同じ名前がある場合 (例:「workflow1」と「WORKFLOW1」)、インポートの失敗につながる可能性があります。
次のクエリを使用して、ワークフローのすべての名前が一意であることを確認します。
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 を編集して一意にします。
バックアップ ファイルに同じ ID の重複クラスター ジョブがある場合は、インポートに失敗することがあります。このレポートの記載に従って、インポート前にクラスター ジョブに重複 ID がないことを確認する必要があります。
次のクエリを使用して、重複しているクラスタ ジョブを見つけます。
1
2
3
SELECT * FROM clusteredjob
WHERE job_id in
(SELECT job_id FROM clusteredjob GROUP BY job_id HAVING COUNT(*)>1)
Jira をシャット ダウンして、データベースを適切にバックアップする
重複しているエントリのいずれかを削除します。
1
delete from clusteredjob where id =XXXXX;
Jira を再起動する
最初に、次のクエリを実行します。
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 を編集して一意にします。
バックアップに 250 文字を超えるファイル名を持つ添付ファイルがある場合、インポートに失敗することがあります。
次のクエリは、250 文字を超える添付ファイルを識別します。
1
2
3
SELECT id,issueid, char_length(filename)
FROM fileattachment
WHERE char_length(filename) > 250
次のコマンドで、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] に名称変更します。
Jira Server または Jira Cloud サイトをインターネットに公開するように構成できます。コンテンツを意図的に公開する場合を除いて、Jira Server で一般に利用できるプロジェクトの権限を再確認して、Cloud に移行前にそれらの匿名アクセスのセットアップを削除することを強くお勧めします。
これにより、プロジェクトの閲覧権限がすべてのユーザーに設定されているプロジェクトを見つけることができます。
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;
Server から移行するユーザーと、Cloud にすでに存在するユーザーの合計がサブスクリプション ユーザー階層を超えないようにします。たとえば、51 ~ 100 ユーザーのサブスクリプションを契約しているときに 110 人のアクティブなユーザーをインポートしようとすると、移行は失敗します。
これを解決するには、次のいずれかの方法に従ってください:
ユーザー数の上限が大きいプランを登録する
移行前にユーザーの数を減らす
アトラシアン サポートに問い合わせて、移行前に製品へのアクセス権がないユーザーをインポートする
SQL クエリを使用して、ライセンスを持つユーザー数を取得できます。これらの SQL クエリの使用方法をご確認ください
移行を実行する前に次のクエリによって、移行するユーザーの数とご利用の Cloud プランのユーザーの上限を検証します。必要に応じて、ユーザー数を削減、Cloud プランをアップグレード、またはサブスクリプションへのユーザー数を追加します。
1
2
3
4
grep "<Users>" <Support Zip Location>/application-properties/application.xml
Example Output:
<Users>2205</Users>
Jira Cloud へのインポートに多数の添付ファイル (未圧縮で 20GB 以上) が含まれる場合、遅延やタイムアウトが発生する可能性があります。データベース バックアップ (entities.xml および activeobjects.xml ファイル) をインポートしてからメディア (添付ファイル、プロジェクト アバター、およびロゴ) を個別にインポートすることをお勧めします。メディアのお別のインポートについて詳細をご確認ください
次の 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;
バックアップ内に孤立データがある場合、インポートが失敗することがあります。一般的なシナリオとして null プロジェクト キーがあります。孤立データについて詳細をご確認ください
孤立データの一部を特定しましょう。出力に空白行がある場合は null のプロジェクト キーが存在する可能性が高いため、key 値が空にならないようにこれを修正する必要があります。Cloud にインポート前に、entities.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
TEST
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク スペースと Cloud 内のストレージと制限に関する情報を確認してください。Cloud ストレージについて詳細をご確認ください
移行や本ガイドで推奨されているいずれかの更新を実行する前に、復元ポイントを確保できるように現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある際は、移行後に何らかの理由で変更を元に戻す必要が発生した場合に備えて、同様に Jira Cloud サイトもバックアップします。これはベスト プラクティスであり、メンテナンスを元に戻す必要が発生した場合に備えて復元ポイントを追加します。
テスト移行を実行してから本番環境に移行することを強くお勧めします。移行のテストについて詳細をご確認ください
週末や祝日に移行する、または Cloud 上のユーザーが 1,000 人を超える場合は、1 ~ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を確保したうえで、移行をサポートします。移行のサポートについて詳細をご確認ください
移行をサポートする多数のチャンネルをご用意しています。
移行計画に関する情報は、Atlassian Migration Program の Web サイトをご覧ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
ピア アドバイスについては、アトラシアン コミュニティでご質問ください。
専門家によるガイダンスについては、アトラシアン パートナーでご相談ください。
追加のサポートが必要な場合は「Cloud 移行ガイド」をご確認、またはライブ チャットによる Q&A を含む Cloud 移行デモにご登録ください。
この内容はお役に立ちましたか?