Jira の移行前のチェックリスト

このページの内容

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

description

Jira Server から Cloud に移行する前にこのチェックリストを使用して、環境とデータの準備が整っていることを確認しましょう。

移行は、複雑で困難なプロセスになることがあります。

アトラシアンではお客様を支援するため、データを Jira Server または Data Center からクラウドに移行する準備が整っていることを確認するために必要なすべての項目を示したチェックリストを作成しました。

一般的なエラーを防ぐため、移行を試す前に次の確認を完了します。

はじめる前に

1. 移行方法を確認する

確認する内容は、移行方法によって異なります。このチェックリストでは次の移行方法を網羅しています。

次に、選択した移行メソッドに対応した移行前のチェックに従います。

2. 準備

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

Jira Cloud Migration Assistant のチェックリスト

Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。次の点が確認されます。

  • すべてのユーザーが有効なメール アドレスを持っていること

  • すべてのユーザーが一意のメール アドレスを持っていること

  • プロジェクト名またはキーがクラウド内のプロジェクト名またはキーと競合していないこと

  • 移行アシスタントが最新かどうか

ただし、移行アシスタントはすべてを確認するわけではありません。このため、移行を開始する前に次のリストを使用したチェックを行う必要があります。

1. ユーザーの移行計画を作成する 必須

外部ディレクトリ

アクティブな外部ユーザー ベースを同期し、ユーザー移行戦略の一環としてすべてのユーザーやグループが適切に移行されていることを確認します。また、これにより、移行中にデータが適切なユーザーに引き続きリンクされるようにします。

外部プロバイダを使用してユーザーを管理している場合、移行前に、それらのユーザーがアクティブで、内部ユーザー ベースと同期されていることを確認します。 

Jira Server の UI を使用した同期
  1. アプリケーションの右上にある歯車アイコンをクリックします。
  2. [ユーザー管理] を選択します
  3. [ユーザー ディレクトリ] を選択します
  4. 最後に、[同期] を選択します
サポート Zip を使用した検証

Epoch タイムスタンプは https://www.epochconverter.com/ などのサイトで照合できます。

必要なディレクトリがアクティブに設定されていることを確認します。


前回の外部ユーザー同期の検証

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


アクティブな外部ディレクトリの検証

grep "Active:" <Support Zip Location>/auth-cfg/directoryConfigurationSummary.txt


Example Output: 
Active: true
Active: true
Active: true
Active: false
Active: true


Jira Cloud Migration Assistant はすべてのユーザーとグループを移行します。移行する具体的なユーザーまたはグループを選択する必要がある場合、アトラシアン サポートにお問い合せください。

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

Jira がサポート対象バージョンで実行していることを確認します。サポー対象のバージョンではない場合、移行アシスタントは機能しません。

Jira Server の UI を使用した検証
  1. アプリケーションの右上にある歯車アイコンをクリックします。

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

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

  4. 最後に、Jira のバージョンを確認します

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

製品バージョンの検証


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 の UI でそれらを修正できます。

SQL を使用した検証 (Postgres でテスト済み)

次のクエリを使用して、重複しているメール アドレス (存在する場合)、これらのアドレスの重複回数、およびそのメール アドレスに割り当てられたユーザーを見つけることができます。

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. 適切な権限を持っていることを確認する 必須

移行を実行するユーザーが、次の権限を持っていることを確認します。

5. グループ名の競合を確認する 必須

クラウド サイトのグループの名前がサーバー サイトのグループと異なることを確認します (意図的に統合しようとしている場合を除く)。移行アシスタントがグループ名の競合を処理する方法」をご確認ください。

一部の移行シナリオでは、サーバー サイトにアドオン ユーザーが発生することがあります。サーバーの世界においてアドオン ユーザーは一般的ではないため、クラウドに戻す移行の際にいくつかの問題が発生する可能性があります。移行の前に、これらのアドオン ユーザーを削除または更新します。

SQL を使用した検証 (Postgres でテスト済み)

次のクエリを使用してこれらのユーザーを見つけ、削除するか、メール アドレスを @connect.atlassian.com 以外のものに更新します。

--ADD-ON USERS - TESTED ON POSTGRESQL
select * from cwd_user where lower_email_address like '%connect.atlassian.com%';

6. ファイアウォールの許可ルールを更新する 必須

