移行前のインスタンスのクリーンアップ

クラウド移行は、Server または Data Center 内のデータをクリーンアップして Cloud 内でよりクリーンな状態に移行する良い機会です。移行するデータが多くなるほど、移行に要する時間が長くなってより複雑になる可能性が高くなります。テスト移行を実行する前にインスタンスをクリーンアップすると、移行がスムーズになってパフォーマンスの問題が減少し、Cloud における生産性が向上します。 

移行の実行中にはインスタンスをクリーンアップしない

Server または Data Center のデータをクリーンアップする最適なタイミングは、移行を実行する前です。移行の実行中にデータをクリーンアップすると、移行が失敗する可能性があります。

Jira インスタンスをクリーン アップする

変更をテストしてバックアップを作成してください

これらのクリーンアップ操作の中には、Jira のエンティティやインスタンス全般に影響するものがあります。最初にステージング環境で変更をテストしてください。適用する前に、本番インスタンスのバックアップも必ず作成してください。

Jira データをレビューする

  • 重複するメール アドレスを確認して修正します。Jira Cloud では重複したメール アドレスはサポート対象外なので、これは必須の準備手順です。

  • Server/Data Center と Cloud でグループ名の競合を確認して修正します。同名のグループは Jira Cloud にマージされるため、これは必須の準備手順です。

  • 未使用のアプリまたはトライアル データを確認および削除します。

  • 移行するプロジェクトのリストを作成して、移行前に不要なプロジェクトを削除します。

  • データ量 (たとえば、プロジェクトまたはカスタム フィールドの数) を確認し、そのサイズまたは複雑さを削減することを検討します。このデータは、[管理] > [システム] > [システム情報] で確認できます。データには、次の項目が含まれる可能性があります。

    • プロジェクトの数

    • カスタム フィールドの数

    • ワークフローの数

    • 画面の数、課題タイプ、権限スキーム

    • ユーザーの数

    • 非アクティブなユーザーの数

  • Optimizer for Jira など、現在の使用状況を把握してシステムをクリーンアップするのに役立つ Marketplace アプリを使用します。

  • データベース整合性チェッカー (Jira Server に標準搭載) または Jira Marketplace アプリの整合性チェックによって、データの状態をチェックします。

すべてのデータを削除して、設定と空のプロジェクト コンテナーのみを移行することを選択するお客様もいます。これは、Cloud で新規に開始する予定があって Server の設定を維持したい場合に適したオプションとなる場合があります。Jira インスタンスのクリーン アップについて詳細をご確認ください

データベースを最適化する

テーブル、インデックス、または統計をクリーンアップする組み込み機能を使用して、データベースを最適化します。以下に、最も一般的なデータベースのコマンドと最大の Jira テーブルを示します。

PostgreSQL

1 2 3 4 5 6 vacuum full jiraissue; vacuum full jiraaction; vacuum full changegroup; vacuum full changeitem; vacuum full worklog; vacuum full customfieldvalue;

PostgreSQL ドキュメント

MySQL

1 2 3 4 5 6 optimize table jiraissue; optimize table jiraaction; optimize table changegroup; optimize table changeitem; optimize table worklog; optimize table customfieldvalue;

MySQL ドキュメント

Microsoft SQL Server

1 2 3 4 5 6 update statistics jiraissue; update statistics jiraaction; update statistics changegroup; update statistics changeitem; update statistics worklog; update statistics customfieldvalue;

Microsoft SQL Server ドキュメント

ORACLE

1 2 3 4 5 6 analyze table jiraissue compute statistics; analyze table jiraaction compute statistics; analyze table changegroup compute statistics; analyze table changeitem compute statistics; analyze table worklog compute statistics; analyze table customfieldvalue compute statistics;

Oracle ドキュメント

機能の一部は自動的に実行され (自動 vacuum など)、パフォーマンスをすでに最適化しています。移行中に行われる大規模なデータベース操作では、これらを手動で実行することでもメリットがもたらされます。

Jira データのカスタマイズを最小限に抑える

  • カスタム ワークフローを標準化して、移行前にデータの複雑さを軽減します。

  • グループと権限スキームを確認して、不要なものがあるか、使用しているものを標準化または単純化できる機会があるかどうかを検討します。 

  • カスタム フィールド、スキーム、課題タイプ、ステータス、解決状況、ボード、フィルター、画面を合理化します。インスタンスのクリーンアップに役立つ Jira クエリの一部を以下に示します。

