フェーズ 2：計画

このフェーズでは、準備フェーズで収集した情報を使用して、移行戦略を策定します。移行計画の重要な側面は、収集した情報を移行の 7 R (リホスト、リプラットフォーム、リロケーション、リ購入、リファクタリング、廃棄、維持) に対して合理化することです。

移行戦略の選択は、時間の考慮事項、ビジネスおよび財務上の制約、リソース要件だけでなく、クラウド導入のビジネス推進要因にも依存します。現在のワークロードをクラウドで維持したい場合は、リホストを選択してください。ただし、ワークロードを最適化してスケーリングしたい場合は、他のオプションのいずれかを検討してください。

データベース移行の 7 R の概要を以下に示します。これらを次の図に示します。

• リホスト (リフトアンドシフト) – アプリケーションを変更せずにクラウドに移動します。例えば、オンプレミスのオラクル・データベースを、 AWS クラウドの「Amazon Elastic Compute Cloud」 (Amazon EC2) インスタンス上のオラクルに移行します。

• 再配置 (ハイパーバイザーレベルのリフトアンドシフト) – 新しいハードウェアを購入したり、アプリケーションを書き換えたり、既存の運用を変更したりすることなく、インフラストラクチャをクラウドに移行できます。サーバーをオンプレミスプラットフォームから同じプラットフォームのクラウドサービスに移行します。例えば、Microsoft Hyper-V アプリケーションを に移行します AWS。

• リプラットフォーム (リフトアンドリシェイプ) – アプリケーションをクラウドに移行し、クラウド機能を活用するためにある程度の最適化を導入します。例えば、オンプレミスの Oracle データベースを AWS クラウドの Amazon RDS for Oracle に移行します。

• 再購入 (ドロップアンドショップ) – 通常は、従来のアプリケーションからサービスとしての Software as a Service (SaaS) 製品に移行して、別の製品に変更し、オンプレミスアプリケーションから新しい製品にデータを移行します。例えば、顧客データをオンプレミスの顧客関係管理 (CRM) システムから Salesforce.com に移行します。

• リファクタリング (リアーキテクト) – アプリケーションを移行し、クラウドネイティブの特徴量を最大限に活用してアーキテクチャを変更することで、俊敏性、パフォーマンス、スケーラビリティを向上させます。例えば、オンプレミスの Oracle データベースを「AuroraPostgreSQL」 に移行します。この戦略には、 がさまざまなワークフロー AWS に提供する専用のデータベースを使用するようにアプリケーションを書き換えることも含まれます。あるいは、モノリシックなアプリケーションを、独自のデータベーススキーマにアクセスする小さなマイクロサービスに分割してモダナイズすることもできます。

• 保持 (再アクセス) – アプリケーションをお客様のソース環境で保持します。これらには、大規模なリファクタリングが必要で、その作業を後回しにしたいアプリケーションや、移行するビジネス上の正当性がないため保持したいレガシーアプリケーションなどが含まれ場合があります。

• 廃止 – お客様のソース環境で不要になったアプリケーションを廃止または削除します。