移行アシスタントは移行を実行するためにアトラシアンのドメインに接続します。ファイアウォールまたはリバース プロキシによってドメインがブロックされると、移行は失敗します。

アトラシアンのドメインに接続できることの検証

移行前に、「アトラシアンのクラウド製品の IP 範囲とドメイン」に記載されているドメインがセキュリティ ルールでブロックされていないことを確認します。さらに、次のエンドポイントを許可します。

7. アプリの移行方法を決定する 必須

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 に公開プロジェクトがある場合、クラウドへの移行前にそれらの匿名アクセスのセットアップを削除します。これらのプロジェクトは移行後にいつでも公開できます。パブリック アクセス設定のチェックの詳細は、こちらをご覧ください。


SQL を使用した検証 (Postgres でテスト済み)

プロジェクト

これにより、プロジェクトの閲覧権限がすべてのユーザーに設定されているプロジェクトを見つけることができます。

// 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


フィルター

"全員で共有" 共有タイプ (グローバル) のフィルターの一覧を取得します。

// 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';


アジャイルボード

"全員で共有" 共有タイプ (グローバル) のアジャイル ボードの一覧を取得します。

// get list of Agile broads 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';


ダッシュボード

"全員で共有" 共有タイプ (グローバル) のダッシュボードの一覧を取得します。

// 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. サーバーのセットアップを確認する 必須

移行する課題またはプロジェクトの数によっては、Jira Server で OutOfMemory エラーが発し、移行全体がクラッシュします。これを防ぐため、Jira アプリケーションのメモリの容量を増やす」に記載されているパラメーターを確認して、アプリケーションが 4 GB 以上のヒープ割り当てで実行されていることを確認します

また、オープンなファイルの制限を確認します。理想的には、32768 に近ければ近いほど望ましいです。システムに設定されるオープンなファイルの数は、Linux ディストリビューションに応じて異なる場合があります。これをシステム コマンド経由で確認する方法が不明な場合、サポート Zip を作成し、application-properties/application.xml ファイルを開いて、<max-file-descriptor> を検索します。この数が 32768 に近い場合は、適宜調整します。詳細は、「Too many open files エラー」ドキュメントで確認できます。これは、Windows を実行している場合には適用されません。

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