これらはサンプル クエリであり、独自の環境で追加の調整やテストが必要になる場合があります。追加サポートについては、組織のデータベース管理者にお問い合わせください。これらのクエリの中には、何百万もの行を含む大規模なインスタンスで行う、実行に長時間を要するクエリがある場合があります。これらは慎重に行う必要があるため、まずはテスト環境で実行することを推奨します。

使用されていないカスタム フィールド

1 2 3 4 5 select customfield.id from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield where customfieldvalue.stringvalue is null and customfieldvalue.numbervalue is null and customfieldvalue.textvalue is null order by customfield.id

ほとんど使用されていないカスタム フィールド

1 2 3 4 select customfield.id, count (*) from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield group by customfield.id having count (*) < 5 order by count (*) desc

日付 (YYYY-MM-DD) より後に更新されていないカスタム フィールドを一覧表示します

1 2 3 4 5 6 7 select field.id, field.cfname from customfield field where field.cfname not in ( select item.field from changeitem item JOIN changegroup cgroup ON item.groupid=cgroup.id where item.fieldtype='custom' and cgroup.created > 'YYYY-MM-DD' ) and customfieldtypekey not like '%com.pyxis.greenhopper%' and customfieldtypekey not like '%com.atlassian.servicedesk%' and customfieldtypekey not like '%com.atlassian.bonfire%'

カスタム フィールドに関連するユーザー アクティビティ (完全なカスタム フィールド IDを使用。例: customfield_10301)

1 2 3 4 select id, entitytype, entityid, username, to_timestamp(lastviewed/1000) as lastviewed, data from userhistoryitem where entityid='customfield_10001' order by lastviewed desc;

すべての選択リスト カスタム フィールドを一覧表示します

1 2 select * from customfield where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select';

オプションと一緒にすべてのカスタム フィールドを一覧表示します

1 2 3 4 select cf.id, cf.customfieldtypekey, cf.cfname, cfo.sequence, cfo.customvalue from customfield cf join customfieldoption cfo on cfo.customfield = cf.id where customfieldtypekey = 'com.atlassian.jira.plugin.system.customfieldtypes:select' order by cfo.id, cfo.sequence;

「カスタム フィールド名」またはカスタム フィールド ID「10001」を含むフィルター

1 select * from searchrequest where reqcontent like '%Field Name%' or reqcontent like '%10001%';

カスタム フィールドを参照するワークフロー

1 select * from jiraworkflows wf where wf.descriptor like '%customfield_10281%';

グローバル コンテキストを持つフィールド

1 2 3 4 5 6 7 8 9 10 11 12 13 14 SELECT distinct(p.pkey), cfname, cf.id, p.pname FROM CUSTOMFIELDVALUE cfv left join JIRAISSUE ji on cfv.ISSUE = ji.id right join CUSTOMFIELD cf on cf.id = cfv.customfield left join project p on p.id = ji.project WHERE cf.id in (''' + globalContextIdsCommaSeparated+ ''') GROUP BY cf.id,cf.cfname,p.pkey, p.pname ORDER BY cf.cfname,p.pname

スクリーン/ワークフロー/通知スキームを持たない、コンテキストを持つ計算対象外のフィールド (値なし)

1 2 3 4 5 6 7 8 9 10 11 12 SELECT cf.id id, to_char(min(ji.created), 'YYYY/MM/DD'), to_char(max(ji.updated), 'YYYY/MM/DD'), count(distinct(ji.id)) FROM CUSTOMFIELDVALUE cfv left join JIRAISSUE ji on cfv.ISSUE = ji.id left join CUSTOMFIELD cf on cf.id = cfv.customfield GROUP BY cf.id ORDER BY cf.id

スクリーン/ワークフロー/通知スキームを持たず、コンテキストを持つ計算対象外のフィールドで、画面に関連づけられているもの

1 2 3 4 5 6 7 8 9 10 11 12 SELECT cf.id id, to_char(min(ji.created), 'YYYY/MM/DD'), to_char(max(ji.updated), 'YYYY/MM/DD'), count(distinct(ji.id)) FROM CUSTOMFIELDVALUE cfv left join JIRAISSUE ji on cfv.ISSUE = ji.id left join CUSTOMFIELD cf on cf.id = cfv.customfield GROUP BY cf.id ORDER BY cf.id

カスタム フィールドの誤使用の監査

これは、カスタム フィールドの使用方法の抽出を支援するための潜在的なクエリです。これにより、代替目的で使用されている、または単に誤用されているフィールドを特定できます。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 select customfield.id, customfield.cfname, customfield.description, customfieldvalue.stringvalue, customfieldvalue.numbervalue, customfieldvalue.textvalue, customfieldvalue.datevalue from customfield left join customfieldvalue on customfield.id = customfieldvalue.customfield where customfieldvalue.stringvalue is not null or customfieldvalue.numbervalue is not null or customfieldvalue.textvalue is not null or customfieldvalue.datevalue is not null group by customfield.id, customfield.cfname, customfield.description;

