企業インフラは大きな変革期を迎えており、企業は時代の変化に対応しなければ、取り残されてしまうでしょう。VMwareのライセンス体系の見直し、インフラコストの上昇、パブリッククラウドの国内回帰に加え、ハードウェアの更新サイクルやAI要件の高まりなどにより、多くの組織がワークロードの実行場所と管理方法を見直さざるを得なくなっています。多くの企業にとって、2026年は今後数年間のIT運用を左右するインフラに関する重要な意思決定の年となるでしょう。
しかし、課題は仮想マシンをある環境から別の環境へ移行するほど単純ではありません。ワークロードごとに、パフォーマンス要件、依存関係、セキュリティ上の考慮事項、そして問題が発生した場合のビジネス上の影響が異なります。技術的なチェックリストだけを頼りにした移行計画は、アプリケーションの接続が途絶えたり、バックアップが失敗したり、ユーザーが予期せぬダウンタイムを経験したりすると、あっという間に事業継続上の問題に発展する可能性があります。だからこそ、ワークロードの移行は単なる技術プロジェクトではなく、戦略的なビジネス上の意思決定として捉えるべきなのです。
今日、より広範なインフラストラクチャのニーズを評価せずに、目先のコスト圧力に反応する組織は、単に一つの運用上の課題を別の課題に置き換えるだけのリスクを抱えています。VM移行とワークロード移行の違いを考えてみましょう。VM移行は仮想マシンをホスト、データセンター、またはプラットフォーム間で移動させるのに対し、ワークロード移行はより広い視野に立ち、アプリケーションをそもそも移動させるべきかどうか、どの環境が最適か、そしてその後アプリケーションを正常に運用するためにどのような変更が必要かに焦点を当てます。
ワークロードによっては、既存のプラットフォームを使い続けることが依然として適切な判断となる場合もあります。しかし、他のワークロードは、代替ハイパーバイザー、プライベートクラウド、パブリッククラウド、または最新のハイパーコンバージドインフラストラクチャ（HCI）の恩恵を受ける可能性があります。目標はすべてを移行することではなく、ビジネス価値に基づいて慎重に選択することです。このガイドでは、2026年にワークロード移行を推進する要因を探り、ワークロードの適切な配置場所を決定するための実践的なフレームワークを作成し、VMwareワークロード移行のリスクを明らかにし、運用安定性を維持しながらインフラストラクチャを最新化する方法を示します。それでは、まず基本的な概念から見ていきましょう。
ワークロード移行とは何ですか？
ワークロード移行とは、アプリケーションとそのサポートリソースを、機能性、セキュリティ、および必要なサービスレベルを維持しながら、あるインフラストラクチャ環境から別の環境へ移行するプロセスです。これらのリソースには通常、コンピューティング、ストレージ、ネットワーク、オペレーティングシステム、アプリケーション構成、IDサービス、およびバックアップ構成が含まれます。アプリケーションによっては、データベース、ミドルウェア、統合機能、および外部サービスも含まれる場合があります。
したがって、ワークロードは単なる仮想マシン以上のものです。サーバーを正常に移行したとしても、その上で実行されているアプリケーションが正しく動作することを保証することはできません。データベースにアクセスできない状態が続いたり、ファイアウォールルールが転送されなかったり、スケジュールされたバックアップジョブが動作しなくなったりする可能性があります。一方、効果的なアプリケーション移行では、実際の移行が始まるずっと前からこれらの依存関係を考慮に入れます。ワークロード移行には一般的に3つの主要なアプローチがあり、さらに移行する必要がなくなったアプリケーションについては、廃止または置き換えという4つ目の選択肢があります。
- リフトアンドシフト：アプリケーションが安定していて十分に理解されている場合、既存のワークロードを最小限の変更で新しい環境に移行し、移行を加速させる手法。ただし、この方法では既存の非効率性が移行先のプラットフォームに引き継がれる可能性がある。
- リプラットフォーム：移行先の環境の機能を活用するために、対象を絞った変更を行うこと。例えば、企業はデータベースVMを新しい環境に移行してマネージドデータベースサービスを採用したり、アプリケーションのストレージとリソース構成を調整してターゲットプラットフォームの利点を活かすことができます。VMwareから別のハイパーバイザーへVMを最小限の変更で移行することは、通常、リフトアンドシフトと呼ばれます。
- アーキテクチャの再構築：コンテナ、マイクロサービス、クラウドネイティブサービスなど、異なる環境向けにアプリケーションを再設計すること。これにより長期的な柔軟性が確保できますが、一般的にはより多くの時間、テスト、投資、およびアプリケーションに関する専門知識が必要となります。
最終的に、最適なワークロード移行戦略とは、アプリケーションのビジネス上の重要性、技術的な状況、そして将来の要件に合わせたアプローチを採用することです。すべてのレガシーアプリケーションが完全な再設計を必要とするわけではなく、すべてのアプリケーションをそのまま移行すべきでもありません。それでは、ワークロード移行が今日注目を集めている理由を見ていきましょう。
2026年のワークロード移行の現状：その波を牽引する要因とは？
今日、企業がワークロード配置に取り組む方法を変える、多くの現実的な市場要因が存在します。それぞれが、業界全体における慣行や考え方の大きな変化を表しています。これらの要因を理解することが、ワークロード移行が企業にとって優先的に取り組むべき課題である理由を理解する鍵となります。
VMwareライセンス再編
BroadcomによるVMwareの買収は、同社の製品ポートフォリオとライセンスモデルに変化をもたらし、永久ライセンス販売からサブスクリプションへの移行につながりました。この動きを受けて、多くの組織がライセンス更新のコミットメント、インフラストラクチャの経済性、そして単一の仮想化エコシステムへの長期的な依存について再検討を迫られています。多くの組織にとって、VMwareの更新コストの上昇は、より広範なワークロード移行戦略の触媒となり、どのワークロードをVMware上に残すべきか、どのワークロードをSangfor HCIのような代替ハイパーバイザーに移行すべきか、そしてどのワークロードをクラウドに移行すべきかを再評価するきっかけとなっています。
クラウドからの帰還
パブリッククラウドは多くの組織にとって依然として不可欠な存在ですが、クラウド導入によって、インフラストラクチャコストをワークロードの挙動に合わせることの重要性も明らかになりました。その結果、多くの組織がワークロードをパブリッククラウドからプライベートインフラストラクチャに移行しています。Broadcom の「Private Cloud Outlook 2026」調査によると、現在、企業の約83%がワークロードをプライベートクラウドに戻すことを検討しています。これは特に、需要が予測可能で、データ転送要件が高く、レイテンシが厳しく、特定のデータ所在地の義務があるワークロードに当てはまります。逆に、需要の変動が大きいアプリケーションや、マネージドクラウドサービスへの依存度が高いアプリケーションは、パブリッククラウドの方が適している可能性があります。
AIインフラの需要
AIの台頭は、ワークロード移行に新たな側面をもたらしている。推論、モデル開発、分析、データ準備といった作業は、コンピューティング、ストレージ、ネットワークに新たな要求を突きつけている。IDC の報告によると、世界のAIインフラ投資額は2025年には3,180億ドルに達し、2026年には4,870億ドルに達すると予測されており、インフラ計画を再構築する投資規模の大きさがうかがえる。
一部の企業にとって、GPUサポート、NVMeストレージ、高帯域幅ネットワークを備えた最新のHCIまたはプライベートクラウドプラットフォームは、AIワークロードのための実用的な基盤となり得るが、最適な設計はモデルのサイズ、データの場所、およびパフォーマンス要件によって異なる。
ハードウェアのライフサイクル終了
2010年代半ばから後半にかけて購入された多くのサーバーは、ベンダーの保証期間やサポート終了日を迎えているか、あるいは既に過ぎており、アプリケーションの可用性を維持しながらハードウェアを更新する必要性が高まっています。新しいインフラストラクチャへの移行は、仮想化、ストレージ、ネットワーク設計、災害復旧などを再検討する機会となります。
さて、ワークロード移行の実践的なアプローチとしては、各手法の取り組みを調整しつつ、その範囲を制御することが挙げられます。まずは対象プラットフォームを検証し、ハードウェアの互換性を確立してから、管理しやすい段階に分けてワークロードを移行します。しかし、より詳細な手順については、どのワークロードをどこに移行すべきかをどのように決定するかを見ていきましょう。
ワークロード移行決定フレームワーク：各ワークロードはどこに移行すべきか？
結局のところ、最も効果的なワークロード移行戦略とは、各アプリケーションをより広範なインフラストラクチャ計画の中の個別のビジネス上の意思決定として扱うことです。以下の4段階のフレームワークは、技術チームとビジネスリーダーがこれらの意思決定を一貫性をもって効果的に行うのに役立ちます。
ステップ1：移行プロファイルに基づいてワークロードを分類する
移行計画を策定するには、まず強固な基盤が必要です。そのためには、各ワークロードがどのような役割を果たし、どのように最適化できるかを理解する必要があります。まずは、各ワークロードを次の4つの基準に基づいて評価することから始めましょう。
| 基準 | 重要な質問 | 評価対象 |
| ビジネス上の重要度 | アプリケーションが利用できなくなった場合はどうなりますか？ | 収益への影響、業務の中断、復旧要件 |
| 技術的な複雑さ | アプリケーションを移行するのはどれくらい難しいですか？ | 依存関係、統合、オペレーティングシステム、データベース、およびネットワーク要件 |
| 変化への感度 | アプリケーションはどの程度の移行リスクを許容できるのか？ | 保守期間、性能許容範囲、規制上の義務 |
この評価には、アプリケーション所有者、インフラストラクチャチーム、セキュリティ専門家、および財務担当者を含める必要があります。技術チームは依存関係を理解し、ビジネス関係者はダウンタイムのコストとアプリケーションの動作変更による影響を明確にします。
ステップ2：ワークロードを適切な移行パターンに合わせる
ワークロードの分類が完了したら、適切な移行方法を選択してください。
リフト＆シフト：ターゲットプラットフォームと互換性があり、アプリケーションの変更を最小限に抑えて移行する必要がある安定したワークロードに最適です。移行期間を短縮できますが、パフォーマンスとリソース割り当てについては検証が必要です。
リプラットフォーム：対象を絞った変更によってワークロードが移行先インフラストラクチャを利用する方法を改善できる場合に最適です。たとえば、VMware VMをSangfor HCIに移行した場合、ワークロードの互換性と検証を前提として、適切に構成されたaSANストレージポリシーと改訂されたリソース割り当てによってメリットが得られる可能性があります。
再設計：既存の設計が拡張性、保守性、またはビジネスの俊敏性を制限している場合に有効です。コンテナ化やアプリケーションの再設計は正当化される場合もありますが、あらゆる移行のデフォルト要件ではなく、明確なビジネスケースに基づいて行うべきです。
廃止または置き換え：冗長性、陳腐化、または価値の低いアプリケーションで、安全に廃止または適切なSaaSサービスに置き換えることができるものに最適です。
ステップ3：リスクに応じて移行の順序を決定する
すべてのワークロードを同時に移行してワークフローの障害を引き起こすことを避けるため、まずは複雑性の低いアプリケーションのパイロットグループで移行ツール、運用手順、ネットワーク構成、バックアップ統合をテストしてください。テストで得られた教訓を活かし、より負荷の高いアプリケーションを移行する前にプロセスを改善しましょう。
アプリケーションの依存関係、業務機能、保守期間、ロールバック要件に基づいて、後続のフェーズをグループ化してみてください。大規模な企業の場合、プログラムは複数四半期または複数年に及ぶ可能性があります。大規模なシステム環境の場合、12～36か月の計画期間が有用な出発点となりますが、実際のスケジュールはワークロード量、契約上の期限、利用可能な人員、アプリケーションの複雑さによって異なります。
ステップ4：行動を起こす前に成功の定義を明確にする
ワークロードのVMが移行先のハイパーバイザー上で起動したからといって、移行が成功したとは限りません。まず、測定可能な受け入れ基準を事前に定義する必要があります。これには以下が含まれます。
- アプリケーションの応答時間とリソース使用率を、確立された基準値と比較した。
- 可用性、復旧時間目標（RTO）、および復旧時点目標（RPO）。
- 移行先プラットフォームでのバックアップおよび復元テストが正常に完了しました。
- ネットワーク接続、ID統合、アクセス制御、およびセキュリティ監視。
- アプリケーション所有者の承認とエンドユーザーによる検証。
- 文書化されたロールバックの判断基準点と手順。
この最終ステップにより、ワークロード移行は一連のインフラストラクチャ変更から、管理されたビジネス変革へと移行します。それでは、VMware移行が2026年にこれほど重要な課題となった理由に焦点を当ててみましょう。
VMwareワークロード移行：2026年の企業における最優先事項
VMware環境を大規模に運用している企業にとって、移行は単なる技術的な作業ではなく、ポートフォリオ全体を対象としたプログラムとなることが多い。数百、数千もの仮想マシンを運用する組織は、プラットフォームの選定、依存関係、テスト、ライセンス管理、組織の準備状況、そしてサービスの継続性といった要素を包括的に管理する必要がある。しかし、VMwareへの移行に着手する前に、自社のワークフローと利用可能な選択肢を理解しておくことが重要だ。
VMware移行を開始する前に移行先を評価する
VMwareの代替ソリューションを導入する前に、以下の4つの領域を評価してください。
- ワークロードの互換性：アプリケーションとゲストオペレーティングシステムは、大幅な設計変更なしにターゲットハイパーバイザ上で動作できますか？一般的な互換性に関する記述だけに頼るのではなく、実際のワークロードをテストしてください。
- 運用に関する習熟度：インフラストラクチャチームは、プロビジョニング、監視、トラブルシューティング、セキュリティ、および復旧を効果的に管理できますか？トレーニングや運用手順の変更を検討してください。
- 総所有コスト：ライセンス、サポート、ハードウェア、移行サービス、再トレーニング、バックアップ、災害復旧、継続的な管理など、3～5年間のコストを比較します。
- エコシステムの成熟度：バックアップ、監視、セキュリティ、自動化、災害復旧ツールとの統合を確認します。関連する正確なバージョンと展開構成がサポートされていることを確認します。
この評価には、ビジネス関係者と技術関係者の両方を含めるべきです。ライセンス費用だけを見れば魅力的に見えるプラットフォームでも、大規模な再トレーニングが必要になったり、サポート対象外の依存関係が生じたりする場合は、必ずしも最良の結果が得られるとは限りません。
VMwareからの移行における重要な技術的考慮事項
VMwareへの移行キャンペーンを開始する前に、貴社が評価する必要のある技術的な要素がいくつかあります。これらには以下が含まれます。
- ディスクフォーマット変換： VMware仮想マシンでは、一般的にVMDK仮想ディスクファイルが使用されます。別のハイパーバイザーに移行する場合、サポートされているディスクフォーマットへの変換またはインポートが必要になる場合があります。移行先のプラットフォームがどのフォーマットに対応しているか、また選択した移行ツールが自動的に変換を実行するかどうかを確認してください。
- ゲストツールとドライバ：VMware Toolsは、ゲストオペレーティングシステムの統合および管理機能を提供します。ターゲットプラットフォームとオペレーティングシステムによっては、VMware Toolsを削除したり、サポートされているゲストエージェントとドライバに置き換えたりする必要がある場合があります。特に、特殊なネットワーク構成やストレージ構成を持つシステムでは、この変更を慎重に計画してください。
- ネットワーク再構築：仮想スイッチ、分散スイッチ設定、VLAN、ファイアウォールポリシー、およびNSXに依存する構成は、別のプラットフォームにそのまま移行できるとは限りません。ソースネットワークの設計をマッピングし、必要な制御を移行先で再現し、本番環境への切り替え前に接続性とセグメンテーションをテストしてください。
- バックアップの継続性：VMwareのvSphere API for Data Protection（VADP）に基づいて設計されたバックアップ統合では、ワークロードがVMware環境から移行した後は保護されない可能性があります。ソース環境を廃止する前に、移行先でバックアップの適用範囲を確立し、テストしてください。保持ポリシー、復元手順、および災害復旧の互換性を確認してください。
- アプリケーションの依存関係とロールバック：データベース、認証システム、外部サービス、およびスケジュールされたジョブへの接続を文書化します。各移行フェーズについて、チームが障害を特定し、サービスを復旧し、続行するかロールバックするかを決定する方法を定義します。
大規模なVMware置き換えプログラムの管理
複雑なエンタープライズ環境においては、遅延、ワークフローの中断、その他の問題を防止するために、段階的なアプローチが重要となります。各段階には、明確なワークロード範囲、責任者、変更期間、受け入れ基準、およびエスカレーションパスを設定する必要があります。アーキテクチャと運用要件が許す限り、対象アプリケーションが受け入れチェックに合格し、ロールバック期間が終了するまで、ソースワークロードを利用可能な状態に維持するように努めてください。
ソースシステムと移行先システムが、重複トランザクションやデータ不整合を引き起こすような形で同時に動作しないことも非常に重要です。VMwareのライセンス期限が迫っているため、より迅速な移行を迫られる場合もあるかもしれませんが、移行先の環境、人材、ツール、復旧プロセスが準備されている場合にのみ、移行期間の短縮は有効です。主な目的は単にVMwareから離れることではなく、企業の将来の要件を許容できるコスト、複雑さ、リスクレベルでサポートするインフラストラクチャモデルを確立することです。それでは、ワークフロー移行計画を効率化するためにSangforがどのように役立つかを見ていきましょう。
Sangfor がエンタープライズ ワークロードの移行をどのようにサポートするか
Sangfor Technologiesは、AIを活用したクラウドインフラストラクチャおよびサイバーセキュリティソリューションを提供するグローバルな多国籍企業であり、アジア太平洋地域、中東、ヨーロッパ、ラテンアメリカの中堅企業および大企業にサービスを提供しています。Sangforは、フルスタックHCIプラットフォームとスタンドアロンハイパーバイザーの両方を提供しており、VMwareの代替ソリューションを検討している組織に、モダナイゼーションの方法に関して柔軟性を提供します。
VMwareの代替ソリューションを探している企業にとって、 Sangforのハイパーコンバージドインフラストラクチャ（HCI）は、コンピューティング、ストレージ、ネットワーク、セキュリティ機能を統合したインフラストラクチャプラットフォームを提供します。このアーキテクチャにより、企業はコンピューティング、ストレージ、ネットワークを完全に別々のプロジェクトとして扱うのではなく、より広範なワークロード移行戦略の一環としてインフラストラクチャの近代化を評価できます。
Sangforは、移行に適したアプリケーション、注意が必要な依存関係、移行先の環境がサポートしなければならない要件を明確にするワークロード評価が、最適な出発点であることを理解しています。それでは、Sangforが大規模なワークロード移行をどのように強化し、最適化するのかを見ていきましょう。
Sangfor HCI：統合された移行先
Sangfor HCIは、仮想化ワークロードを実行するためのハイパーバイザー基盤を提供するaSVコンピューティング仮想化をはじめとする、複数のインフラストラクチャ機能を統合しています。Sangfor aSANは、完全に統合された分散型ソフトウェア定義ストレージレイヤーであり、移行時にコンピューティングとともにストレージ容量、パフォーマンス、および耐障害性の設定を計画できます。Sangfor aNETは、視覚化された管理機能を備えた組み込みの仮想ネットワークを提供し、aSECは仮想化ワークロードにセキュリティ機能を追加します。
Sangforのクラウドプラットフォームは、仮想化環境の一元管理を提供し、VMware vCenter Serverに匹敵する役割で、管理者にプロビジョニング、監視、運用に関する共通インターフェースを提供します。これらのコンポーネントを組み合わせることで、企業はワークロードの統合とインフラストラクチャの近代化を評価するためのプラットフォームを利用できます。ビジネスケースは、すべてのアプリケーションが同じ移行先から等しく恩恵を受けるという前提ではなく、検証済みのワークロード互換性、運用要件、回復力、ライフサイクルコストに基づいて策定されるべきです。
SangforとVMwareエコシステムとの互換性
企業評価では、自社にとって最適なVMware代替ソリューションを選択する際に、同等の機能を比較検討する必要があります。幸いなことに、Sangfor aSVは、一般的なゲストOSを含むVMware仮想マシンの移行をサポートしており、再設計の必要性を軽減できます。ただし、各ワークロード、ゲストOSのバージョン、構成ごとに互換性を検証する必要があります。また、aSVはスタンドアロンのハイパーバイザーとしても利用可能で、HCIの本格的な導入前にコンピューティング環境の移行を検討している企業に最適です。
移行ツールと実行
ワークロード移行ツールは手作業を削減できますが、その機能はソースプラットフォーム、ターゲットバージョン、ゲストオペレーティングシステム、および移行方法によって異なります。Sangforは、ディスクフォーマット変換やゲストツールの置き換えなど、VMwareからaSVへの移行における主要な手順を自動化する移行ツールを提供しています。ネットワークおよびセキュリティポリシーのマッピングは、切り替え前に必ず確認およびテストする必要があります。
移行全体を通してバックアップとリカバリを保護する
バックアップの継続性は、VMware の置き換えプログラムにおいて極めて重要な要素です。移行後に正常に動作するワークロードであっても、新しい環境でバックアップとリカバリのテストが十分に行われていない場合は、完全に本番環境に対応できるとは言えません。Sangfor は、エコシステムパートナーシップを通じて、移行開始時からバックアップとリカバリの計画策定を支援します。Veeam は Sangfor 環境のバックアップ、リカバリ、および災害復旧のオーケストレーションをサポートし、Veritas との合併後の Cohesity は、データの回復力、管理、およびセキュリティをサポートします。バックアップジョブとリストア手順は、ソース環境を廃止する前に、ターゲットプラットフォームでテストする必要があります。
可視性管理と移行ガバナンス
移行期間中、SCPはVMの状態やリソース使用状況など、Sangfor HCIターゲット環境の一元管理を提供します。一方、チームは既存のツールを使用してVMwareソース環境の監視を継続します。VMware環境とSangfor環境を同時に運用している組織では、移行プロセス全体における可視性が特に重要になります。
Sangforのグローバルプロフェッショナルサービス組織は、大規模なVMwareリプレースプログラムを実施する企業向けに、移行計画、段階的な実行サポート、移行後の検証を提供するとともに、複雑な移行に対する地域規模および企業規模のサポートも提供しています。最終的に、最適なインフラストラクチャパートナーとは、評価とテストから本番環境への切り替え、復旧検証、そして継続的な運用に至るまで、移行ライフサイクル全体を通して企業をサポートできるパートナーです。
結論
2026年のワークロード移行は、企業にとって老朽化したインフラストラクチャの置き換えやVMwareライセンスの変更への対応にとどまらない、より大きな機会となります。アプリケーション要件の再評価、ワークロード配置の最適化、回復力の強化、そして将来のビジネス優先事項を支えるインフラストラクチャ戦略の構築を実現するチャンスです。重要なのは、どのワークロードを移行するか、どこで実行するか、そして移行後にどのように管理するかについて、十分な情報に基づいた意思決定を行うことです。
ワークロード移行を成功させるには、綿密な評価、段階的な実行、互換性の検証、そして中断のないバックアップとリカバリの実施が不可欠です。移行先がパブリッククラウド、プライベートクラウド、ハイパーコンバージドインフラストラクチャのいずれであっても、それぞれの移行は測定可能なビジネス価値と運用価値をもたらす必要があります。
VMwareの代替ソリューションを検討している企業にとって、Sangforはクラウドインフラストラクチャの近代化を実現するエンタープライズグレードの選択肢を提供します。aSV、aSAN、aNET、aSEC、そしてSangfor Cloud Platformによる集中管理機能を備えたSangfor HCIは、VMwareを置き換え、プライベートクラウドやハイブリッドクラウドへの移行を目指す組織にとって、統合されたエンタープライズグレードのプラットフォームとなります。
最終的な目標は、単にワークロードを移行することではなく、将来の展開を見据えた適切な基盤を構築することです。戦略的に移行に取り組む企業は、不要な複雑さを軽減し、運用上の信頼性を高め、インフラストラクチャに関する意思決定に柔軟性を持たせることができます。
よくある質問
アプリケーションとそのサポートインフラストラクチャを、機能性、セキュリティ、および必要なサービスレベルを維持しながら、ある環境から別の環境へ移行するプロセス。
VM移行は仮想マシンをホスト間またはプラットフォーム間で移動させることに重点を置くのに対し、ワークロード移行はアプリケーション全体、その依存関係、ビジネス要件、移行先の環境、および移行後の運用モデルを考慮します。
既存システムの移行、プラットフォームの再構築、アーキテクチャの再構築、あるいは廃止。最適なアプローチは、アプリケーションの複雑さ、ビジネス上の重要度、互換性、コスト、そして長期的な目標によって異なります。
まず、ワークロードと依存関係を洗い出し、互換性のあるターゲットハイパーバイザーを選択し、代表的なパイロットテストを実施します。本番ワークロードを段階的に移行する前に、ディスク変換、ゲストツール、ネットワーク構成、セキュリティ制御、バックアップ範囲、ロールバック手順を計画してください。
アプリケーションの非互換性、予期せぬダウンタイム、ネットワーク構成の誤り、データの不整合、バックアップ範囲の不足、スタッフの準備不足などがリスク要因となります。ワークロードごとの受け入れ基準、テスト済みの復旧手順、明確な責任分担を盛り込んだ段階的な移行計画は、これらのリスクを軽減するのに役立ちます。
