• VMware
  • クラウド
  • オンプレミス
  • クラウドネイティブ

脱VMwareか、続VMwareか─いま企業に求められる最適な移行パスの考え方


                                                                        usieze_article.webp

BroadcomによるVMware買収をきっかけに、ライセンス体系や提供方針が大きく変わり、多くの企業でVMwareからの移行検討が現実的な課題となっています。ただし、この問題は「脱VMware」か「続VMware」かの単純な二択で判断できるものではありません。重要なのは、自社のシステム特性や制約、将来のIT戦略を踏まえて、最適な移行パスを見極めることです。

本記事では、VMware問題を単なるライセンス更新ではなく、IT基盤再設計の機会と捉え、脱VMwareと続VMwareの具体的な選択肢や、それぞれに適したケースを解説します。どの選択肢が自社に合うのかを見極めるための判断材料としてご覧ください。

【監修者】小林 朗 (こばやし あきら)

【監修者】小林 朗 (こばやし あきら)

SCSK株式会社 ITインフラサービス事業グループ
データ・AI基盤事業本部 USiZEサービス部 第一課 課長
【経歴】
1999年にCSK(現SCSK)に入社。
ネットワーク/周辺サーバのエンジニアを経て、クラウドサービスの企画・開発・運営を担当。
【資格等】
・ITILv3 Expert/ITIL4 マネージング・プロフェッショナル
・2025 Japan All AWS Certifications Engineers他

VMware問題は「製品の話」ではなく、IT基盤を見直す絶好の機会

VMwareを取り巻く環境の変化。その本質は単なるライセンスや製品の問題にとどまりません。いま企業に求められているのは、仮想基盤の刷新ではなく、IT基盤そのものをどう設計し直すかという視点です。

Broadcom買収で何が変わったのか

BroadcomによるVMware買収で最も大きく変わったのはライセンス体系です。従来の買い切り型からサブスクリプション型への移行に加え、課金単位の変更やOEMライセンスの販売停止などが相次ぎ、更新時に大幅な費用増が発生するケースが増えています。これが、いわゆる「VMware問題」として広く認識されている背景です。

一方で、問題の本質は単なるライセンスコストの上昇ではありません。それは企業にとって仮想基盤をどうするかという個別の話ではなく、どのシステムを守り、どのシステムを変え、将来どこまでモダナイズしていくのかという、IT戦略全体の判断になっているのです。

なぜ今、企業は意思決定を迫られているのか

従来は、オンプレミス中心か、一部の仮想化か、といった比較的シンプルな構成が主流でした。しかし現在は、オンプレミス、パブリッククラウド、ハイブリッドクラウドなど、利用できるITインフラの形態が大きく広がっています。

その一方で、ビジネス側では変化への対応力やスピードが求められ、基幹業務では引き続き高い安定性が求められます。こうした状況にVMware問題が重なったことで、「これを機にどこまで変えるのか」という判断を先送りしにくくなっています。

「脱VMwareか継続か」という二択では判断できない

「脱VMwareか継続か」という二択では判断できない

VMware環境の見直しを検討する際、「脱VMwareか、それとも継続か」という二択で考えてしまいがちですが、実際にはそれほど単純な問題ではありません。VMwareがなぜ使われ続けてきたのかを押さえたうえで、現実的な選択肢を見極めることが重要です。

VMwareが今も選ばれ続ける理由

まず前提として、VMwareは依然として優れた仮想基盤です。仮想化そのものの機能に加え、vMotion、HA(High Availability)、DRS、vCenterによる統合管理、さらにはバックアップや監視製品との連携実績があります。こうした特長があるからこそ、長年にわたり企業システムの標準基盤として使われてきました。

そのため、VMwareを単純に「古い基盤だから移行すべき」と考えるのは適切ではありません。むしろ、高機能であるがゆえに深く使い込まれており、それが移行の難しさにもつながっています。

無理な脱VMwareは失敗に繋がる

そのため、すべての環境を一律に脱VMwareへ向かわせるのは現実的ではありません。VMware特有の機能に強く依存しているシステムでは、代替基盤に移行しても同じ水準の運用や可用性をすぐに再現できるとは限らないためです。また、システムごとに抱えている制約や前提条件によっては、理想通りの移行が難しいケースも少なくありません。こうした点を踏まえずに進めてしまうと、結果的に運用負荷やリスクが増大する可能性があります。