Xmx および Xms の値が 4096m または 4g 以上であることを確認します。

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 に近いことを確認します

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 (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します

JVM_MINIMUM_MEMORY="4096m"
JVM_MAXIMUM_MEMORY="4096m"


Windows の場合 (サービスとして実行していない場合) 

 /jira-installation-directory/bin/setenv.bat ファイルに移動し、次の両方のパラメーターが 4096m または 4g (メガバイトではなくギガバイトで設定されている場合) を上回っていることを確認します。

JVM_MINIMUM_MEMORY="4096m"
JVM_MAXIMUM_MEMORY="4096m"


Windows の場合 (サービスとして実行している場合)

この記事の手順に従います。

10. サーバーのタイムゾーンを確認する (クラウド サイトを統合する場合)  必須

Jira Cloud サイトを統合するために移行アシスタントを使用している場合、課題のタイムスタンプのタイムゾーンがわずかに変わることがあります。Jira Cloud は UTC を使用します。Jira Server インスタンスがこれ以外のタイムゾーンを使用している場合、UTC との時差に基づいて時間が変更されます。

回避策として、こちらの記載に従い、Jira Server インスタンスの -Duser.timezone=UTC にシステム フラグを追加します。 

Jira Server の UI を使用した検証

サーバーのタイムゾーンを確認するには、次の手順を実行します。

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

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

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

  4. 最後に、jvm.system.timezone を見つけます。

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

サーバーのタイムゾーンを検証するには次のクエリを使用できます。

grep "<jvm.system.timezone>" <Support Zip Location>/application-properties/application.xml


Example Output: 
<jvm.system.timezone>America/New_York</jvm.system.timezone>

11. 共有されている構成名の重複を修正する 推奨

移行での競合を防ぐために、クラウド サイトの共有設定と同じ名前を持つ、サーバー インスタンスの共有設定 (ワークフローまたは権限スキーム) の名前を変更します。競合が見つかった場合、移行中に設定の名前が変更される場合があります

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

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

13. サーバー インスタンスの準備 推奨

サーバー データが正常に移行されるようデータベース整合性チェッカー (Jira Server のネイティブ機能) と Atlassian Marketplace の Integrity Check for Jira アプリを使用して、データのステータスを確認します。

他のチェックおよび実行すべきアクションは次のとおりです。

  • すべての必須フィールドが値を持ち、null が使用されていないこと

  • 移行したいアーカイブ済みのプロジェクトを再有効化していること

  • 移行した非アクティブなユーザー ディレクトリを再有効化していること

データのクリーン アップの詳細については、「移行前のサーバー インスタンスのクリーン アップ」を参照してください。

14. クラウド サイトの準備 推奨

クラウド サイトのセットアップ時には次の点を考慮します。

  • クラウド サイトでは、サーバー サイトと同じ Jira 製品が有効化されている必要があります (Jira Service Management を除く)。たとえば、サーバー サイトに Jira Core と Jira Software がある場合、Jira Core プロジェクトを移行しない場合でもクラウド サイト上で両方が必要になります。これは、すべてのユーザーとグループを正常に移行するためです。移行後にこれらの製品を使用したくない場合、関連製品の無料トライアルをセットアップしてから移行後にそれらを無効化します。

  • クラウド サイトの言語が、サーバー サイトの言語と同じであることを確認します。言語が異なる場合、一部のフィールドが適切に移行されない場合があります。

  • Atlassian Access を使用する場合、移行前にそれをセットアップする必要があります。

15. データのバックアップを作成する 推奨

移行を実行する前に、現在の Jira Server サイトをバックアップすることをおすすめします。移行先の Cloud サイトに既存のデータがある場合、同様に Jira Cloud サイトもバックアップします。

16. テスト移行を実行する 推奨

テスト移行を行ってから本番環境への移行を行うことを強く推奨します移行テストのガイダンスをご参照ください。

17. 移行プランをサポートに共有する 推奨

週末や祝日に移行を行う場合、またはクラウド上のユーザーが 1,000 人以上になる場合は、2 週間以上前に移行サポート チームにお知らせください。弊社で人員を用意し、移行を支援いたします。 

アトラシアンでのクラウドへの移行のサポートについてご確認ください

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

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

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

レポートの不一致の可能性

JSWSERVER-14984 - 課題情報を取得中... ステータスによって、Jira の 8.11/8.13.15 より前のバージョンでは Server と Cloud 間でレポートに不一致が生じる可能性があります。これは、Server が一部のスプリントをレンダリングしない不具合があるためです。

Jira Server の UI を使用した検証
  1. アプリケーションの右上にある歯車アイコンをクリックします。

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

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

  4. 最後に、Jira のバージョンを確認します

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

製品バージョンの検証

grep "<product name" <Support Zip Location>/application-properties/application.xml
 
 
Example Output:
<product name="Jira" version="8.7.1"/>
XML バックアップ ファイルを使用して検証

Jira Server のビルドとバージョンを使用して、ビルド番号を Jira バージョンに照合できます。

製品バージョンの検証

grep 'Build #' <Backup File Location>/entities.xml
 
 
Example Output:
Build #                                       : 100118

2. XML ファイルが有効であることを確認する 必須

entities.xml と activeobjects.xml の両方が有効な XML ファイルであることを確認します。複雑な環境を持つ大規模なお客様の環境からのエクスポートでは、XML 構造が無効になる場合があります。

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

次のクエリを使用して、ファイルが有効であるかどうかを確認します。

xmllint --noout <Backup File Location>/entities.xml
xmllint --noout <Backup File Location>/activeobjects.xml                                      : 100118

コマンドで出力が返されない場合、ファイルは有効です。例外が発生した場合、フォーマット エラーのある箇所が示されます。

3. XML ファイルの構造を確認する 必須

バックアップ ファイルがインポート用に適切に構築されていることを確認します。大きなインスタンスの場合、クラウドのバックアップ ファイルを、activeobjects.xml および entities.xml を含むデータベース ファイルと、添付ファイルやその他のメディアを含むファイルに分割することをおすすめします。これによってタイムアウト エラーを防いだり、インポート時の問題のリスクを軽減したりすることができます。

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

メディアや他の添付ファイルからデータを分離するかどうかに応じ、階層が次の関連する形式に一致するかどうかを確認します。

添付ファイルとデータ

JIRA-backup-XXXXXX
├── activeobjects.xml
├── entities.xml
├── data
│   ├── attachments
│   └── avatars
└── logos

添付ファイルと他のメディアのみ

media-only-X.zip
└─── data
      ├── attachments
      │         ├── ProjectKey
      │         │         └── 10000
      │         │		    ├── IssueKey-1
      │         │		    ├── IssueKey-2
      │         │       	└── IssueKey-3
      │         └─── ProjectKey2
      └── avatars


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

Jira Server に、アップグレードに失敗したタスク、またはアップグレードが保留中となっているタスクがある場合、クラウドへのインポートが失敗することがあります。 

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

クラウドへのインポートを試みる前に、以下を実行してアップグレードに失敗したタスクを特定します。

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"

任意のアップグレード タスクが "failed" を返す場合、回避策として、それらを "complete" に更新するか、失敗したアップグレード タスクをまとめて削除します。要素を削除する際には、結果となる XML 構造が有効であることを確認します。

変更を加えたら、ファイルを保存して再度圧縮し、元のバックアップ ファイルと同じファイル構造を保持するようにします。

5. 重複しているユーザー メールや無効なユーザー メールを確認する 必須

インポートに失敗する最も一般的な理由の 1 つは、メールの重複や無効なメールです。インポート チェックでは重複しているメールや無効なメールが確認されますが、これにより、時間がかかるインポートまたはアップロードに失敗したり、大規模なお客様の場合はメンテナンス時間がかかったりする場合があります。ベスト プラクティスは、このようなメール アドレスを事前に確認することです。

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

重複ユーザー

以下を実行して、重複メールを特定します (メールの左側に 1 より大きい数が表示される)。

grep 'lowerEmailAddress="'<Backup File Location>/entities.xml | awk -F\lowerEmailAddress=\" '{print $2}' | cut -d\" -f1 | sort | uniq -c

Example Output:
   1 felix.test@test.com
   2 fixed.test@test.com
   1 florian.test@test.com

重複が見つかった場合、ソース インスタンスでそれらを修正するか entities.xml を編集して一意にします。


さらに、アドオン ユーザーが存在する場合、移行時に問題が発生する可能性があります。クラウドにインポートする前にアドオン ユーザーをクリーン アップすることで、この問題を回避できます。

SQL を使用した検証 (Postgres でテスト済み)

アドオン ユーザー

次のクエリを使用してこのような条件を満たすユーザーを見つけ、ソースでメールを削除または更新し、@connect.atlassian.com 以外が設定されるようにします。

--ADD-ON USERS - TESTED ON POSTGRESQL
select * from cwd_user where lower_email_address like 'connect.atlassian.com';

6. テスト中にクラウドで受信メール ハンドラーを無効にする必須

既定では、受信メール ハンドラーはインポート後にオンになります。これによって、クラウドのメール ハンドラーがサーバーのメール ハンドラーの代わりにメールを処理する可能性があります。メールが誤って処理されないように、テスト中はこれらの機能をオフにすることを強くお勧めします。

以下を実行できます。

  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 バックアップ ファイルを使用して検証

ワークフローの重複

次のクエリを使用して、ワークフローのすべての名前が一意であることを確認します

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 でテスト済み)