カスタム フィールドを削除すると、関連するデータも削除される場合があります。

課題タイプ、ワークフロー、カスタム フィールド、スキームなどの共有構成エンティティを共有する追加のプロジェクトを後で移行する場合は、Server インスタンスからこれらのエンティティを更新または削除する際にご注意ください。

Jira Cloud Migration Assistant を使用する

Jira Cloud Migration Assistant は、不要なデータを Cloud に残しておくのに役立ちます。次のような移行前の工夫を施すことができます。

  • プロジェクト選択画面で「最終更新日」でプロジェクトを並べ替えます。これによって、他のプロジェクトよりも先に移行するプロジェクトに集中しやすくなります。

  • アーカイブされたプロジェクトの移行を、移行の前後に別途行うことで、現在のユーザーにとって重要なアクティブ プロジェクトの移行ダウンタイムが増加することを防げます。

  • 移行前のレポートを生成してデータを確認する。

Jira Cloud Migration Assistant は、Jira Server または Data Center インスタンスのすべての設定を Cloud に移行するわけではありません。選択したプロジェクトに必要な情報を分析して、これらのプロジェクトが Cloud で引き続き機能するために必要なデータのみを移行します。つまり、選択したプロジェクトで未使用のワークフロー スキーム、権限スキーム、カスタム フィールドなど、マッピングされていないまたは未使用の各設定は Cloud に移行されません。Jira Cloud Migration Assistant の詳細をご確認ください。

Confluence インスタンスをクリーン アップする

変更をテストしてバックアップを作成してください

これらのクリーンアップ操作の中には、Confluence 内のエンティティやインスタンス全般に影響するものがあります。最初にステージング環境で変更をテストしてください。適用する前に、本番インスタンスのバックアップも必ず作成してください。

Confluence データをレビューする

  • 重複するメール アドレスを確認して修正します。Confluence Cloud では重複したメール アドレスはサポート対象外なので、これは必須の準備手順です。

  • Server/Data Center と Cloud でグループ名の競合を確認して修正します。同名のグループは Confluence Cloud にマージされるため、これは必須の準備手順です。

  • 未使用のアプリやトライアル データを削除します。

  • 特定のページ、スペース全体、添付ファイル、マクロ、アプリなど、最近使用していないものがないかをご確認のうえ、削除することをご検討ください。使用統計の収集方法をご確認ください

すべてのデータを削除して、設定と空のスペース コンテナーのみを移行することを選択するお客様もいます。これは、Cloud で新規に開始する予定があって Server の設定を維持したい場合に適したオプションとなる場合があります。Confluence インスタンスのクリーン アップについて詳細をご確認ください

Confluence データのカスタマイズを最小限に抑える

Server/Data Center インスタンスのクリーンアップに役立つ Confluence クエリの一部を以下に示します。

これらはサンプル クエリであり、独自の環境で追加の調整やテストが必要になる場合があります。追加サポートについては、組織のデータベース管理者にお問い合わせください。これらのクエリの中には、何百万もの行を含む大規模なインスタンスで行う、実行に長時間を要するクエリがある場合があります。これらは慎重に行う必要があるため、まずはテスト環境で実行することを推奨します。

ユーザーごとにコンテンツ作成の統計結果を返すクエリ

1 2 3 4 5 6 7 8 9 select content.creator, cwd_user.display_name, count(content.contentid) as total_content_created from content inner join user_mapping on content.creator = user_mapping.user_key inner join cwd_user on user_mapping.username = cwd_user.user_name inner join spaces on content.spaceid = spaces.spaceid where contenttype = 'PAGE' and content.creator is not null and content_status = 'current' and prevver is null and content.creationdate between '2018-07-01' and '2019-01-01' group by content.creator, cwd_user.display_nameorder by total_content_created DESC

特定の時刻における各スペースの最終更新日を一覧表示する

1 2 3 4 5 SELECT spaces.spacename, spaces.spacekey FROM content, spaces WHERE content.spaceid = spaces.spaceid GROUP BY spaces.spacename, spaces.spacekey HAVING MAX(content.lastmoddate) < '2006-10-10';

次のステップ

インスタンスをクリーン アップした後は、次の移行前チェックリストを確認して、移行の準備を整えます。

詳細情報とサポート

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

その他のヘルプ