Server から Cloud への移行をテストする

Server または Data Center から Cloud への移行を計画している際は、移行前にトライアル実行を実施することを強くお勧めします。テスト移行は次のことに役立ちます。

  1. 予想されるダウンタイムも含めた、実際の移行のタイムラインの明確化。

  2. データの検証とユーザー受け入れテスト (UAT) の実行。

  3. ローンチの準備とオンボーディング時のコミュニケーションの構築。

  4. 実際の移行の前に解決する必要がある潜在的な問題や手順の確認。

このガイドでは、ベスト プラクティスやテスト対象を含む、Jira または Confluence のテスト移行を実行する方法の概要を紹介します。

はじめる前に

  • 計画ガイドを確認する: 移行を成功させるには、移行計画をしっかりと準備する必要があります。テスト開始前に、Cloud 移行ガイドをご確認ください。このガイドには、テスト開始前に知っておくべき情報を含む、主要なフェーズや各ステップの考慮事項が記載されています。

  • 移行方法を選択する: Cloud 移行方法は複数用意されています。テスト前に、これらの方法を比較して最適な方法を選択する必要があります。

  • 前提条件の完了: 移行方法を選択したら、ドキュメントを確認し、テスト前に実施する必要がある前提条件となる手順がないことを確認します。

Cloud 組織を確認する

現在、移行エクスペリエンスに影響する可能性がある変更を導入しています。admin.atlassian.com の組織で、ユーザーグループの各リストが [ディレクトリ] タブにある場合は、改善されたユーザー管理エクスペリエンスをご利用中です。これは、サイト全体のユーザーとグループが組織でマージされることを意味します。グループと権限の移行方法に関する詳細についてご覧ください。ご不明な点がありましたら、サポートまでお問い合わせください

テスト移行または UAT の場合、テスト クラウド サイトは製品サイトもホストしている組織に含まれないものを使用することをお勧めします。製品サイトは、別の組織でホストするようにしてください。これは、関連するユーザーとグループのスムーズな移行を確保するためです。

テストの仕組み

移行前のチェックを完了したら、移行を開始しましょう。

移行のテストと本番環境の移行の準備におすすめしている基本的なステップの概要は、以下のとおりです。

  1. データのクリーンアップ

  2. Cloud サイトにサインアップする

  3. (オプション) Atlassian Access のセットアップ

  4. テスト移行の実行

  5. データの確認とユーザー受け入れテスト (UAT) の実施

  6. (オプション) テスト サイトのリセット

  7. 移行手順書の作成

  8. 変更管理とローンチ計画の作成

ステップ 1: データのクリーンアップ

移行するデータが多くなるほど、移行にかかる時間が長くなってより複雑になる可能性が高くなります。このため、テスト移行の実行前にデータをクリーンアップする時間を取ることをお勧めしています。これによって、移行がスムーズになってパフォーマンスの問題が軽減され、さらには Cloud における生産性が向上する可能性があります。 

移行前の Server インスタンスのクリーンアップに関する詳細についてご確認ください。

ステップ 2: Cloud サイトにサインアップする

まだサインアップしていない場合は、今すぐしましょう。テストをトライアル サイトか本番サイトかどちらで実行するかを決定する必要があります。 

トライアル サイトを使用する場合、次のことが可能です。

クラウド移行トライアルをご利用の場合は、サンドボックス環境で移行をテストできるように、Atlassian Cloud Premium プランまたは Enterprise プランを選択するか、それらにアップグレードすることをお勧めします。Premium と Enterprise の両プランは Standard プランよりも多くの機能を備えているため、このテスト環境では追加機能が表示される場合があることにご注意ください。

サンドボックス テストとステージング環境のセットアップ方法に関する詳細についてご確認ください。

サイト名 (URL) の形式は https://example.atlassian.net/ になります。ここで、example はユーザーが指定する一意の文字列です。

サイト名は、最初の製品にサインアップする際 (例: Jira Software Cloud または Confluence Cloud への初回サインアップ時) に、Atlassian Cloud サイト全体に対して選択されます。

サイト名を指定する際には、いくつかの点に考慮する必要があります。

  • 3 文字以上の一意の文字列にする必要があります。

  • 英数字とハイフンのみを使用できます。

  • 最初と最後の文字にはハイフンを使用できません。

ステップ 3 (オプション): Atlassian Access をセットアップする

Atlassian Access は、SAML SSO、ユーザー プロビジョニング (SCIM)、強制 2 段階認証、監査ログなどの Cloud セキュリティとユーザー管理の各機能を提供します。これはすべての Atlassian Cloud 製品とドメイン全体で動作するため、ユーザーとセキュリティ ポリシーを 1 か所で管理できます。 

Atlassian Access を Cloud で使用する予定がある場合は、テスト移行の開始前に 30 日の無料トライアルにサインアップしてすべてのユーザーに対して SSO をセットアップすることで、ユーザー プロビジョニングと監査ログをテストできます。必要な期間が 30 日を超える場合は、サポート チームにお問い合わせください。

ステップ 4: 移行前のチェックリストを完了する

テスト移行を開始する前に、JiraConfluence で移行前のチェックリストを実行して、あなたとそのデータの準備が整っていることを確認します。 

ステップ 5: テスト移行を実行する

移行をテストする準備ができました。

Jira および Confluence Cloud Migration Assistant の場合

  1. Confluence Cloud Migration Assistant」または「Jira Cloud Migration Assistant」に記載されている手順に従い、データをインポートします。 

  2. データの移行後、Cloud で使用する予定のアプリを移行またはインストールします。 

