クラウド移行戦略を選択する

この記事は、ポートフォリオ内の各ワークロードに最適なクラウド移行戦略を選択するのに役立ちます。 各戦略 (廃止、保持、リホスト、リプラットフォーム、リファクタリング、再設計、再構築、または置換) には、ビジネス目標と技術的要件に合わせて必要な個別の利点とトレードオフが用意されています。

移行戦略の概要

次の表は、使用可能なすべてのクラウド移行戦略の包括的な概要を示しています。 このリファレンスを使用して、各戦略の主要なビジネス ドライバーと、ワークロードに各アプローチを適用するタイミングを示す主要なインジケーターを理解します。

クラウド導入前にビジネス ドライバーを決定する

ビジネス ドライバーは、戦略的成果をサポートするためにワークロードを変更する必要がある理由を定義します。 これらの要因を特定することで、クラウド導入の決定が測定可能なビジネス価値と一致することが保証されます。

1. クラウド導入のための組織のビジネス目標を定義します。 ビジネス目標は、ワークロードの関連性と変革のニーズを評価するための基盤を提供します。 明確に定義された目標がない場合、ワークロードの決定は戦略的成果をサポートしない可能性があります。 ビジネス利害関係者は、機敏性、イノベーション、コストの最適化、回復性、持続可能性などの目標を定義または検証する必要があります。 これらの目標を把握するには、戦略的計画ドキュメント、エグゼクティブ インタビュー、またはビジネス ケース ワークショップを使用します。

2. 定義されたビジネス目標に対する各ワークロードの貢献度を分類します。 分類では、各ワークロードが組織の戦略的な方向性をどのようにサポートしているかを明確にします。 ワークロード チームとビジネス利害関係者は、各ワークロードが 1 つ以上のビジネス目標に貢献しているかどうかを共同で評価する必要があります。 メトリック、利害関係者の入力、アーキテクチャドキュメントを使用して、アラインメントを決定します。 機敏性の実現、イノベーションの推進、コストの削減、回復性の向上、または持続可能性のサポートにおけるワークロードの役割を文書化します。

3. 現在の機能と将来の期待とのギャップを特定します。 ギャップ分析では、ビジネス目標を達成するために各ワークロードが何を変更する必要があるかが明らかになります。 ワークロードの現在のパフォーマンス、スケーラビリティ、アーキテクチャを、定義された目標をサポートするために必要なものと比較します。 機能、統合、コンプライアンス、またはユーザー エクスペリエンスのギャップを文書化します。 これらの分析情報を使用して、移行戦略の選択を通知します。

4. 各ワークロードのビジネス ドライバーを決定します。 ビジネス ドライバーには、現在の制限事項と将来の期待の両方が反映されています。 ビジネス利害関係者とワークロード チームは共同作業を行い、戦略的成果をサポートするために各ワークロードの実行方法を異なる方法で定義する必要があります。 技術的、運用上、およびコンプライアンスの要件を検討します。 次の表を使用して、識別されたビジネス ドライバーに基づいて実行可能な移行戦略の一覧を絞り込みます。

   Business driver	Migration strategy
   冗長または低価値のワークロードの使用を停止する必要がある	Retire
   ビジネスの中断を最小限に抑え、近い将来に最新化を行う必要がない	Rehost
   ビジネス目標を達成するために PaaS ソリューションと最小限のコード変更が必要	Replatform
   ビジネス目標を達成するためにコードを変更する必要がある	Refactor
   目標を達成するためにアーキテクチャを変更する必要がある	Rearchitect
   運用を簡素化するために SaaS/AI ソリューションが必要	Replace
   要件を満たすために新しいクラウドネイティブ ソリューションが必要	Rebuild
   安定性を必要とし、変更を回避する	Retain

適切な移行戦略を選択する

移行戦略では、各ワークロードがビジネス ドライバーに基づいて Azure に移行する方法を定義します。 絞り込まれた戦略の一覧を確認し、選択したオプションをビジネス関係者や技術関係者と共に検証します。 コンプライアンス、セキュリティ、または運用上の制約と競合するオプションを削除します。 戦略を最終決定する際には、Azure の準備、チーム スキル、統合の複雑さを考慮してください。

1. 廃止 (使用停止)

ビジネス価値を提供しなくなったワークロードを廃止する。 この戦略は、ワークロードが古い、使用されていない、または冗長である場合に重要です。 ワークロードが古く、他のシステムに影響を与える重大な依存関係がないことを確認して、この決定を検証します。 ワークロードの使用停止時にインベントリを更新します。

2. リホスト (同様の移行)

リホスト戦略では、最小限の変更でワークロードを Azure に移行することで、迅速かつ低リスクの移行が可能になります。 リホストは同様の移行であり、仮想マシンを IaaS に、IaaS を IaaS に、PaaS を PaaS に移動します。

