ポートフォリオ分析と移行計画

このステージでは、ポートフォリオレベルのビューの反復、データギャップの解消、より多くのデータの取得に重点を置いて、ポートフォリオ全体の信頼性の高い移行ウェーブプランを作成します。 

このステージのステークホルダーは通常、前の 2 つのステージを混在させます。これには、CxOs とシニアリーダー、移行チームとプラットフォームチーム、IT アーキテクトとエンタープライズアーキテクトが含まれます。重要なのは、反復と改良を通じてポートフォリオレベルのデータ忠実度を高めることです。

ヒント

詳細とガイダンスについては、AWS クラウド 移行用のアプリケーションポートフォリオ評価ガイドの関連セクションを参照してください。

大まかな目標とアクション

• アプリケーションポートフォリオと関連インフラストラクチャのベースラインを確立する – 検出の加速と初期計画段階から構築されたポートフォリオレベルのデータを反復して、ギャップを埋め、アプリケーションポートフォリオ全体の高レベルビューを生成します。この段階では、application-to-infrastructureへのマッピング、使用状況データ、アプリケーションメタデータ属性を絞り込むことが重要です。これらの属性には、所有権、重要度、各アプリケーションのプライマリ関数が含まれます。

• 依存関係データを取得して分析する (通常は特殊な検出ツールを使用) – アプリケーションを検証し、移行ウェーブプランの作成を支援するには、この段階で信頼性の高いアプリケーション依存データが重要です。依存関係データには、システム間の通信の量や頻度などの通信データや、運用上の考慮事項などの非技術的な依存関係が含まれます。これらの依存関係によって、同時に移動する必要があるアプリケーションと、異なる場所から操作できるアプリケーションが決まります。

• コンプライアンスと規制要件を特定して検証する – フレームワーク、ルール、証拠、およびドキュメントの要件を特定して検証します。 

• 仮定を事実に変換する – 以前の段階ではどのくらい引き受けましたか？ この段階では、前提条件の数を最小限に抑えることが重要です。

• 移行ポートフォリオ合理化モデルのベースラインを確立する – 以前のステージ (アプリケーションの優先順位付け基準や 6 R 決定ツリーなど) からモデルを反復します。モデルをアプリケーションポートフォリオ全体に適用して検証します。

• 測定可能なビジネス成果を文書化する – 移行の波をビジネス目標に合わせるには、各移行ウェーブのビジネス成果と関連する主要主要指標 (KPI) を特定します。

• 方向性のあるビジネスケースの進化 – ベンチマークを実際の使用率とコストデータに置き換え、更新されたウェーブプランに合わせて移行コストを絞り込みます。コスト削減、IT 生産性の向上、耐障害性の向上、俊敏性の向上など、期待される各ビジネス成果から期待される価値をすべて含めるようにカバレッジを拡大します。

• 重要な日付を文書化して伝える – 魅力的なイベント (データセンターの終了日、契約、ライセンス契約の更新など）、アプリケーションのリリースサイクル、回避すべき移行日、テクノロジーの更新サイクル、人材の可用性を文書化して伝えます。

• ウェーブプランニングのコストとリスクを分析する — どの程度の並列変更をサポートまたは許容できますか？ 人材の要件、リスクの特定と緩和、重要度、影響を分析します。

• スキル要件の特定 — クラウド内のさまざまなワークロードタイプをサポートする準備状況の予測レベルはどのくらいですか？ 移行ウェーブ計画は、計画された準備状況と一致していますか？ サポートチームはウェーブプランの要件を満たすことができますか？

• 内部プロセスを文書化する – 変更管理、サービス管理、アーキテクチャレビューボード、リスク評価、承認ワークフローなど、クラウド移行に影響する現在のプロセスに関する情報を文書化します。

• 移行ウェーブプランの作成 – ウェーブプランを作成するには、このリストで前述したすべての要素を組み合わせます。ポートフォリオに優先順位基準を適用し、依存関係を分析してアプリケーションの波を作成します。プラットフォームと移行準備を移行ウェーブプランに組み込みます。 AWS インフラストラクチャとサービスの実装にはどのくらいの時間がかかりますか？ セキュリティと運用の準備には何が必要ですか？ 波の持続時間にはどのような影響がありますか？ 移行ツールの実装にはどのくらいの時間がかかりますか？ ネットワークとシステムの使用状況を考慮して、データのレプリケートにはどのくらいの時間がかかりますか？ カットオーバーウィンドウとは ロールバックにはどのくらいの時間がかかりますか？

• ワークストリームの更新 – ポートフォリオと詳細なアプリケーション評価データを移行およびランディングゾーンのワークストリームにフィードするプロセスを確立します。これらのワークストリームがデータ要件を明確に概説していることを確認します。

結果

• 忠実度の高いアプリケーションとインフラストラクチャのインベントリ

• 各アプリケーションの高レベルの移行戦略

• 詳細なビジネスケース

• 信頼性の高い移行ウェーブプラン

ベストプラクティス

• 移行ウェーブプランでアプリケーションが均等に分散されていることを確認します。ブロック要因や移行の遅延につながる可能性のある複雑さを避けるため、重要度と複雑さを考慮してください。

• 最初の 2 つのウェーブでは、重要でないシンプルなアプリケーションを優先します。

• 優先順位、依存関係、ビジネスドライバーを組み合わせて、ウェーブプランを反復することに焦点を当てます。

• ウェーブプランを作成するときは、クラウドインフラストラクチャ、セキュリティ、運用準備状況 (スキルを含む) を考慮します。

• 通常 4～8 週間の移行ウェーブの長さがアプリケーションジャーニーの概要となるようにウェーブプランを作成します。各波は以下をカバーする必要があります。

  • 詳細な評価

  • 移行の準備状況

  • インフラストラクチャの構築とテスト

  • データ転送

  • ウェーブ内のアプリケーションのカットオーバー

  • ウェーブクロージャ (学習した教訓、移行後の問題の解決など）

デフォルトのウェーブ構造を定義して使用し、詳細な評価、設計、実装、テスト、カットオーバー、検証を含む移行ファクトリモデルを適用します。