重要なのは、どのシステムを変えるべきか、どのシステムを維持すべきかを整理しながら、最適な移行パスを設計することです。

本記事のポイントをまとめた資料DLおよび、VMware問題にお悩みの方はこちら!

VMware移行は「4つのパターン」で考える

VMware移行は「4つのパターン」で考える

そこで有効になるのが、移行パターンを大きく4つに整理して考えるアプローチです。まず全体像をシンプルに整理したうえで、自社がどの選択肢に当てはまるのかを考えていきましょう。

4つの選択肢の全体像

VMware環境の移行先は、「脱VMwareか続VMwareか」「オンプレミスかクラウドか」という2軸によって、大きく次の4つのパターンに分類できます。

4つの選択肢の全体

パターン1:続VMware×オンプレミス

オンプレミス環境でVMwareを継続する

パターン2:続VMware×クラウド

VMware環境を維持したままクラウドへ移行する

パターン3:脱VMware×オンプレミス

オンプレミス環境を維持したままVMware以外のハイパーバイザーへ移行する

パターン4:脱VMware×クラウド

クラウド基盤を活用しながらVMware以外のハイパーバイザーへ移行する

VMware移行パターンの選び方を判断フローで解説

4つからどれを選択すべきか。それには、現状を踏まえてどの選択肢が最適か、さらに、その移行を今の条件で現実的に実行できるかによって決まります。その分かれ目になるのが、技術的な制約と時間的な制約です。

<移行パスの判断フロー>

<移行パスの判断フロー>

まず確認したいのは、自社のシステムがVMwareの機能にどれだけ依存しているかです。例えばvMotionやHA、DRS、NSXのほか、vCenterによる一元管理などを前提に運用している場合、VMware特有の仕組みに強く依存している状態といえます。

【VMware依存度が高い場合】

他の基盤に移行するには、同じ運用を再現するためのコストや工数が大きくなります。そのため無理に脱VMwareを目指すよりも、VMwareを使い続ける方向で検討しましょう。

【VMware依存度が低い場合】

依存が少ない場合は、他のハイパーバイザーへの移行、すなわち脱VMwareが検討可能です。

次に、システムの制約を確認します。ここでいう制約とは以下のようなものです。

  • レガシーOSの存在
  • ミドルウェア(Oracleなど)のライセンス条件がインフラ構成に強く影響する
  • IPアドレスの変更ができない構成

【システム制約が大きい場合】

これらはすべて、移行先の選択肢や構成変更の自由度を制限する要因となります。クラウド移行やモダナイズは難しくなり、オンプレミスが現実解となります。

【システム制約が少ない場合】

逆に、大きな制約が無い場合は、クラウド移行が有力な選択肢となります。単にクラウドに移すだけではなく、クラウドの特性を最大限に活用したアプローチ―例えばコンテナやクラウドネイティブ(※)など―を検討することも可能です。スケーラビリティや運用効率の向上、最新技術の導入といったクラウドならではのメリットを享受できるため、クラウドを前提とした移行が非常に価値のある選択となります。

ここまでの整理を踏まえると、自社が「VMwareを継続するのか」「脱VMwareを目指せるのか」、さらに「オンプレミスかクラウドか」という方向性が見えてきます。

最後に、すべての判断に影響するのが時間です。ここまでで脱VMwareが最適と分かった場合でも、すぐにその形で移行できるとは限りません。特に脱VMware×クラウドを目指す際、現状オンプレミスで稼働しているシステムであれば、クラウド移行そのものに加えて、仮想基盤の見直しも必要になるため、実現までのハードルが高くなります。ライセンス更新が半年後に迫っている、あるいは検証環境を用意する猶予がないといった時間的な制約がある際は、本来は最適と分かっている移行であっても、現実的には間に合いません。

このような場合には、まずは短期間で実行可能な選択肢を取り、時間を確保することが重要になります。具体的には、一度VMwareを維持したままクラウドへ移行し、その後に改めて脱VMwareを段階的に進めていくといったアプローチです。

つまり、「最終的に目指す姿」と、「いま取れる移行手段」を分けて考える必要があります。4つの選択肢を一度で決めるのではなく、段階的に組み合わせて進めることが現実的な移行の進め方といえるでしょう。

