Server から Cloud への移行を計画する
Atlassian Server 製品の移行準備に役立つドキュメント。
移行は、複雑で困難なプロセスになることがあります。
アトラシアンではお客様をサポートするために、データを Jira Server または Data Center からクラウドに移行する準備が整っていることを確認するために必要なすべてを示したチェックリストを作成しました。
一般的なエラーを防ぐため、移行を試す前に次の確認を完了します。
確認する内容は、利用する移行方法によって異なります。このチェックリストでは、次の方法を網羅しています。
次に、選択した移行メソッドに対応した移行前のチェックに従います。
移行前のチェックを完了するには、以下へのアクセス権が必要な場合があります。
Jira Server または Cloud のユーザー インターフェイス
展開されていない Jira サポート Zip
展開されていない Jira XML バックアップ
ソース インスタンスでの SQL クエリの実行
Jira Cloud Migration Assistant は、データに一般的なエラーがないかどうかを自動的に確認します。次の点が確認されます。
すべてのユーザーに有効で一意のメール アドレスが紐付けられているかどうか
プロジェクト名またはキーがクラウドのプロジェクト名またはキーと競合していないこと
移行アシスタントが最新かどうか
ただし、移行アシスタントはすべてを確認するわけではありません。このため、移行を開始する前に次のリストを使用したチェックを行う必要があります。
アクティブな外部ユーザー ベースを同期して、ユーザー移行戦略の一環としてすべてのユーザーやグループが適切に移行されていることを確認します。また、これによって、移行中にデータが適切なユーザーに引き続きリンクされるようにします。
外部プロバイダを使用してユーザーを管理している場合、移行前に、それらのユーザーがアクティブで、内部ユーザー ベースと同期されていることを確認します。
アプリケーションの右上にある歯車アイコンをクリックします。
[ユーザー管理] を選択します。
[ユーザー ディレクトリ] を選択します。
最後に、[同期] を選択します。
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: true
Jira Cloud Migration Assistant は次を移行します。
すべてのユーザーまたはグループ
選択したプロジェクトに関連するユーザーとグループ
Jira がサポート対象バージョンであることを確認します。サポート対象のバージョンではない場合、移行アシスタントは機能しません。
アプリケーションの右上にある歯車アイコンをクリックします。
[システム] を選択します
左側のナビゲーション パネルにある [システム情報] を選択します
最後に、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 Cloud でサポートされていないため、これらのユーザーは Jira Cloud Migration Assistant では移行できません。エラーを回避するには、移行前にメール アドレスの重複を見つけて修正する必要があります。ユーザー情報が LDAP サーバーで管理されている場合は、移行前にそこでメールを更新して Jira と同期する必要があります。ユーザー情報をローカルで管理している場合は、Jira Server または Data Center の UI でそれらを修正できます。
次のクエリを使用して、重複しているメール アドレス (存在する場合)、これらのアドレスの重複回数、そのメール アドレスに割り当てられたユーザーを見つけられます。
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;
移行を実行するユーザーが、次の権限を持っていることを確認します。
Server インスタンスのシステム管理者グローバル権限を持っていること
宛先のクラウド サイトに存在すること
クラウドのサイト管理者権限を持っていること
移行するすべてのプロジェクトの課題の作成権限を持っていること
クラウド サイトのグループの名前がサーバー サイトのグループと異なることを確認します (意図的に統合しようとしている場合を除く)。「移行アシスタントがグループ名の競合を処理する方法」についてご確認ください。
一部の移行シナリオでは、Server サイトにアドオン ユーザーが発生する場合があります。Server の世界においてアドオン ユーザーは一般的ではないため、クラウドに戻す移行の際にいくつかの問題が発生する可能性があります。移行前に、これらのアドオン ユーザーを削除または更新します。
次のクエリを使用してこれらのユーザーを見つけ、削除するかメール アドレスを @connect.atlassian.com 以外のものに更新します。
1
2
--ADD-ON USERS - TESTED ON POSTGRESQL
select * from cwd_user where lower_email_address like '%connect.atlassian.com%';
移行アシスタントは移行を実行するためにアトラシアンのドメインに接続します。ファイアウォールまたはリバース プロキシによってドメインがブロックされると、移行は失敗します。
移行前に、「アトラシアンのクラウド製品の IP 範囲とドメイン」に記載されているドメインがセキュリティ ルールでブロックされていないことを確認します。さらに、次のエンドポイントを許可します。
https://api.media.atlassian.com: 添付ファイルのアップロードを有効にします
https://api-private.atlassian.com: Atlassian Migration Platform との通信を有効にします
https://marketplace.atlassian.com: 移行アシスタントが最新であることを確認できるようにします
https://api.atlassian.com: Atlassian App Migration Platform との通信を有効にします
https://*s3.us-west-2.amazonaws.com: 移行データのアップロードを有効にする
https://rps--prod-east--app-migration-service--ams.s3.amazonaws.com: アプリ移行データのアップロードを有効にする
[宛先のクラウド サイト]: 宛先のクラウド サイトとの通信を有効にします
Jira Cloud Migration Assistant によってアプリ データを移行できます。移行するアプリの Marketplace パートナー (アプリ ベンダー) に連絡して、構築した移行パスが Jira Cloud Migration Assistant をサポートしているかどうかを確認したうえで、データの効率的な移行方法についてアドバイスを求めましょう。これには、Portfolio for Jira などのアトラシアン製アプリが含まれます。Portfolio for Jira を移行する必要がある場合は、関連する機能リクエストをウォッチすると最新情報を受け取れます。
Jira Cloud では Portfolio はスタンドアロン アプリとして提供されていませんが、Jira Software Cloud Premium の Advanced Roadmaps として機能を利用できます。
Jira Server または Jira Cloud サイトをインターネットに公開するように設定できます。コンテンツを意図的に公開する場合を除いて、プロジェクト権限を確認する必要があります。Jira Server に公開しているプロジェクトがある場合は、クラウドに移行前にそれらの匿名アクセスのセットアップを削除します。これらのプロジェクトは移行後にいつでも公開できます。公開アクセス設定のチェックに関する詳細についてご確認ください。
プロジェクト
これにより、プロジェクトの閲覧権限がすべてのユーザーに設定されているプロジェクトを見つけることができます。
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;
移行する課題またはプロジェクトの量によっては、移行全体のクラッシュの原因になる可能性がある OutOfMemory エラーが Jira Server で発生する場合があります。これを防ぐためには「Jira アプリケーション メモリの容量を増やす」に記載されているパラメーターを確認して、アプリが 4GB 以上のヒープ割り当てで実行されていることをご確認ください。
また、オープンなファイルの制限を確認します。32768 になるべく近い数が理想的です。システムに設定されるオープンなファイルの数は、Linux ディストリビューションに応じて異なる場合があります。これをシステム コマンド経由で確認する方法が不明な場合は、サポート Zip を作成して application-properties/application.xml ファイルを開き、<max-file-descriptor> を検索します。この数が 32768 に近い場合は、必要に応じて調整します。詳細については、「Too many open files エラー」ドキュメントでご確認ください。これは、Windows を実行している場合には適用されません。
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 Cloud サイトを統合するために移行アシスタントを使用している場合、課題のタイムスタンプのタイムゾーンがわずかに変わることがあります。Jira Cloud は UTC を使用します。Jira Server インスタンスがこれ以外のタイムゾーンを使用している場合、UTC との時差に基づいて時間が変更されます。
回避策は、Jira Server インスタンスの -Duser.timezone=UTC にシステム フラグを追加することです。これについては、タイムゾーンの詳細を含むようにドキュメントを更新する方法を説明したこの記事で概説しています。
サーバーのタイムゾーンを確認するには、次の手順を実行します。
アプリケーションの右上にある歯車アイコンをクリックします。
[システム] を選択します
左側のナビゲーション パネルにある [システム情報] を選択します
最後に、jvm.system.timezone を見つけます。
また、次のクエリで 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>
移行の競合を防ぐために、Cloud サイトの共有設定と同名の Server インスタンスの共有設定 (ワークフローまたは権限スキーム) の名前を変更します。競合が見つかった場合は、移行中に設定の名前が変更されることがあります。
アトラシアンの Cloud プランには個別のストレージ制限があります。移行前に、現在使用しているディスク領域と、アトラシアンの Cloud ストレージのドキュメントをご確認ください。
Server データが正常に移行されるように、データベース整合性チェッカー (Jira Server のネイティブ機能) と Atlassian Marketplace の Integrity Check for Jira アプリによって、データのステータスを確認します。
他のチェックおよび実行すべきアクションは次のとおりです。
すべての必須フィールドが値を持ち、null が使用されていないこと
移行したいアーカイブ済みのプロジェクトを再有効化していること
移行した非アクティブなユーザー ディレクトリを再有効化していること
データのクリーン アップに関する詳細については「移行前のサーバー インスタンスのクリーン アップ」をご確認ください。
Cloud サイトのセットアップ時は、次の点を考慮する必要があります。
Cloud サイトでは、Server サイトと同じ Jira 製品が有効化されている必要があります (Jira Service Management (旧 Jira Service Desk) を除く)。たとえば、Server サイトに Jira Core と Jira Software がある場合は、Jira Core プロジェクトを移行していない場合でも Cloud サイト上で両方が必要になります。これは、すべてのユーザーとグループを正常に移行するためです。移行後にこれらの製品を使用しない場合は、関連製品の無料トライアルをセットアップしてから移行後にそれらを無効化します。
Cloud サイトの言語が、Server サイトの言語と同じであることを確認します。言語が異なる場合は、一部のフィールドが適切に移行されない場合があります。
Atlassian Access を使用している場合は、移行前にユーザー移行戦略を決定して Access をセットアップする必要があります。
移行を実行する前に、現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある場合は、同様に Jira Cloud サイトもバックアップします。
テスト移行を行ってから本番環境への移行を行うことを強く推奨します。移行テストのガイダンスをご参照ください。
移行を実施するユーザーが 1,000 人を超える場合は、少なくとも 2 か月前までに移行サポート チームまでお問い合わせください。アトラシアンで人員を確保したうえで、移行をサポートします。
クラウド移行のサポート方法に関する詳細についてご確認ください。
サイト インポートは、Server から Cloudへの移行では利用できなくなります。
2022年05月 1日 より、1 ~ 1000 名のユーザーを移行する場合に、サイト インポートを使用した Server から Cloud への移行ができなくなりました。1000 人を超えるユーザーの移行を検討している場合、サイト インポートは追って連絡があるまで引き続きご利用になれます。
Jira Server または Data Center ライセンスのあるユーザー数を表示するには、「Jira アプリケーションのライセンス」ページの「ライセンス認可済みのユーザー数を表示する」セクションをご覧ください。
すべての移行ニーズには、Jira Cloud Migration Assistant を使用することをお勧めします。アプリ、Jira Service Management、Advanced Roadmaps の移行など、この移行アシスタントにはいくつものメリットがあります。
このお知らせの詳細については、コミュニティ投稿をご覧ください。この変更に関する技術的または互換性に関する懸念については、お問い合わせください。
インポートが機能するには、バックアップの XML ファイルがサポート対象のバージョンの Jira Server または Data Center から取得されたものである必要があります。
レポートの不一致の可能性
JSWSERVER-14984 によって Server が一部のスプリントを誤ってレンダリングしないため、8.11/8.13.15 より前の Jira バージョンでは Server と Cloud 間でレポートの不一致が生じる可能性があります。
アプリケーションの右上にある歯車アイコンをクリックします。
[システム] を選択します
左側のナビゲーション パネルにある [システム情報] を選択します
最後に、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 Server のビルドとバージョンを使用して、ビルド番号を Jira バージョンに照合できます。
製品バージョンの検証
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 を含むデータベース ファイルと、添付ファイルやその他のメディアを含むファイルに分割することをお勧めします。
これによってタイムアウト エラーを防いだり、インポート時の問題のリスクを軽減したりすることができます。
.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 へのインポートが失敗することがあります。
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 を再起動する
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 を編集して一意にします。
バックアップに 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 人のアクティブなユーザーをインポートしようとすると、移行は失敗します。
これを解決するには、次のいずれかの方法に従ってください:
ユーザー数の上限が大きいプランをサブスクライブする
移行前にユーザーの数を減らす
アトラシアン サポートに問い合わせて、移行前に製品へのアクセス権がないユーザーをインポートする
「Jira Server のライセンス付与済みユーザーのリストを取得する」ガイドで紹介されているクエリによって、ライセンス付与済みユーザーの数を取得します。
移行を実行する前に次のクエリによって、移行するユーザーの数とご利用の Cloud プランのユーザーの上限を検証します。必要に応じて、ユーザー数を削減、Cloud プランをアップグレード、またはサブスクリプションへのユーザー数を追加します。
1
2
3
4
grep "<Users>" <Support Zip Location>/application-properties/application.xml
Example Output:
<Users>2205</Users>
Jira Site Import を使用している場合、日付のタイムスタンプのタイムゾーンがわずかにずれている可能性があります。Jira Cloud はタイムゾーンに UTC (協定世界時) を使用します。Jira Server インスタンスがこれ以外のタイムゾーンを使用している場合、UTC との時差に基づいて時間が変更されます。
回避策として、こちらの記載に従い、Jira Server インスタンスの -Duser.timezone=UTC にシステム フラグを追加します。
サーバーのタイムゾーンを確認するには、次の手順を実行します。
アプリケーションの右上にある歯車アイコンをクリックします。
[システム] を選択します
左側のナビゲーション パネルにある [システム情報] を選択します
最後に、jvm.system.timezone を見つけます。
サーバーのタイムゾーンを検証するには次のクエリを使用できます。
1
2
3
4
grep "<jvm.system.timezone>" <Support Zip Location>/application-properties/application.xml
Example Output:
<jvm.system.timezone>America/New_York</jvm.system.timezone>
Jira Cloud へのインポートに多数の添付ファイル (未圧縮で 20+ GB) が含まれる場合、遅延やタイムアウトが発生する可能性があります。データベース バックアップ (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;
バックアップに孤立データがある場合は、それらが Cloud で適切に処理されずにインポートが失敗することがあります。一般的なシナリオとして、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 ストレージのドキュメントをご確認ください。
移行や本ガイドで推奨されているいずれかの更新を実行する前に、復元ポイントを確保できるように現在の Jira Server サイトをバックアップすることをお勧めします。移行先の Cloud サイトに既存のデータがある際は、移行後に何らかの理由で変更を元に戻す必要が発生した場合に備えて、同様に Jira Cloud サイトもバックアップします。これはベスト プラクティスであり、メンテナンスを元に戻す必要が発生した場合に備えて復元ポイントを追加します。
テスト移行を行ってから本番環境への移行を行うことを強く推奨します。移行テストのガイダンスをご参照ください。
移行を実施するユーザーが 1,000 人を超える場合は、少なくとも 2 か月前までに移行サポート チームまでお問い合わせください。アトラシアンで人員を確保したうえで、移行をサポートします。
クラウド移行のサポート方法に関する詳細についてご確認ください。
移行をサポートするための多数のチャネルをご用意しています。
移行計画の詳細については、Atlassian Migration Program の Web サイトをご参照ください。
技術的な問題が発生している、または戦略やベスト プラクティスに関するサポートが必要な場合は、サポート チームにお問い合わせください。
専門的なアドバイスについては「アトラシアン コミュニティ」をご参照ください。
専門家によるサポートが必要な場合は、アトラシアン パートナーにご相談ください。
この内容はお役に立ちましたか?