クラスタ ジョブの重複を見つける

次のクエリを使用して、重複しているクラスタ ジョブを見つけます。

SELECT * FROM clusteredjob 
WHERE job_id in 
(SELECT job_id FROM clusteredjob GROUP BY job_id HAVING COUNT(*)>1)

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

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

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

    delete from clusteredjob where id =XXXXX;
  3. Jira を再起動する

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

最初に、次のクエリを実行します。

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 文字を超える添付ファイルを識別します。

SELECT id,issueid, char_length(filename)
FROM fileattachment
WHERE char_length(filename) > 250
XML バックアップ ファイルを使用して検証

次のコマンドで、250 文字を超えるファイル名が返されないことを確認します0 と表示されるはずです。

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 で公開されているプロジェクトのプロジェクト権限を確認し、クラウドへの移行前にそれらの匿名アクセスのセットアップを削除します。

SQL を使用した検証 (Postgres でテスト済み)

プロジェクト

これにより、プロジェクトの閲覧権限がすべてのユーザーに設定されているプロジェクトを見つけることができます。

// 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


フィルター

"全員で共有" 共有タイプ (グローバル) のフィルターの一覧を取得します。

// 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';


アジャイルボード

"全員で共有" 共有タイプ (グローバル) のアジャイル ボードの一覧を取得します。