1. 問題のあるワークロードをリホストしないでください。 リホストでは、既存のパフォーマンス、信頼性、またはアーキテクチャの問題は解決されません。 最新化なしでこのようなワークロードを移行すると、技術的負債が繰り越される可能性があり、後でやり直す必要があります。 代わりに、移行中にこれらのワークロードを最新化して、根本原因に対処します。

2. ワークロードが 2 年以内に最新化を必要としないことを確認します。 リホストは、ワークロードが少なくとも 2 年間、現在の状態のままであることを確信している場合にのみ適しています。 モダン化の可能性が高い場合は、重複する作業を回避するために、代わりにリファクタリングまたは再設計を検討してください。

3. リホストを使用して、基本的なクラウド運用を構築します。 リホストは、チームが Azure の運用、ガバナンス、コスト管理の経験を積むのに役立ちます。 この早期公開は、より広範なクラウド導入目標をサポートし、チームがより複雑な最新化作業を準備します。

3. リプラットフォーム (ホスティング環境の最新化)

再プラットフォーム化により、コードの変更を最小限に抑えて、ワークロードが最新のホスティング環境に移行します。 この戦略は、完全なアプリケーションの書き換えを行わずに、インフラストラクチャ管理を削減し、スケーラビリティを向上させ、運用を簡素化する場合に重要です。

PaaS オプションによって運用オーバーヘッドが削減され、信頼性が向上するか、ディザスター リカバリーが簡略化されるワークロードを選択します。 PaaS サービスを利用するには、最小限のコード リファクタリングが必要な場合があります。

4. リファクタリング (コードの最新化)

リファクタリングにより、新しい機能を追加することなく、コードの内部構造が向上します。 この手法は、チームがレガシ コードを最新化し、技術的負債を削減し、Azure の長期的な保守容易性のためにワークロードを準備するのに役立つので、クラウド導入時に重要です。 移行プロセスで技術的負債に対処するユニークな機会が生まれる場合、または移行後の動作によって改善の領域が明らかになった場合は、コードをリファクタリングする必要があります。

5. 再設計 (アーキテクチャとコードの最新化)

再設計戦略では、スケーラビリティ、機敏性、サービス指向を向上させるために、ワークロードのアーキテクチャを再設計します。 この戦略は、モノリシック アプリケーションの分割、マイクロサービスの導入、またはターゲットスケーリングの有効化が必要な場合に重要です。 現在のアーキテクチャでビジネス目標を達成したり、効果的にスケーリングしたりする能力が制限されている場合は、再設計する必要があります。 例については、「 モダン Web アプリ パターン」を参照してください。

6. 置き換える (SaaS 代替を使用)

代替戦略では、商用 SaaS ソリューションを使用して、カスタム開発と継続的なメンテナンスの必要性を排除します。 この戦略は、SaaS オファリングが最小限のカスタマイズでビジネス ニーズを満たす場合に最適です。 SaaS ソリューションが同等の機能を提供し、統合機能が要件を満たし、総保有コストが移行を正当化する場合は、ワークロードを置き換えます。 データ移行の複雑さ、ユーザートレーニングのニーズ、プロセスの変更を含め、置き換えオプションを評価する際に考慮してください。 一般的な代替シナリオには、CRM システム、人事プラットフォーム、コラボレーション ツールが含まれます。SaaS の成熟度によって、カスタム ソリューションに対する信頼性の高い代替手段が提供されます。

7. リビルド (クラウドネイティブのビルド)

再構築戦略は、クラウドネイティブ ソリューションを使用したワークロードの完全な再開発です。 このアプローチは、レガシ システムが古い場合、または最新化が不可能な場合に適しています。 従来の機能を最新化するのではなく、PaaS、自動化、AI などの Azure 機能を使用するようにソリューションを再考できます。 一部のワークロードでは、DHCP サーバーなどの再構築が必要です。 他のワークロードの場合は、Active Directory ドメイン コントローラーなど、サービスの新しいインスタンスを移行するのではなく、Azure にデプロイすることをお勧めします。

8. 保持 (そのまま保持)

保持戦略は、ワークロードが安定しており、準拠していて、現在および将来のすべてのビジネスニーズを満たし、移行の差し迫った理由がない場合に、ワークロードを現在の環境で維持します。 規制の制約、技術的な依存関係、またはビジネス継続性の要件のために移行できないワークロードを保持する必要があります。 Use Azure Arc to manage retained on-premises workloads from Azure, providing unified management capabilities. Consider a more modern on-premises solution like Azure Local for your workloads and connect to Azure. 別の移行ウェーブに移行できないワークロードをシフトするか、制約が変更されたときに後で再検討します。

移行中に最新化するタイミングを理解する

移行中の最新化とは、クラウドの価値を最大化するためにワークロードを再プラットフォーム化、再設計、またはリファクタリングすることを指します。 最新化は長期的な利点を提供できますが、移行のタイムラインに複雑さとリスクをもたらします。 明確な業務上の正当な理由に基づいて、移行中に最新化するか、移行後フェーズに最新化を延期するかを評価する必要があります。 次の推奨事項に従います。