VMware移行の具体策─パターン別に見る最適な進め方

VMware移行の具体策─パターン別に見る最適な進め方

ここからは、前章の判断結果を実際にどう実現していくのか、パターン別の進め方と具体的なソリューションを見ていきます。

【続VMware】VMwareをオンプレミスで継続する場合の進め方

このパターンは、前章の判断フローで「VMware依存度が高く、かつ構成変更の自由度が低い」システムに当てはまります。最もリスクの低い選択肢ではあるものの、Broadcom買収後のコスト問題や将来の柔軟性という観点では、根本解決にはなりにくいです。そのためこの選択肢はどうしても大きく変えられないシステムの現実解です。そのため、現状維持にとどめるのではなく、将来的なクラウド移行や脱VMwareに向けたロードマップを並行して考えることが重要です。

SCSKでは、ハードウェア更改や運用改善をどう行うか、将来どのタイミングで別の選択肢に移るべきかも含めて、短期・中長期の両面でSI構築や提案を行っています。VMware問題にお困りの方はまずはお気軽にご相談ください。

【続VMware】VMware環境を維持したままクラウドへ移行する場合の進め方

【続VMware】VMware環境を維持したままクラウドへ移行する場合の進め方

こちらは、「VMwareへの依存度が高く、今すぐ脱VMwareするのは難しい」「でもオンプレミスのまま留まり続けるのも避けたい」、あるいはクラウドのスピード感や柔軟性などのメリットを求める企業に向いています。オンプレミスの制約から解放され移行の選択肢を広げることで、いわば「駆け込み寺」として、中長期のあるべき姿を考えるための時間を確保するアプローチです。具体的な方法には以下の2つがあります。

メガクラウド事業者が提供するVMware基盤へ移行する

一つ目は、AWS、Azure、Google Cloud、Oracle Cloudなどが提供するVMware基盤(例:Amazon Elastic VMware Service、Azure VMware Solutionなど)を活用する方法です。すでに特定のクラウドを利用している、あるいは今後そこへ寄せる方針が決まっている企業では、このルートが有力です。既存のVMware運用を大きく崩さずにクラウドへ移せるため、移行の影響を抑えやすい点がメリットです。

一方で、最低ホスト台数○台以上という条件や、ネットワークやライセンス運用に一定の制約があります。そのため小規模構成(コスト)や柔軟性を重視するケースでは適さない場合もあります。

VMwareベースの国産クラウドへ移行する(USiZEなど)

そこでもう一つの選択肢となるのが、VMwareをそのまま使える国産クラウド(例:USiZE※後述)へ移行する方法です。メガクラウド以外にも、VMware環境に最適化されたサービスを提供するクラウドはさまざまあります。

このタイプのクラウドは、仮想マシン(VM)単位で柔軟に利用できる、小規模構成から始められる、既存環境の変更を最小限に抑えやすいといった特徴があります。特に、短期間で移行を完了しつつ、将来の構成を検討するための時間を確保したいケースで、まず現行環境をそのままの形でクラウドへ移行するという用途に向いています。

VMwareのクラウド移行へお困りの方へ

SCSKでは5つのサービス提供が可能です。

提供事業者 サービス名称
SCSK USiZE(ユーサイズ)
Amazon Web Services Amazon Elastic VMware Service(EVS)
Microsoft Azure Azure VMware Solution(AVS)
Google Cloud Google Cloud VMware Engine(GCVE)
Oracle Cloud Infrastructure Oracle Cloud VMware Solution(OCVS)

SCSKでは、既述の4大メガクラウド/パブリッククラウド(AWSAzureGoogle CloudOCI)に加え、国産クラウド「USiZE」も含めた選択肢をフラットに提案いたします。特定のクラウドに寄せるのか、それとも一度中立的な基盤へ移行するのか、さらにはその後の脱VMwareをどのように進めるのかといった観点まで含め、短期的な移行と中長期の最適化を一体で設計いたします。

(参考)USiZEのご紹介

データ主権を担保したソブリンクラウド ユーサイズ

データ主権を担保したソブリンクラウド ユーサイズ

