Server から Cloud への移行のテスト
移行する前に、クラウド組織を確認してください
現在、移行操作に影響する可能性のある変更をロール アウト中です。admin.atlassian.com の組織で、[ユーザー] リストと [グループ] リストが [ディレクトリ] タブの下にある場合は、ユーザー管理エクスペリエンスが改善されています。つまり、複数サイトのユーザーとグループが組織にマージされています。グループと権限の移行方法の詳細をご確認ください。ご不明な点がありましたら、サポートまでご連絡ください。
テスト移行または UAT の場合、テスト クラウド サイトは、製品サイトもホストしている組織に含まれないものを使用することをお勧めします。製品サイトは、別の組織でホストするようにしてください。これは、関連するユーザーとグループのスムーズな移行を確保するためです。
サーバーまたは Data Center 製品からクラウド製品への移行を計画する際、移行する前にトライアル実行を実施することを強くおすすめします。テスト移行は次のことに役立ちます。
- 予想されるダウンタイムも含めた、実際の移行のタイムラインの明確化。
- データの検証とユーザー受け入れテスト (UAT) の実行。
- ローンチの準備とオンボーディング時のコミュニケーションの構築。
- 実際の移行の前に解決する必要がある潜在的な問題や手順の確認。
このガイドでは、ベスト プラクティスやテスト対象を含む、Jira または Confluence のテスト移行を実行する方法の概要を紹介します。
はじめる前に
動作の仕組み
移行前のチェックを完了したら、移行を開始しましょう。
移行のテストと本番環境の移行の準備におすすめしている基本的なステップの概要は、以下のとおりです。
- データのクリーンアップ
- クラウド サイトへのサインアップ
- (オプション) Atlassian Access のセットアップ
- テスト移行の実行
- データの確認とユーザー受け入れテスト (UAT) の実施
- (オプション) テスト サイトのリセット
- 移行手順書の作成
- 変更管理とローンチ計画の作成
ステップ 1: データのクリーンアップ
移行するデータが多くなるほど、移行にかかる時間が長くなり、移行がより複雑になる可能性が高くなります。このため、テスト移行を実行する前にデータをクリーンアップする時間を取ることをおすすめしています。これによって、移行がスムーズになり、パフォーマンスの問題が軽減され、クラウド製品での生産性が向上する場合もあります。
データのクリーンアップの詳細については、「移行前のサーバー インスタンスのクリーンアップ」を参照してください。
ステップ 2: クラウド サイトへのサインアップ
クラウド サイトにサインアップしていない場合、今すぐサインアップを完了しましょう。テストをトライアル サイトで実行するか、本番サイトで実行するかを決定する必要があります。
トライアル サイトを使用する場合、次のことが可能です。
- 無料のクラウド移行トライアルの有効化
- 標準の 7 日間のトライアル (トライアル後に Free プランに戻ります) のセットアップ
新しい本番サイトへの移行テストを予定している場合、Free、Standard、または Premium プランから選択できます。
(オプション) ステップ 3: Atlassian Access のセットアップ
Atlassian Access は、SAML SSO、ユーザー プロビジョニング (SCIM)、強制 2 段階認証、監査ログなどのクラウド セキュリティおよびユーザー管理機能を提供します。これはすべてのアトラシアン クラウド製品およびドメインにわたって動作するため、ユーザーとセキュリティ ポリシーを 1 か所で管理できます。
クラウドで Atlassian Access を使用する予定がある場合、テスト移行を開始する前に 30 日の無料トライアルにサインアップし、すべてのユーザーに対して SSO をセットアップして、ユーザー プロビジョニングと監査ログをテストできます。30 日以上の期間が必要な場合は、お問い合わせください。
ステップ 4: 移行前のチェックリストを完了する
テスト移行を開始する前に、Jira や Confluence で移行前のチェックリストを実行し、データの準備が整っていることを確認します。
ステップ 5: テスト移行の実行
移行をテストする準備ができました。
Jira および Confluence Cloud Migration Assistant の場合
「Confluence Cloud Migration Assistant」または「Jira Cloud Migration Assistant」に記載されている手順に従い、データをインポートします。
データを移行したら、クラウド製品で使用する予定のアプリを移行またはインストールします。
移行を複数回テストする必要がある場合、再インポートする予定のデータを手動で削除する必要があります。これは、移行アシスタントがクラウド サイトにすでに存在するデータを上書きしないためです。データを削除するには 2 つの方法があります。
データを削除した後にテスト移行を再実行できます。
Jira サイト インポートの場合
「Jira サイト インポーターを使用してサーバーからクラウドに移行する」の手順に従ってデータをインポートします。
データを移行した後、クラウド製品で使用する予定のアプリを移行またはインストールします。
移行を再テストする必要がある場合、Jira のサイト インポートを行うと、以前インポートした Jira データやクラウド サイトに存在するデータなどのすべての既存のコンテンツが削除されます。つまり、過去のテスト移行のデータは自動的に削除されるため、複数回テストする場合に最初にデータを削除する必要はありません。
ステップ 6: データの確認とユーザー受け入れテスト (UAT) の実施
移行後、クラウド サイトを確認して、すべてが想定どおりに動作していることを検証します。
一般的な確認事項
- Jira 課題にリンクされている Confluence ページなど、他のコンテンツへのリンクが機能していることを確認します。
- 他のサーバー製品へのアプリケーション リンクの再構成が必要になる場合があります。この場合、再構成を行ったあとに機能を再テストし、連携が想定どおりに機能していることを確認します。
- 移行したアプリやアプリ データが想定どおりに動作していることを確認します。
- Jira、Confluence、または Bitbucket などの他の製品との連携をテストします。
- 移行およびローンチ後に予定されるトレーニングやコミュニケーションのためにスクリーンショットを取得し、サーバー製品とクラウド サイトとの間の変更を文書化します。
Jira の場合
- ワークフローが想定どおりに動作していることを確認します。たとえば、移行されていないサードパーティ製アプリに依存している事後操作がある場合があります。これらがクラウド製品では機能しないが、サーバー サイトでは引き続き機能していることがあります。
- 製品の使用やテスト データの作成を試します。新しいプロジェクトの作成、課題の作成と編集、添付ファイルのアップロードなどをテストします。
- Jira マクロの修復を実行し、動作しなくなったマクロが修正されるかどうかを確認します。
Confluence 用
- 添付ファイルが正しくインポートされていることを確認します。
- 移行したアプリやアプリ データが想定どおりに動作していることを確認します。Gliffy Diagrams などのサードパーティ製アプリに依存しているマクロが動作しない可能性があります。この場合、修正が可能かどうかをアプリ ベンダーにご確認ください。
UAT および変更管理のベスト プラクティス
ユーザー受け入れテストを実施する理由
一部のエンドユーザーにテスト サイトを使用して一般的な日常タスクを模倣してもらう、UAT を実施することをおすすめします。これによって、予期していない問題を把握できるだけでなく、組織が変更に対して準備することができます。
対象に含めるべき人物
これは組織ごとに異なりますが、次のようなユーザーとテストを行うことをご検討ください。
- 特定のチームのメンバー
- ヘビー ユーザーと使用頻度の低いユーザーの組み合わせ
- クラウド サイトに移行する各チームから選定されたメンバー
明確で建設的なフィードバックを提供できるユーザーを選定することもご検討ください。一般に、インプットを得るために、クラウド サイトを使用するすべての主要なユーザー タイプまたはロールを招待することをおすすめします。
テストすべき対象
慣れ親しんだ機能が移行で変更されることによる、ユーザーへの次のような問題を記録するようにします。
- 新機能
- 新しいユーザー インターフェイス
- 異なるアプリ
- 新しい URL とブックマークの変更
- ユーザー管理の違い
製品固有の推奨事項
- Jira Software および Jira Core: スプリントの作成、バックログへの課題の追加、ボードの参照などをテストします。
- Jira Service Management (旧 Jira Service Desk): キューの参照、ポータル ビューの確認、その他の一般的なアクティビティをエージェントに依頼します。
- Confluence: 新しいスペースの作成、ページの作成と編集、添付ファイルのアップロードなどをユーザーに試してもらいます。
ユーザーが混乱した領域や機能変更を記録します。これらはローンチ前やオンボーディング時に提供するコミュニケーションとトレーニングに含めることができます。
(オプション) ステップ 7: テスト サイトのリセット
本番環境インスタンスを使用してテストしたり、テストを再実行する必要がある場合などに、クラウド サイトからデータを削除して再度開始できます。
クラウド サイトからすべてのデータを削除し、既定の設定にリセットするには、こちらの手順に従います。
ステップ 8: 移行手順書の作成
移行手順書は、移行を完了するために必要な作業をまとめた詳細な手順ガイドです。これを作成することで、本番環境への移行を計画どおりにスムーズに実施できます。
手順書には、プロセスの各ステップ、それらのステップで必要な手順、それらを実施する担当者、予想される時間などを含める必要があります。
ステップ 9: 変更管理とローンチ計画の作成
テストが完了したら、ユーザーが移行の結果としてどのような変更に備えるべきかを予測できるようになります。ユーザーが作業を素早く再開するために必要なトレーニング、ドキュメント、コミュニケーションを準備します。
これらをまとめる際は、変更内容だけではなく、その理由や、ユーザーが移行から得られるメリットを強調するようにします。
ユーザー向けの一般的なメリットには、以下が含まれます。
- 無料のクラウド モバイル アプリへのアクセス
- どこからでも作業を行い、素早く安全にアクセス可能 (VPN は不要)
- 他の SaaS ツールやクラウド アプリとのより良い連携
詳細情報とサポート
移行をサポートする多数のチャンネルをご用意しています。
- 移行の詳細な計画情報や FAQ については、Atlassian Cloud 移行センターを参照してください。
- 技術的な問題が発生していたり、戦略やベスト プラクティスで支援が必要な場合、お問い合わせください。
- また、アトラシアン コミュニティもご利用ください。
- エキスパートによる支援が必要な場合、アトラシアン パートナーにご相談ください。