1. チームが必要なスキルと時間を持っている場合に最新化します。 適切な専門知識や時間を必要とせずに最新化を試みると、リスクと遅延が増加します。 チームの準備が不十分な場合は、最新化を後のフェーズに延期します。

2. 互換性の更新が必要なワークロードを最新化します。 レガシ テクノロジ、サポートされていない SDK、または SaaS ソリューションを採用する必要性には、最新化が必要な場合があります。 各作業を明確なビジネス ケースで正当化します。

3. 移行によって資金調達と調整が可能になったときに最新化します。 移行プロジェクトは、多くの場合、資金と利害関係者のサポートのロックを解除します。 この機会を利用して、最新化をビジネスの優先順位に合わせます。 遅延すると、非効率的なワークロードが発生し、機会が見逃される可能性があります。

利害関係者に意思決定を伝える

明確なコミュニケーションにより、すべての利害関係者が、導入プロセス全体を通じて移行の決定を理解し、サポートできるようになります。 利害関係者の配置により、優先順位と制約に関する共有の理解を確立することで、実行リスクが軽減され、プロジェクトの成果が向上します。 移行プロセス全体を通じて調整を維持するために、構造化された通信計画を確立する必要があります。 次の推奨事項に従います。

1. ビジネス成果を検証する成功メトリックを定義します。 成功メトリックは、選択したアクションの値を定量化し、ビジネス ドライバーが達成されたかどうかを確認します。 この手順により、技術的な完了ではなく、ビジネス価値に基づいて決定が行われます。 次のようなメトリックを使用します。

   クラウド移行戦略	成功メトリックの例
   Retire	• 移行前に廃止済みとして識別された 100% のワークロードを廃止する
   Rehost	• サービス レベル アグリーメント (SLA) の低下なしで、100% の階層 1 ワークロードを他のクラウドから Azure に移行する • 移行後に 30% のオンプレミス インフラストラクチャを使用停止します。
   Replatform	• 移行されたアプリケーションのデプロイのリード タイムを 30% 短縮 • インフラストラクチャとライセンスのコストを 12 か月以内に 25% 削減
   Refactor	• Azure ネイティブ サービスを使用してアプリケーションの応答時間を 40% 向上させる • コードインストルメンテーションにより、95% の可観測性カバレッジを実現
   Rearchitect	• パフォーマンスの低下なしで 2 倍のユーザー負荷をサポート • 3 つの新しい Azure ネイティブ サービスを既存のアーキテクチャに統合する
   Replace	• 99.9% アップタイムでカスタム コードなしで CRM を SaaS に移行 • 競争上の差別化要因に対する開発作業の% を 30 にシフトする。
   Rebuild	• 新しいクラウドネイティブアプリケーションを、オンプレミスの6か月に対して3か月でリリース PaaS サービスを使用して運用コストを 40% 削減
   Retain	• 現在の SLA とコンプライアンス体制を維持する • Azure Arc を使用して Azure からオンプレミスのワークロードを管理する

2. ワークロード処理の決定を文書化し、関連するすべての利害関係者と共有します。 移行の決定は、複数の組織機能に影響を与え、広範な利害関係者の入力を必要とします。 意思決定のコミュニケーションには、ビジネス所有者、法務チーム、セキュリティ チーム、技術リーダーが含まれます。 各移行戦略の決定が文書化されたビジネス目標をサポートし、利害関係者の懸念にどのように対処するかを説明します。

3. 移行計画をクラウド戦略チームと調整します。 クラウド戦略チームは、組織のコンテキストを提供し、移行の決定が広範なクラウド導入目標と一致することを保証します。 定期的な調整により、個々のワークロードの決定と企業全体のクラウド戦略の間の競合を防ぐことができます。 一貫性を維持するために、戦略フェーズ中に確立されたクラウド導入計画に対する移行戦略の選択を確認します。

4. 委任所有者と実行チームの間で定期的なコミュニケーションを確立します。 意思決定者と実装者の間で継続的なコミュニケーションを行い、技術的な現実が生まれるにつれて計画が実行可能であることを保証します。 移行の進行状況を追跡し、リスクを特定し、技術的な問題に対処するために、定期的な進行状況レビューをスケジュールします。 このフィードバック ループを使用して、実装の課題や新しい機会が発生したときに移行戦略を調整します。

5. 進化する要件に基づいて、移行戦略を確認して更新します。 ビジネスの優先順位と技術的な分析情報は移行プロセス全体で変化し、戦略の調整が必要になります。 現在のビジネス目標と技術的な機能に対するワークロード処理の決定を再評価するための定期的なレビュー サイクルを確立します。 新しい優先順位、学習した教訓、組織のニーズの変化を反映するように戦略マッピングを更新します。

Next steps