タスク 1: 移行パターンとメタデータの検証

このタスクでは、ポートフォリオワークストリームの評価およびウェーブプランニングアクティビティで特定された移行パターンを検証し、移行メタデータソースを検証します。目標は、各移行パターンをサポートするのに十分なデータが収集されていることを確認することです。

このタスクは、次のステップで構成されます。

• ステップ 1: 移行パターンを検証する

• ステップ 2: 移行メタデータとウェーブプランを検証する

ステップ 1: 移行パターンを検証する

ポートフォリオワークストリームでは、アプリケーションポートフォリオの初期評価、選択した移行戦略、各戦略の特定された移行パターンを実行しました。この情報は、ポートフォリオ評価ランブックに含まれている必要があります。詳細については、AWS 「大規模な移行のためのポートフォリオプレイブック」を参照してください。

このステップでは、移行戦略を確認し、すべての移行パターンを特定し、移行ランブックのドラフトを作成する準備が整っていることを確認します。このタスクはプロジェクト全体で繰り返すことができ、ポートフォリオの理解が成熟するにつれて、移行の後の段階で追加の移行パターンを特定する可能性があります。

1. ポートフォリオの移行戦略を確認する

   移行戦略は、オンプレミスアプリケーションを に移行するために使用するアプローチです AWS クラウド。アプリケーションをクラウドに移行するための 7 つの移行戦略は、7 R と呼ばれます。大規模な移行の一般的な戦略には、リホスト、リプラットフォーム、再配置、廃止などがあります。リファクタリングは、移行中にアプリケーションをモダナイズする必要があるため、大規模な移行にはお勧めしません。これは移行戦略の中で最も複雑であり、多数のアプリケーションに対して を管理するのは複雑になる可能性があります。代わりに、アプリケーションのリホスト、再配置、またはリプラットフォームを行い、移行の完了後にアプリケーションをモダナイズすることをお勧めします。7 R の詳細については、AWS 「大規模な移行用ガイド」を参照してください。

   最初のポートフォリオ評価の出力に基づいて、ポートフォリオに必要なすべての移行戦略のリストがあり、各戦略に割り当てられるポートフォリオの量を決定しました。以下に例を示します。

   • リホスト – 70%

   • リプラットフォーム – 20%

   • 廃止 – 10%

2. ポートフォリオの移行パターンを確認する

   移行パターンは、戦略、送信先、および使用されるアプリケーションまたはサービスの詳細を示す反復可能な移行タスクです。このステップでは、移行パターンに、使用するツールや対象となる AWS サービスなどの詳細情報が含まれていることを確認します。以下に例を示します。

   • AWS Application Migration Service （AWS MGN) または Cloud Migration Factory を使用して Amazon Elastic Compute Cloud (Amazon EC2) にリホストする

   • AWS CloudFormation テンプレートを使用して Amazon EC2 にリプラットフォームし、 で新しいインフラストラクチャを構築する AWS クラウド

   • AWS Database Migration Service （AWS DMS) またはネイティブデータベーステクノロジーを使用して Amazon Relational Database Service (Amazon RDS) にリプラットフォームする

   AWS 大規模な移行のポートフォリオプレイブックでは、各移行パターンを移行戦略にマッピングし、結果を次の例のような表に文書化します。

方針	パターン
リホスト	Application Migration Service または Cloud Migration Factory を使用して Amazon EC2 にリホストする
リプラットフォーム	DMS またはネイティブデータベーステクノロジーを使用して Amazon RDS AWS にリプラットフォームする
リプラットフォーム	AWS CloudFormation テンプレートを使用して Amazon EC2 にリプラットフォームし、 で新しいインフラストラクチャを構築する AWS クラウド

ステップ 2: 移行メタデータとウェーブプランを検証する

このステップでは、移行メタデータのソースの場所を検証します。Excel ドキュメントで使用可能な列などのデータ構造が、必要なメタデータを保持するのに適していることを確認し、すべてのメタデータが使用可能であることを確認します。

1. 移行パターンの移行メタデータを検証する

   サーバーとアプリケーションを移行するには、移行パターンごとに異なる移行メタデータのセットが必要です。例えば、Amazon EC2 へのリホスト移行では、VPC サブネット、セキュリティグループ、インスタンスタイプの情報など、ターゲットインスタンスの仕様を指定する必要があります。ただし、ストレージ移行、データベース移行、またはリプラットフォーム移行には、異なる移行メタデータのセットが必要です。通常、ポートフォリオ評価ランブックで移行メタデータ要件を定義しますが、各移行パターンをサポートするのに十分なメタデータがあることを確認する必要があります。メタデータの識別と収集の詳細については、AWS 「大規模な移行のためのポートフォリオプレイブック」を参照してください。

2. 移行メタデータとウェーブプランのソースの場所を検証する

   通常、移行メタデータのソースの場所はメタデータ管理ランブックに文書化します。理想的には、場所はウェーブプランニングスプレッドシートなどの単一の情報源として機能します。また、メタデータが、以下の一般的な場所を含む複数の場所に残っている可能性もあります。

   メタデータソースの場所について以下を検証します。

   • 検出ツール

   • 設定管理データベース (CMDB)

   • アプリ所有者アンケート

   • 移行ウェーブプランニングスプレッドシート

   メタデータソースの場所について以下を検証します。

   1. ソースカタログは、すべてのメタデータソースと所有者の場所で管理されていますか？

   2. ソースの場所 (ウェーブプランニングスプレッドシートなど) には、必要な移行メタデータがすべて含まれていますか？

   3. 各メタデータソースにアクセスするための明確な手順はありますか？

   4. ソースが 1 つもない場合、各メタデータソースはその属性に明確にマッピングされていますか？

   5. サーバーとアプリケーションに明確なウェーブプランがあり、移行ワークストリームの準備が少なくとも 5 つのウェーブがあるか？

   6. ソースを更新するプロセスはありますか？ その場合、頻度と通知プロセスはどのくらいですか？

タスク終了条件

次の終了基準を満たしたら、次のタスクに進みます。

• 明確に定義された移行パターンのリストを検証しました。

• 移行メタデータのソースの場所には、各パターンに必要なメタデータがすべて含まれているか、欠落しているメタデータをキャプチャするプロセスが設定されています。

• 少なくとも 5 つのウェーブについてウェーブプランと移行メタデータを検証し、通知と更新のプロセスを定義しました。