最初に、自社が実際にVMwareの何を使っているか棚卸しします。サーバ仮想化製品群「VMware vSphere」（以下、vSphere）だけを利用しているのか。それとも、vSphereに加え、ストレージ仮想化ソフトウェア「VMware vSAN」（以下、vSAN）、ネットワーク仮想化ツール「VMware NSX」（以下、NSX）、運用管理ソフトウェア「VMware Cloud Foundation Operations」（旧称VMware Aria Operations）、バックアップ製品との連携まで含めて仮想化基盤を構成しているのかによって移行の難易度は変化します。

　vSphereを中心に構成し、NSXやvSANなどへの依存が少ない環境であれば、これらを広く利用している環境と比べて、移行時に見直す範囲を絞りやすくなります。一方、NSXでネットワークを仮想化し、vSANでストレージを統合している企業は、単なる「VM（仮想マシン）の引っ越し」では済まず、ネットワーク設計やストレージ運用ごと見直す必要があります。まずは自社がどちら側にいるのかを、機能単位で確認することが、検討の出発点になります。

確認項目2．次回のライセンス更新費はいくらになるか

　Broadcom体制以降のVMwareは、物理コア数を基準としたサブスクリプション課金に移行しました。そこで、以下の項目も棚卸しする必要があります。

• ホストの台数
• CPU数
• コア数
• VCF／VVFの対象範囲

　重要なのは、一般的な「値上がり率」ではなく、自社の場合に更新費がいくらになるかを確認することです。ホスト数やCPUのコア数、契約する製品によって影響は異なるため、まずは実際の更新見積もりを取得します。その上で、課金単位や最低コア数などのライセンス条件も確認し、現行環境を維持した場合の費用を算出します。

確認項目3．移行費用を含めても安くなるか

　ここが、今回の判断で最も重要な論点です。移行には、ライセンス費以外にも次のコストがかかります。

• 新基盤の構築費
• 移行ツールの費用
• ベンダーへの支払い
• 移行後のテスト工数
• アプリケーションの改修費
• 運用担当者の教育費
• 移行期間中の並行稼働コスト

　これらを積み上げると、移行初年度のコストはライセンス更新費を上回る可能性があります。そこで比較すべきは、「今年の更新費がいくら上がるか」ではなく「VMwareを3〜5年使い続けた場合のTCO」と「移行費用を含めた、移行後3〜5年のTCO」です。単年の見積もりだけを見て移行を決めてしまうと、移行コストを回収するために想定以上の時間がかかる展開になりかねません。

確認項目4．利用中の機能を移行先で代替できるか

　NSXやvSANを利用している場合は、VMの移行だけでなく、ネットワークやストレージの設計・運用方法まで見直す必要が生じる可能性があります。ネットワークのセグメント設計、ストレージの冗長構成、DR（災害復旧）の仕組み、バックアップの連携先まで、それぞれを再設計する必要がある場合もあります。

　固有機能への依存度が高ければ、「VMの移行」だけではなく、「インフラ基盤の再設計」に近いプロジェクトになります。この依存度を重視せずに見積もりを立てると、想定より工数がふくらみ、移行する方が高額になる場合もあります。

確認項目5．アプリケーション側の移行条件は整理できているか

　意外と見落とされがちなのが、アプリケーション側の視点です。インフラ台帳に載っているVMの台数のみを数えても、移行計画としては不十分である恐れがあります。そこで、以下を確認します。

• アプリケーションのオーナーは誰か
• SLA（サービスレベル合意）や停止可能時間
• 他システムとの依存関係
• OSやミドルウェアのバージョン
• データベースの構成
• バックアップとDRの仕組み

　VMの台数が分かっても、それぞれのVM上で稼働するアプリケーションの停止可能時間や依存関係までは分かりません。移行対象のアプリケーションがどの部門の管理下にあり、どのシステムと連携しているかまで把握して初めて、移行順序や停止時間を含む現実的な計画を立てられます。

確認項目6．全ワークロードを同じ基盤へ移すべきか

　移行を検討する際、移行先を1つに決めようとする企業があります。しかし、オンプレミスの別の仮想化基盤へ移すもの、パブリッククラウドへ移行するもの、コンテナ基盤への移行を検討するものなど、ワークロードごとに移行先を分ける方法もあります。1つの製品に全体を寄せることを前提にせず、システムの重要度や特性に応じて移行先を使い分ける発想が、結果的にコストとリスクの両方を抑えることにつながります。

確認項目7．次回更新までに移行を完了できるか

　最後に確認したいのが、時間的な制約です。特に数百台規模の仮想マシンを抱える環境では、次回更新までの期間が短い場合、全てを一度に移行するのは難しい可能性があります。

　その場合の現実的な選択肢が、段階的な移行です。契約条件が許せば、次回更新時はいったんVMwareの利用を継続し、その契約期間中に一部のワークロードを先行して移行する方法もあります。その上で次々回の更新までにVMwareの比率を下げていく、という進め方です。一足飛びの全面移行にこだわらず、更新サイクルに合わせて段階的に依存度を下げていくことも、十分に合理的な選択肢です。