LASSIC Media らしくメディア
VMwareライセンス改定後の移行判断と外注活用
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- Broadcomの方針転換により、VMwareの永続ライセンスは新規販売が終了し、サブスクリプション型のVCF・VVFへ集約されています。
- サポート契約が更新を迎えるタイミングが、VMware継続か他基盤への移行かを検討する最初の分岐点になります。
- 脱VMware移行を選ぶ場合は、資産棚卸からPoC・切替計画までを外部の専門パートナーに委託することで、リスクを抑えながら進められます。
目次
永続ライセンス販売終了とVCF・VVF一本化 — Broadcomが変えた3点
VMwareライセンス改定とは、2023年11月に買収を完了したBroadcomが永続ライセンスの新規販売を終了し、VMware Cloud Foundation(VCF)・vSphere Foundation(VVF)というサブスクリプション型の統合製品に製品構成を集約した措置を指します*1*2。
2023年11月の買収完了とライセンス方針転換*1
Broadcomは2023年11月22日にVMwareの買収を完了しました*1。以降、VMwareは「VMware by Broadcom」として事業を続けており、製品・ライセンス体系は大きく組み直されています。
買収完了から2カ月後の2024年1月22日、VMware Cloud Foundationブログ（VMware公式ブログ）が方針転換を発表しました*2。多数のソフトウェア製品を単体では販売せず、VCFまたはVVFの一部としてのみ提供する内容で、今回のライセンス改定の直接の出発点となっています。
永続ライセンス販売終了とサブスクリプション一本化*2
2024年1月の発表以降、VMwareソフトウェアの新規販売は永続ライセンスからサブスクリプションに一本化されました*2。vSphere Enterprise Plus・vSAN・NSX・Aria管理スイートなど、従来は個別に購入できていた製品は数多くありました。これらの多くが、VCFまたはVVFというセット提供に集約されています*2。
すでに永続ライセンスを保有し、サポート契約(SnS)が有効な企業は、契約期間中はそのまま利用を継続できます*2。ただし、Broadcomは永続ライセンスのサポート契約の新規更新を提供しておらず、契約満了時には新しいライセンス体系への移行が必要になります*2。
vSphere Foundation・Cloud Foundationへの製品バンドル再編*4
vSphere Foundation(VVF)は「エンタープライズグレードのワークロードプラットフォーム」と位置づけられています*4。仮想化・簡易管理・ハイパーコンバージドインフラの機能をまとめて提供する製品です。VMware Cloud Foundation(VCF)は、このVVFを基盤としながら、クラウド管理と統合自動化の機能を加えた製品です*4。
つまり、従来は個別に選べていた仮想化基盤の各機能が、VVF・VCFという2種類のセットのどちらかを選ぶ形に整理されました*2*4。この理解が実態に近いといえます。この再編が、次章で説明するコスト構造の変化につながります。
CPU1基16コア下限の課金ルールと契約更新で生じるコスト変化
VCF・VVFのコアライセンスは、ESXi(VMwareのハイパーバイザ製品)ホスト全体の物理CPUコア数に基づいて計算されます*3。ここで実務に直結するのが、CPU1基あたり最低16コアでカウントするという下限ルールです*3。
CPU1基あたり16コア以上でカウントする課金ルール*3
Broadcomの公式ナレッジベースでは、「実際のコア数が16未満でも16コアとして計算する」というルールが明記されています*3。たとえば2CPU×8コアのホストであれば、実コア数は16でも、下限ルールにより2CPU×16コア=32コア分としてライセンスを購入する計算になります*3。
複数ホストで構成される環境では、この下限ルールがホストごとに適用されます*3。コア数の少ない小規模ホストを多数保有している企業ほど、実コア数と課金対象コア数の差が広がりやすい仕組みです。自社のホスト構成でどの程度差が出るかは、契約更新前に確認しておく必要があります。
バンドル購入と契約規模で総コストが変わる要因
従来はvSphere単体やvSAN単体など、必要な機能だけを個別に購入できていました。VCF・VVFへの一本化後は、NSXやAriaなど利用していない機能も含むセットを契約する場合があり、これがコスト構造を変える要因の一つです*2。
もっとも、契約体系の変更による総コストの増減は、保有しているライセンス構成や契約規模によって大きく異なります。一律の倍率で説明できるものではなく、正確な影響を把握するには、現行契約とVCF・VVFそれぞれの見積もりを取得し、社内で比較検討する必要があります。
サポート契約の満了タイミングが最初の判断点になる*2
永続ライセンスのサポート契約は、既存契約の期間中であれば継続利用が可能です*2。しかし契約満了後は同条件での更新ができないため、サポート契約の満了日が、VMware継続か他基盤への移行かを検討し始める最初の節目になります*2。
移行には資産の棚卸・移行先の検証・切替計画の策定という相応の準備期間が必要です。サポート契約が切れる直前になって検討を始めると、十分な検証時間を確保できないおそれがあるため、契約満了より前に判断軸を整理しておくことが望まれます。
VMware継続と他基盤移行 — コスト・技術・体制で見る4つの判断軸
VMware環境を継続するか、他のハイパーバイザやクラウドへ移行するかは、単純な費用比較だけでは決められません。ここでは、コスト構造・技術要件・運用体制・移行リスクという4つの軸が整理の切り口です。
| 判断軸 | VMware継続 | 他基盤へ移行 |
|---|---|---|
| コスト構造 | サブスクリプション契約への更新で、16コア下限ルールにより総コストが変わる可能性があります。 契約内容の見積もりで事前確認が必要です。 |
移行先のライセンス費用(または無償)に加え、移行作業・検証にかかるコストが別途発生します。 |
| 技術要件 | vSAN・NSXなど既存機能をそのまま使い続けられます。 | 移行先での機能互換性・性能を個別に検証する必要があります。 |
| 運用体制 | 既存の運用手順・人材スキルをそのまま活かせます。 | 新しい基盤の運用手順・監視・バックアップ体制を再構築する必要があります。 |
| 移行リスク | 契約更新のタイミング管理が主な留意点になります。 | 切替時のダウンタイムやアプリケーション互換性がリスクになります。 事前のPoC(概念実証)で低減を図ります。 |
既存資産(vSAN・NSXなど)の活用度で継続コストを見積もる
vSANによるストレージ仮想化やNSX(ネットワーク仮想化・セキュリティ機能)を高度に使い込んでいる環境もあります。こうした環境では、置き換える移行先の選定・検証に相応の工数がかかるでしょう。まずは自社がVMwareのどの機能をどこまで使っているかを棚卸しすることが、判断の土台になります。
契約更新コストと移行コストを両方見積もって比較する
継続を選ぶ場合の更新見積もりと、移行を選ぶ場合の移行先ライセンス・移行作業費を並べて比較することが欠かせません。移行コストには、移行先の環境構築だけでなく、検証・並行稼働・切替作業の人件費も含めて算定する必要があります。
運用体制・社内人材のスキル転換余地を確認する
移行先が変われば、日常の運用手順・監視方法・バックアップの取り方も変わります。社内の運用担当者が新しい基盤の知識をどの程度習得できるか、あるいは外部の運用支援を組み合わせる余地があるかを、コスト比較と並行して確認しておくとよいでしょう。
移行先の選択肢 — ハイパーバイザとクラウドの3系統
脱VMwareの移行先は一つに絞られるものではなく、企業の要件に応じて複数の系統から選ぶ形になります。ここでは特定製品を優劣で評価せず、確認できる提供形態の範囲で3系統を整理します。
オンプレミス代替ハイパーバイザ(OSS系・商用系)の選択肢
既存のオンプレミス環境をそのまま活かしたい場合は、ハイパーバイザの入れ替えが選択肢になります。Proxmox VEのようなオープンソース系や、Hyper-V・Nutanix AHVといった商用ハイパーバイザが候補です。いずれも仮想マシンの実行基盤という点ではVMwareと役割が重なります。ただし管理機能や対応するストレージ・ネットワーク構成には違いがあり、自社の要件に照らした個別の検証が必要です。
クラウド事業者が提供するVMware環境の提供条件変化*5*6
ハイパーバイザ自体を変えず、VMware環境をクラウド上で使い続ける選択肢もあります。Microsoftが提供するAzure VMware Solutionは、Azureの専用ベアメタル基盤上でVMware環境を構築するサービスです*6。vSphere・vSAN・NSXを含み、Microsoftが管理・サポートする形で提供が続いています。
一方、Google Cloud VMware Engineは、Broadcomのライセンス配布方針の変更を受けて提供条件が変わりました。Google Cloudの公式ドキュメントによると、2025年10月15日以降はライセンス同梱ノードの新規販売を終了しています*5。以降は、利用者が自らBroadcomからVCFサブスクリプションを購入するBYOL(Bring Your Own License)方式のみです。クラウド事業者経由でVMwareを使う場合も、Broadcomのライセンス改定の影響を受ける点は変わりません。
パブリッククラウドへのリプラットフォーム(IaaS再構築)
仮想マシンをそのまま移すのではなく、パブリッククラウドのIaaS(仮想サーバーサービス)やマネージドサービスに載せ替える方法もあります。この方式はハイパーバイザ単位の入れ替えよりも設計変更の範囲が広く、アプリケーションのアーキテクチャ自体を見直す工程が加わります。そのため、他の2系統に比べて検討・実装の期間が長くなりやすい選択肢といえるでしょう。
脱VMware移行に必要な3つの工程と外注が担う役割
移行先を決めた後も、実行フェーズには複数の専門工程が続きます。ここで扱うのは、代表的な3工程と、内製で進める場合のリスク・必要スキルです。
資産棚卸と依存関係調査(アプリ・ネットワーク・ストレージ)
移行の第一歩は、稼働している仮想マシン・アプリケーション・ネットワーク設定・ストレージ構成を棚卸し、どの資産がどの資産に依存しているかを洗い出す作業です。この調査が不十分だと、移行後に想定していなかった依存関係が原因で、業務システムが正しく動作しなくなるおそれがあります。
移行先のPoC(概念実証)による性能・互換性検証
移行先が決まったら、本番導入の前に小規模な環境でPoC(概念実証。移行先が要件を満たすかを小規模に検証する工程)を経て、性能・機能互換性を確認します。特にNSXの高度なネットワークセグメンテーションを使っている場合、移行先で同等の機能が用意できるかどうかは、PoCで実機検証しない限り判断が難しい領域です。
切替計画とロールバック手順の設計
本番切替では、ダウンタイムを最小化する計画と、問題が発生した際に旧環境へ戻すロールバック手順の両方を事前に用意しておく必要があります。切替計画を誤ると、移行作業中にシステムが長時間停止し、業務に影響が及ぶリスクがあります。
資産棚卸・依存関係調査・移行先の実装知識・ネットワーク移行・切替時のプロジェクト管理は、いずれも異なる専門性を要する領域です。これらを一貫して社内で担うには、複数分野の知識を持つ人材を組み合わせる必要があり、体制構築の負荷は小さくありません。専門パートナーに委託する場合は、棚卸からPoC・切替計画までを一つの体制で見通せるため、工程間の情報の欠落を防ぎやすくなります。
委託先を選ぶ3つの評価軸
脱VMware移行を外注する場合、委託先の選定が移行の成否を左右します。以下の3つの評価軸を確認するとよいでしょう。
VMware移行・仮想化基盤の技術対応範囲を確認する
ハイパーバイザの入れ替えだけでなく、ネットワーク(NSX相当の機能)・ストレージ(vSAN相当の機能)・バックアップ体制まで一貫して対応できるかを確認します。対応範囲が仮想マシンの移設だけに限られていないかは、契約前に明確にしておく必要があります。
移行先を特定製品に偏らせない中立的な提案力を見る
移行先には複数の系統があり、企業ごとに最適な組み合わせは異なります。特定の1製品だけを前提に提案してくる委託先では、選択の幅が狭まるおそれがあります。オンプレミス代替ハイパーバイザ・クラウド事業者のVMware環境・パブリッククラウドの中から比較検討する提案力があるかどうかが評価の分かれ目です。
元請としてのPM機能と契約体系を確認する
移行プロジェクトには、調査・PoC・切替という複数フェーズがあり、フェーズごとに担当会社が分かれると責任範囲が曖昧になりやすいです。元請（プライムベンダー）として一つの契約の下でプロジェクト管理(PM)機能を持つ委託先であれば、フェーズ間の引き継ぎ漏れを抑えながら進めやすくなります。
まとめ — VMware移行判断の3つの軸
本稿では、BroadcomによるVMwareライセンス改定を起点に、継続と移行の判断軸、移行先の選択肢、外注で進める際の工程を整理しました。要点を3つに集約すると次の通りです。
第一に、サポート契約の満了タイミングが、継続か移行かを検討し始める最初の節目になります。第二に、判断はコスト構造・技術要件・運用体制・移行リスクの4軸で比較し、一律の倍率ではなく個別見積もりで確認する必要があります。第三に、移行を選ぶ場合は資産棚卸からPoC・切替計画までを一貫して見通せる専門パートナーへの委託が、リスクを抑えた進め方につながるでしょう。
よくある質問
VMwareの永続ライセンスは今すぐ使えなくなりますか。
いいえ、有効なサポート契約が残っている間は継続して利用できます*2。ただしBroadcomは永続ライセンスのサポート契約の新規更新を提供していないため、契約満了時には新しいライセンス体系への移行を検討する必要があります*2。
VMwareから他の基盤への移行にはどの程度の期間がかかりますか。
移行に必要な期間は、資産の規模・利用している機能の複雑さ・移行先の選択によって大きく異なるため、一律の目安を示すことはできません。まずは自社の資産棚卸とPoCの結果から、個別に見積もることが現実的な進め方です。
無償のハイパーバイザに移行すればコストを抑えられますか。
ソフトウェアライセンス費用は抑えられる可能性がありますが、移行作業・検証・運用体制の再構築にかかるコストは別途発生します。総コストで比較するには、ライセンス費用だけでなく移行・運用の工数も含めて見積もる必要があります。
VMwareを継続する場合に確認しておくべきことは何ですか。
サポート契約の満了日と、更新時に適用されるVCF・VVFの見積もりを早めに確認することが重要です*2。自社が保有するCPUコア数を16コア下限ルールに沿って再計算し、想定コストを把握しておくことも欠かせません*3。
移行を外注する場合、最初に依頼すべき作業は何ですか。
最初に依頼すべきは、現行のVMware資産と依存関係を洗い出す棚卸調査です。棚卸の結果をもとに移行先候補を絞り込み、PoCで検証してから切替計画を策定する順序で進めると、想定外の停止リスクを抑えられます。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Broadcom Inc.「Broadcom Completes Acquisition of VMware」（broadcom.com、2023年）
- *2 出典：VMware（Broadcom）「VMware End of Availability of Perpetual Licensing and SaaS Services」VMware Cloud Foundation Blog（blogs.vmware.com、2024年）
- *3 出典：Broadcom「Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN」（knowledge.broadcom.com）
- *4 出典：Broadcom「What Is vSphere Foundation?」VMware Cloud Foundation Documentation（techdocs.broadcom.com）
- *5 出典：Google Cloud「Latest service announcements」Google Cloud VMware Engine Documentation（docs.cloud.google.com、2025年）
- *6 出典：Microsoft「Introduction – Azure VMware Solution」Microsoft Learn（learn.microsoft.com）