移行を複数回テストする必要がある場合は、再インポートする予定のデータを手動で削除する必要があります。これは、移行アシスタントが Cloud サイトにすでに存在するデータを上書きしないためです。データを削除するには 2 つの方法があります。

  1. Cloud サイトからすべてのデータを削除する

  2. 個々のスペースを削除するか、個々のプロジェクトを削除する

データを削除した後にテスト移行を再実行できます。

Jira サイト インポートの場合

  1. Jira サイト インポーターによって Server から Cloud に移行する」の手順に従ってデータをインポートします。

  2. データの移行後、Cloud で使用する予定のアプリを移行またはインストールします。 

移行を再テストする必要がある場合は、Jira のサイト インポートによって、以前インポートした Jira データや Cloud サイトに存在するデータなどのすべての既存のコンテンツが削除されます。つまり、過去のテスト移行のデータは自動で削除されるため、複数回テストする場合は最初にデータを削除する必要はありません。

ステップ 6: データの確認とユーザー受け入れテスト (UAT) の実施

移行後、Cloud サイトを確認して、すべてが想定どおりに動作していることを検証します。 

全般的なデータ レビュー

通常は次のロールになります。

  • Jira 課題にリンクされている Confluence ページなど、他のコンテンツへのリンクが機能していることを確認します。

  • 他の Server 製品へのアプリ リンクの再設定が必要であるかどうかを確認します。必要である場合は、再設定を行ったあとに機能を再テストし、統合が適切に機能していることを確認します。

  • 移行したアプリやアプリ データが適切に動作していることを確認します。

  • Jira、Confluence、または Bitbucket などの他の製品との統合をテストします。

  • スクリーンショットを撮って、移行中とローンチ後に予定しているトレーニングやコミュニケーションのために Server と Cloud の各サイト間の変更を記録します。

Jira のデータ レビュー

Jira データに関する確認事項

  • ワークフローが適切に動作していることを確認します。たとえば、移行されていないサードパーティ製アプリに依存している事後操作があるかもしれません。これらは Cloud では機能しないものの、Server サイトでは引き続き機能している場合があります。 

  • 製品を使用してテスト データを作成します。新規プロジェクトの作成、課題の作成と編集、添付ファイルのアップロードなどをテストします。

  • Jira マクロの修復を実行して、動作しなくなったマクロが修正されるかどうかを確認します。

Confluence のデータ レビュー

Confluence データに関する確認事項

  • 添付ファイルが正しくインポートされていることを確認します。

  • 移行したアプリやアプリ データが想定どおりに動作していることを確認します。Gliffy Diagrams などのサードパーティ製アプリに依存しているマクロが動作しない可能性があります。この場合は、修正できるかどうかをアプリ ベンダーにご確認ください。

UAT および変更管理のベスト プラクティス

一部のエンドユーザーにテスト サイトを使用して一般的な日常タスクを模倣してもらう、UAT を実施することをおすすめします。これによって、予期していない問題を把握できるだけでなく、組織が変更に対して準備することができます。

関与する必要があるユーザー

これは組織ごとに異なりますが、次のようなユーザーと一緒にテストすることをご検討ください。

  • 特定のチームのメンバー

  • ヘビー ユーザーとライト ユーザーの組み合わせ

  • Cloud サイトに移行する各チームから選定されたメンバー

明確で建設的なフィードバックを提供できるユーザーの選定もご検討ください。一般に、インプットを得るために、Cloud サイトを使用するすべての主要なユーザー タイプまたはロールを招待することをお勧めします。

テストの対象

慣れ親しんだ機能が移行で変更されることによる、ユーザーへの次のような問題を記録するようにします。

  • 新機能

  • 新しいユーザー インターフェイス

  • 異なるアプリ

  • 新しい URL とブックマークの変更

  • ユーザー管理の違い

製品固有の推奨事項

Jira Software と Jira Work Management の場合 

  • スプリントの作成、バックログへの課題の追加、ボードの表示などをテストします。

Jira Service Management (旧 Jira Service Desk) の場合 

  • エージェントに依頼して、キューの表示、ポータル ビューの確認、その他の一般的なアクティビティを確認します。

Confluence の場合: 

  • ユーザーに依頼して、新しいスペースの作成、ページの作成と編集、添付ファイルのアップロードを試します。

ユーザーが混乱した領域や機能変更を記録します。これらはローンチ前やオンボーディング時に提供するコミュニケーションとトレーニングに含めることができます。 

ステップ 7 (オプション): テスト サイトをリセットする

本番環境インスタンスによってテストした、またはテストを再実行する必要がある場合など、状況によっては Cloud サイトからデータを削除してもう一度テストする必要がある可能性があります。Cloud サイトのすべてのデータをリセットして削除するには、次の手順に従います。

ステップ 8: 移行手順書の作成

移行手順書は、移行を完了するために必要な作業をまとめた詳細な手順ガイドです。これを作成することで、本番環境への移行を計画どおりにスムーズに実施できます。

手順書には、プロセスの各ステップ、それらのステップで必要な手順、それらを実施する担当者、予想される時間などを含める必要があります。

ステップ 9: 変更管理とローンチ計画の作成

テストが完了したら、ユーザーが移行の結果としてどのような変更に備えるべきかを予測できるようになります。ユーザーが作業を素早く再開するために必要なトレーニング、ドキュメント、コミュニケーションを準備します。 

これらをまとめる際は、変更内容だけではなく、その理由や、ユーザーが移行から得られるメリットを強調するようにします。

ユーザー向けの一般的なメリットには、以下が含まれます。

  • 無料の Cloud モバイル アプリにアクセスする

  • どこからでも作業を行い、素早く安全にアクセス可能 (VPN は不要)

  • 他の SaaS ツールやクラウド アプリとのより良い連携

詳細情報とサポート

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

 

その他のヘルプ