クラウドへの移行をテストする

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 での生産性が向上する場合もあります。インスタンスのクリーンアップの詳細をご確認ください。

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

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

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

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 日を超える場合は、サポート・チームにお問い合わせください。

Atlassian Access の詳細を確認

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

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

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

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

Jira および Confluence Cloud Migration Assistant の場合

データの移行

以下のページに記載されている手順に従います。

再移行時にデータを削除

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

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

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

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

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

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

全般的なデータ レビュー

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

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

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

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

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

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

Jira のデータ レビュー

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

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

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

  • 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 ツールやクラウド アプリとのより良い連携

Cloud でユーザーの利用を開始する方法をご確認ください。

詳細情報とサポート

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

 

その他のヘルプ