SCSKが提供する国産のソブリンクラウドUSiZEは、

  • 最低契約台数の決まりがなく、仮想マシン1台、1か月から利用可能
  • 既存環境(IPアドレスやアプリケーション、レガシーOSなど)をそのまま移行可能
  • マルチクラウド接続(SCNX)により、他クラウドとの連携や段階移行にも対応
  • 物理サーバの占有も可能

といった特徴があり、「まずは環境を移し、その後の最適化を検討する」といった用途に適したクラウド基盤となっています。VMwareベースのクラウド選びや、その先の移行方針でお悩みの方は、ぜひ一度ご相談ください。

【脱VMware】オンプレミスのまま他の仮想基盤へ移行する場合

このパターンは、「VMware依存はそこまで高くない」「しかしクラウド移行は難しい」というシステムに適しています。たとえば、レガシーOSやミドルウェアの制約からオンプレミスを維持せざるを得ないが、VMwareのコストやベンダーロックインは見直したい、という場合です。

移行先となる代表的なハイパーバイザーには、Nutanix、Hyper-V、KVM(Kernel-based Virtual Machine)ベースの仮想基盤、OpenShift Virtualizationが挙げられます。これらのどれを選ぶかには、VMwareの機能依存、今後の展望、コストという3つの軸で検討しましょう。

移行先となる代表的なハイパーバイザーには、Nutanix、Hyper-V、KVM(Kernel-based Virtual Machine)ベースの仮想基盤、OpenShift Virtualizationが挙げられます。

まず、現在VMwareの機能を広く活用している場合、おすすめはNutanixです。NutanixはVMwareと同等に近い充実した機能が特徴で、vMotionやHAなどを前提にした運用を行っている環境でも比較的スムーズに移行できます。その上、UIのシンプルさやHCIによる統合管理にも強みがあり、運用効率の向上が期待できます。

なお、Microsoft製品との親和性を重視する際は、Hyper-Vも有力です。Hyper-Vは、Windows ServerやM365などの既存のMicrosoft環境との統合性が高く、ライセンス体系も含めて既存資産を活かしやすい点が特徴です。Microsoft製品を中心にシステムを構成している企業にとって魅力的な選択肢と言えます。

一方で、コストを最優先するならKVMです。KVMはLinuxに標準で組み込まれているオープンソースの仮想化技術です。ライセンス費用自体は無償なのでコストメリットが高い一方、運用や管理機能を自前で整備する必要があるため、しっかりとした技術力と体制が求められます。こうした課題に対し、ベンダーが提供するKVMベースの仮想化基盤(例:HPEのHVM)では、ハードウェアとソフトウェアを含めて最適化され、エンタープライズ用途に整備されています。低コストで運用負荷を軽減したい企業におすすめです。

最後に、今後の展望としてハイブリッドクラウドやクラウドネイティブなどを見据えている場合は、KubernetesベースのOpenShiftが選択肢になります。OpenShiftではVMとコンテナを同じ基盤で扱えるため、今はVMベースだが将来的にはモダナイズしていきたいという企業にとっては、仮想基盤の置き換えと同時に次のステップへの足掛かりを作れます。

SCSKでは、上記でご紹介した4つのハイパーバイザー:Nutanix、Hyper-V、HVM(HPE Morpheus VM Essentials Software)、OpenShiftを全て取り扱っております。お客様環境に最適な仮想基盤にお悩みの方は、まずはお気軽にご相談ください。

【脱VMware】クラウドを前提に仮想基盤を見直す場合の進め方

こちらは前章の判断フローにおいて、「脱VMware」と「クラウド活用」の両方が現実的と整理された場合に該当します。4つのパターンの中でも最も自由度が高く、将来のIT基盤のあり方を含めて抜本的に見直せる領域です。クラウド各社が提供する独自の仮想基盤を利用することになりますが、どのレベルまで任せるか(逆に言うとどこまで自社で管理するか)によって、選ぶべきモデルの種類が異なり、大きく3つに分かれます。移行対象となるシステムの重要度や変更頻度、それに伴う技術負担をもとに、適切なモデルを選択しましょう。

選ぶべきモデルの種類が異なり、大きく3つに分かれます。

IaaS(クラウドリフト):まず移行したい/変更できないシステム

