Jira サイト インポートの移行前チェックリスト

サイト インポートは、Server から Cloudへの移行では利用できなくなります。

2022 年 2 月 1 日から、移行を検討しているユーザー数に応じて、サイト インポートによる Server から Cloud への移行を終了します。

移行を検討している場合:

  • 1 - 10 ユーザー - サイト インポートは 2022年01月31日 まで利用可能

  • 11 - 100 ユーザー - サイト インポートは 2022年02月28日 まで利用可能

  • 101 - 250 ユーザー - サイト インポートは 2022年03月31日 まで利用可能

  • 251 - 1,000 ユーザー - サイト インポートは 2022年04月30日 まで利用可能

  • 1,000 ユーザーを超える場合 - サイト インポートは終了の通知があるまで引き続きご利用いただけます。

Jira Server または Data Center ライセンスのあるユーザー数を表示するには、「Jira アプリケーションのライセンス」ページの「ライセンス認可済みのユーザー数を表示する」セクションをご覧ください。

すべての移行ニーズには、Jira Cloud Migration Assistant を使用することをお勧めします。アプリや Jira Service Management の移行など、Migration Assistant にはいくつかのメリットがあります。間もなく Advanced Roadmaps の移行がサポートされる予定です。

このお知らせの詳細については、コミュニティ投稿をご覧ください。この変更に関する技術的または互換性に関する懸念については、お問い合わせください

Jira サイト インポート用のチェックリストを始める前に、ニーズに合った適切な移行方法を選択していることをご確認ください。Jira Server から Jira Cloud への移行を最も簡単で信頼性の高い方法にするために積極的に投資しているため、ほとんどの移行には Jira Cloud Migration Assistant をお勧めします。

移行前のチェックを完了するには、次のアクセス権が必要な場合があります。

1. Jira Server のバージョンを確認する (必須)

インポートが機能するには、バックアップ XML ファイルがサポート対象のバージョンの Jira Server または Data Center から取得されたものである必要があります。 

Jira Server の UI を使用した検証

  1. アプリケーションの右上にある歯車アイコンをクリックします。

  2. [システム] を選択します

  3. 左側のナビゲーション パネルにある [システム情報] を選択します

  4. 最後に、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 Server のビルドとバージョンを使用して、ビルド番号を Jira バージョンに照合できます。

製品バージョンの検証

1 2 3 4 5 grep 'Build #' <Backup File Location>/entities.xml Example Output: Build # : 100118

2. 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 を含むデータベース ファイルと、添付ファイルやその他のメディアを含むファイルに分割することをお勧めします。

これによってタイムアウト エラーを防いだり、インポート時の問題のリスクを軽減したりすることができます。

.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 └── avatars

4. 失敗したアップグレード タスクを確認する (必須)

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 のメール ハンドラーの代わりにメールを処理する可能性があります。メールが誤って処理されないように、テスト中はこれらの機能を無効にすることを強くお勧めします。

以下を実行できます。

  1. [Jira 設定] > [システム] の順にクリックします。

  2. [グローバル メール設定] を選択して、[メールのプル機能] と [メールのプロセス機能] をオフにします。

  3. [受信メール] を選択して、すべてのメール サーバーとハンドラーを削除します。

  4. 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)

ソース インスタンスでの移行

  1. Jira をシャット ダウンして、データベースを適切にバックアップする

  2. 重複しているエントリのいずれかを削除します。 

    1 delete from clusteredjob where id =XXXXX;
  3. 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) > 250

XML バックアップ ファイルを使用して検証

次のコマンドで、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 でテスト済み)

Jira Server のライセンス付与済みユーザーのリストを取得する」ガイドで紹介されているクエリによって、ライセンス付与済みユーザーの数を取得します。

サポート Zip を使用した検証

移行を実行する前に次のクエリによって、移行するユーザーの数とご利用の Cloud プランのユーザーの上限を検証します。必要に応じて、ユーザー数を削減、Cloud プランをアップグレード、またはサブスクリプションへのユーザー数を追加します。

1 2 3 4 grep "<Users>" <Support Zip Location>/application-properties/application.xml Example Output: <Users>2205</Users>

13. 添付ファイルのサイズを確認する (推奨)

Jira Cloud へのインポートに多数の添付ファイル (未圧縮で 20+ GB) が含まれる場合、遅延やタイムアウトが発生する可能性があります。データベース バックアップ (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. 孤立データを確認する (推奨)

孤立データがバックアップにある場合は、それらが Cloud 内で適切に処理されずにインポートが失敗することがあります。一般的なシナリオとして 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 TEST

15. ストレージの上限を超えていないことを確認する (推奨)

アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク領域と Cloud ストレージのドキュメントをご確認ください。

16. データをバックアップする (推奨)

移行や本ガイドで推奨されているいずれかの更新を実行する前に、復元ポイントを確保できるように現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある際は、移行後に何らかの理由で変更を元に戻す必要が発生した場合に備えて、同様に Jira Cloud サイトもバックアップします。これはベスト プラクティスであり、メンテナンスを元に戻す必要が発生した場合に備えて復元ポイントを追加します。

17. テスト移行を実行する (推奨)

テスト移行を実行してから本番環境に移行することを強くお勧めします。移行テストのガイダンスをご確認ください。

18. 移行プランをサポートに通知する (推奨)

週末や祝日に移行する、または Cloud のユーザーが 1,000 人を超える場合は、1 ~ 2 か月前に移行サポート チームにお問い合わせすることをお勧めします。アトラシアンで人員を用意して移行をサポートします。

詳細情報とサポート

移行をサポートする多数のチャネルをご用意しています。

その他のヘルプ