// get list of Agile broads 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';


ダッシュボード

"全員で共有" 共有タイプ (グローバル) のダッシュボードの一覧を取得します。

// 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. クラウド ユーザーの上限を超えていないことを確認する 必須

サーバーから移行するユーザーの合計数に、クラウド内に既に存在するユーザーの数を加えた数が、サブスクリプションのユーザー階層を超えないようにします。たとえば、51 ~ 100 のユーザー サブスクリプションをお持ちの場合、110 人のアクティブ ユーザーをインポートしようとすると、移行は失敗します。 

解決するには、次のいずれかを実行してください。

SQL を使用した検証 (Postgres でテスト済み)

Jira サーバーでライセンスを保有しているユーザーの一覧の取得」ガイドで参照されているクエリを使用して、ライセンスを保有しているユーザーの数を取得します。

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

移行を実行する前に以下のクエリを使用して、移行するユーザーの数がクラウド プランのユーザー制限以下であることを検証します。必要に応じて、ユーザーの数を減らすか、クラウド プランをアップグレードするか、サブスクリプションにユーザーを追加します。

grep "<Users>" <Support Zip Location>/application-properties/application.xml

Example Output:
<Users>2205</Users>


13. サーバーのタイムゾーンを確認する 必須

Jira Site Import を使用している場合、日付のタイムスタンプのタイムゾーンがわずかにずれている可能性があります。Jira Cloud はタイムゾーンに UTC (協定世界時) を使用します。Jira Server インスタンスがこれ以外のタイムゾーンを使用している場合、UTC との時差に基づいて時間が変更されます。

回避策として、こちらの記載に従い、Jira Server インスタンスの -Duser.timezone=UTC にシステム フラグを追加します。 

Jira Server の UI を使用した検証

サーバーのタイムゾーンを確認するには、次の手順を実行します。

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

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

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

  4. 最後に、jvm.system.timezone を見つけます。

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

サーバーのタイムゾーンを検証するには次のクエリを使用できます。

grep "<jvm.system.timezone>" <Support Zip Location>/application-properties/application.xml


Example Output: 
<jvm.system.timezone>America/New_York</jvm.system.timezone>

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

Jira Cloud へのインポートに多数の添付ファイル (未圧縮で 20+ GB) が含まれる場合、遅延やタイムアウトが発生する可能性があります。データベース バックアップ (entities.xml および activeobjects.xml ファイル) をインポートしてからメディア (添付ファイル、プロジェクト アバター、およびロゴ) を個別にインポートすることをおすすめします。

SQL を使用した検証 (Postgres でテスト済み)

次の 1 つめのクエリは、データベースの添付ファイルの全体的なサイズを識別しますさらに評価する必要がある場合、2 番目のクエリでプロジェクトごとにそれらをブレイクダウンします

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;

15. 孤立データを確認する 推奨

バックアップに孤立データがある場合、それらがクラウド内で適切に処理されず、インポートに失敗することがあります。一般的なシナリオとして、null プロジェクト キーがあります

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

次のコマンドを使用して、一部の孤立データの特定を試みます。

出力に空白行がある場合、null のプロジェクト キーが存在する可能性があります。key 値が空にならないようにこれを修正する必要があります。クラウドにインポートする前に entities.xml で修正を行います。

XML の有効性の検証

xmlstarlet sel -t -v "/entity-engine-xml/Project/@key"  -n <Backup File Location>/entities.xml 


Example Output:
SER

SKP
TEST

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

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

17. データのバックアップを作成する 推奨

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

18. テスト移行を実行する 推奨

テスト移行を行ってから本番環境への移行を行うことを強く推奨します移行テストのガイダンスをご参照ください。

19. 移行プランをサポートに共有する 推奨

週末や祝日に移行を行う場合、またはクラウド上のユーザーが 1,000 人以上になる場合は、2 週間以上前に移行サポート チームにお知らせください。弊社で人員を用意し、移行を支援いたします。 

アトラシアンでのクラウドへの移行のサポートについてご確認ください

詳細情報とサポート

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


最終更新日 2022 年 4 月 14 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.