ツールと初期移行バックログの準備

[アーティクル]
04/15/2024

移行を実装するには、移行する適切なツールとワークロードの包括的なバックログが必要です。この記事では、必要なツールを定義し、最初の移行バックログを構築して、移行の準備をする方法に関するガイダンスを提供します。

移行ツールを準備する

移行を正常に完了するには、修復アクティビティを含むイテレーションを通じてワークロードを評価、レプリケート、追跡するための特定のツールが必要です。

さまざまな移行ツールが利用可能です。多くは Azure プラットフォームにネイティブであるか、既に一般的に使用されています。

移行プロジェクトを成功させるために必要な一般的なツールまたはオファリングの一覧を次に示します。

ツールの種類	機能	ツール
検出と評価	環境の自動検出と評価を実行します。移行の阻害要因を識別し、サーバー間の依存関係を識別します。	Azure Migrate
レプリケーション	オンプレミスのソースとクラウドステージング環境の間でデータ状態をレプリケートします。リソースのハイドレートと移行に使用されます。	Azure Migrate
追跡	サーバーをワークロードにグループ化し、修復アクティビティを追跡し、ワークロード移行の状態を提供するなど、プロジェクトアクティビティを整理するために使用されます。	Azure DevOps、Excel、Microsoft Project
移行ガイド	Azure Migrate に使用する移行機能を特定するのに役立ちます。移行実行ガイドは、移行の決定と実装を段階的にガイドできるプロジェクトリソースです。	移行実行ガイド

Azure Migrate の代わりに他のツールを使用できますが、特定された理由がない限り、ネイティブオファリングを使用することをお勧めします。 Azure Migrate のネイティブオファリングは、Azure プラットフォームとシームレスに連携するように構築されており、最新の機能をサポートするように継続的に更新されます。

Note

既存のツールを使用してワークロードを Azure にレプリケートすると、このプロセス中にツールを変更すると、パフォーマンスが中断され、低下する可能性があります。このシナリオでは、引き続き既存のツールを使用します。後で、ディザスターリカバリーフェールオーバーシナリオのように移行の昇格を実行できます。

初期移行バックログ

以降のセクションでは、初期移行バックログを構築するために実行する必要がある前提条件のアクティビティについて説明します。

クラウド戦略チームは、デジタル資産のケアとメンテナンスを担当します。ただし、デジタル資産のマッピングから生成されたバックログへの対処は、移行プロセスに関連するすべてのロールの共有責任に該当します。クラウド戦略チームとクラウド導入チームは、チームが個々のワークロードアクティビティの計画を開始する前に、移行バックログを確認して理解する必要があります。そのレビュー中に、両方のチームのメンバーが、移行バックログについて以下のキーポイントを言葉で明確に表現するための十分な知識を身に付ける必要があります。

ビジネスの成果とメトリック

チームのすべてのメンバーが、意図したビジネスの成果を理解する必要があります。移行には時間がかかります。チームメンバーは、移行のさまざまな段階で、緊急ではあるが戦略的ではない活動に気を取られがちです。意図した結果を確立して強固にすることで、チームメンバーが移行アクティビティの優先順位と相対的な重要性を理解し、長期にわたってより適切な意思決定を行えるようにするのに役立ちます。

移行の進行状況を追跡することは、移行チームのモチベーションにとっても、利害関係者の継続的なサポートにとっても同様に重要です。移行 KPI を使用して、およびメトリックを監視して進行状況を追跡します。作業量を追跡する方法にかかわらず、後続のイテレーションの間にパフォーマンスを評価できるよう、チームが主要なメトリックを認識していることが重要です。

ビジネスの優先順位

あるワークロードを別のワークロードよりも優先することは、論理的ではないように思えたり、クラウド導入チームにとって有益でさえない場合があります。ワークロードの優先順位付けの決定を促進するビジネスの優先順位を理解することは、チームが重要なモチベーションを維持するのに役立ちます。また、優先順位の決定プロセスにおいてチームがより強力に貢献できるようになります。

コアとなる前提条件

デジタル資産の合理化では、デジタル資産を評価する際の基本的な前提に基づいて作業することによる機敏性と時間の節約への影響について説明します。これらの価値を十分に実現するために、クラウド導入チームは前提条件とそれらが確立された理由を理解する必要があります。その知識により、チームは有効性と節約に関する仮定に異議を唱えることができるようになります。

バックログのキャプチャ

クラウド導入チームのすべてのメンバーと共有できる場所にバックログをキャプチャします。共有された場所から、さまざまなチームメンバーが知識と作業をバックログに合わせることができ、移行プロセス全体を通じてバックログを最新の状態に保つことができます。

組織で使い慣れたツールを使用することも、デジタル資産の合理化を完了するために使用するツールを基にすることもできます。

事前構築済みのテンプレートをお探しの場合は、移行実行ガイドに、バックログの整理に役立つスプレッドシートテンプレートが用意されています。

バックログ内の個々のサーバー移行を通じてワークロード自体を追跡できるように、ワークロードをサーバーに関連付ける必要があります。また、バックログを使用して、評価を完了するときにワークロード間の依存関係を示すこともできます。資産を修復してテストを完了すると、バックログを修復計画にマージします。

バックログは、移行プロセス全体で使用されます。バックログの維持は重要です。

複数のデータセンターのバックログを計画する

移行を開始する前に、移行するデータセンターごとにプロジェクトマネジメントツールでエピックを作成する必要があります。データセンターエピックでは、関連する作業をグループ化して、各データセンターの場所の状態を追跡できます。

エピックを使用して移行を管理しない場合は、データセンターのトップレベルの目標またはグループ化を使用できます。重要なのは、各データセンターを個別の場所としてフィルター処理、整理、追跡できることです。

移行によるビジネス上の効果と動機を理解しておくことが重要です。これらの動機を使用して、エピック (データセンター) の一覧に優先順位を付けます。たとえば、現在のリースが終了する前にオンプレミスのデータセンターから移行する意図が移行を促進する場合は、リースの更新日を使用してエピックに優先順位を付けます。

各エピック内で、機能として評価および移行するワークロードを管理します。そのワークロード内の各資産を、ユーザーストーリーとして管理します。タスクは、各資産を評価、移行、最適化、促進、保護、管理する作業を表現します。

スプリントまたはイテレーションは、クラウド導入チームがコミットする資産とユーザーストーリーを移行するために必要な一連のタスクです。スプリントは通常、会計四半期やカレンダー月などの時間のセグメントです。リリースは、運用環境に昇格される 1 つ以上のワークロードまたは機能を表します。

次のステップ

回復性のプラン