IaaS(Infrastructure as a Service)は上の図の通り、クラウド上のハードウェアをサービスとして利用できるモデルです。ユーザはハードウェアの調達や運用をクラウド事業者に任せ、一方でOSやミドルウェア、アプリケーションの構築・管理は引き続き自社で行えます。従来のオンプレミス運用に近い形を維持できるため、基幹システムのような重要度が高く構成変更のリスクが高いシステムに向いています。

具体的なサービス例:Amazon EC2(AWS)、Virtual Machines(Azure)、Compute Engine(Google Cloud)、OCI Compute(Oracle Cloud)

従来のサーバ構成や仮想環境をそのままクラウドに移行(クラウドリフト)できるため、短期間での導入やリスクを抑えた移行に適しており、「まずクラウドへ移す」手段となります。

CaaS(コンテナ):変更が続き運用負荷を見直したいシステム

CaaS(Containers as a Service)は、クラウド上のコンテナ基盤を利用するアプローチです。IaaSとの違いは、OSやインフラの管理をクラウド側に任せつつ、アプリケーションの実行環境は自由に制御できる点にあります。つまり、インフラ管理の負担を軽減しながら、アプリケーションの柔軟性は維持できる中間的なモデルです。

具体的なサービス例:Amazon EKS/ AWS Fargate(AWS)、AKS(Azure Kubernetes Service)/Azure Container Apps(Azure)、GKE(Google Kubernetes Engine)(Google Cloud)

例えば、業務システムの中でも今後も機能追加や改善を続けていくシステムのように、IaaSでは運用負荷が大きいが、PaaS(後述)ほど制約は受けたくない、という場合に適しており、運用負荷と自由度のバランスを取りたい企業に向いています。

PaaS(クラウドネイティブ):作り変えを前提としたシステム

PaaS(Platform as a Service)は、アプリケーションのコード以外の大部分をクラウド側に任せるモデルです。インフラ、OS、ミドルウェアの管理が不要なため、開発スピードの向上や運用負荷の大幅な削減が可能になります。

具体的なサービス例:Lambda/RDS(AWS)、App Service/Azure SQL Database(Azure)、App Engine/Cloud SQL(Google Cloud)、OCI Functions(Oracle Cloud)

このモデルは、最もクラウドネイティブなアプローチであり、スケーラビリティや俊敏性に優れる一方で、ミドルウェアや構成に一定の制約があるため、アプリケーションの設計変更が前提となります。そのため、既存システムの移行というよりも、新規開発やリニューアル(見直し)のタイミングで採用されるケースが一般的です。

VMwareの移行をクラウドで進める際は、どこまでを自社で管理し続けるのかという前提を見直し、システム特性や開発・運用体制に合わせて、どのレベルまでクラウドに任せるのかを見極めることが重要です。

このように、VMwareの移行をクラウドで進める際は、どこまでを自社で管理し続けるのかという前提を見直し、システム特性や開発・運用体制に合わせて、どのレベルまでクラウドに任せるのかを見極めることが重要です。

SCSKでは、お客様環境とクラウド各社のIaaS/CaaS/PaaSソリューションの特性を踏まえ、どのクラウドを選択すべきか、どこをクラウドに任せるべきかといった設計から、移行・運用までを一貫して支援可能です。

VMwareからの移行方針やクラウド選定/サービス選定でお悩みの方は、ぜひ一度ご相談ください。

まとめ:VMware問題はIT戦略全体を設計し直す機会

まとめ:VMware問題はIT戦略全体を設計し直す機会

本記事では、VMwareを取り巻く環境の変化を踏まえ、「脱VMwareか、続VMwareか」という単純な二択ではなく、システムごとの特性や制約に応じたゴール設定と移行パスの考え方を整理してきました。

重要なのは、「自社の条件でどの移行パスが現実的か」を見極めることです。そのため短期的な移行だけでなく、中長期の最適化を見据え、システムごとに最適な手段を組み合わせながら、段階的に進めるという視点で、全体を設計することが求められます。VMware問題とは、単なる仮想基盤の置き換えの話ではなく、IT基盤全体の在り方を見直す取り組みと言えるでしょう。

SCSKでは、こうした検討に対して、現状整理から移行方針の策定、構築・運用まで一貫して支援しています。VMware移行やクラウド活用の進め方にお悩みの際は、ぜひ一度ご相談ください。

最新情報などをメールでお届けします。
メールマガジン登録

×