
本記事のポイント
-
- 移行の成否を左右するのは、移行ツールの操作よりも、仮想マシン・依存関係・移行難度の事前整理です。
- 業務影響を抑えるには、低リスクな環境から段階的に移行し、各段階で切り戻しまで検証することが重要です。
- Moveの前提条件だけでなく、ネットワーク・OS・アプリケーション・バックアップの対応状況まで、事前に確認する必要があります。
VMware から Nutanix への移行は、製品を入れ替えれば終わる作業ではありません。どの仮想マシンをどの順で移すか、移行ツールが対応しない環境をどう扱うか、移行後に何が起きるか。この3つを事前に押さえられるかどうかで、計画の精度が変わります。当社が支援した複数の移行プロジェクトに共通する進め方と、実際に起きたトラブルをまとめます。
VMwareからNutanixへの
移行について相談する ▶
目次
1. 移行を検討した理由
本記事は、当社が支援した複数の移行プロジェクトから、共通する経緯と対処をまとめたものです。いずれも全国に拠点を持つ中堅から大手規模の企業で、業務システムの基盤として VMware vSphere を長年運用していました。仮想マシンの規模は数十台から数百台と幅があります。各社の意向により、社名、業種、規模の特定につながる情報は載せていません。
更新の費用が想定を超えた
検討のきっかけは、いずれのケースもライセンス更新の費用でした。Broadcom による買収後の変更が重なり、次回の更新の見積もりが従来より大きく上がるという状況です。
重なったのは3つの変更です。永続ライセンスからサブスクリプションへの移行、vSphere や NSX を束ねたパッケージ単位の提供、CPU コア単位への課金です。これまで使っていなかった機能の費用も加わるため、経営層への説明の場で問題になります。
こうした状況は、当社が支援した企業に限りません。Gartner は2025年の Market Guide で、2028年までにエンタープライズ規模の VMware 顧客の70%が、仮想化されたワークロードの少なくとも50%を他の基盤へ移すと予測しています。
運用の負担と、製品の見通しが立たないこと
費用だけではありません。vCenter、ESXi、外部ストレージ、バックアップソフトという別々の製品を個別に管理する負担が、情報システム部門の担当者に集中していました。
サーバー、ストレージ、ネットワークが分かれた3層構成では、障害が起きたときの原因の切り分けに時間がかかります。対応が長引くほど、業務への影響が広がります。
買収後の製品の方向が見通せず、5年先を見据えた投資の判断ができないという声もありました。この3つが重なって、移行の検討が始まっています。
更新の見積もりが出てから検討を始めると、選べる範囲が限られます。次回の更新日を確認し、そこから移行の設計、検証、実施に必要な期間を引いてください。数十台の規模で約6か月、数百台では1年から2年かかります。この日を過ぎてから動き始めると、継続以外の選択肢が残りません。
2. Nutanix を選んだ理由
複数の代替製品を比べたうえで Nutanix を採用した企業に共通していたのは、次の3点です。
費用が減る箇所が3つ重なる
VMware 環境では、ESXi のライセンス、外部ストレージの購入と保守、vCenter のライセンス、災害対策用の SRM のライセンスがそれぞれ発生していました。
Nutanix では、ハイパーバイザーの AHV が製品に含まれ、分散ストレージも HCI に組み込まれているため外部ストレージが不要になります。管理ツールの Prism と、災害対策の機能も標準で使えます。
外部ストレージの更新時期が重なっていた企業では、その更新費用を移行で吸収できる形になり、5年間の総額での比較が有利に働きました。ただし、削減額は環境と契約の内容によって変わります。 自社の構成で試算してください。
管理する画面が1つにまとまる
Prism は Web ブラウザーから操作し、仮想マシンの管理、資源の監視、バックアップの設定を1つの画面で行えます。VMware 固有の知識を前提とせずに運用できる点が、人員の限られた情報システム部門で評価されました。
ファームウェアから管理ソフトウェアまでを、1台ずつ順に適用する方式で更新できます。ノードが故障したときのデータの再配置と、復旧後の再配分も自動で行われます。
管理する機器と保守契約が減る
外部ストレージを廃止して HCI の分散ストレージに統合すると、管理する機器の数と保守契約の数が減ります。拡張するときはノードを追加すれば、計算資源とストレージが同時に増えます。
3層構成では、ストレージの障害に外部ストレージのメーカーとの連携が必要でした。HCI に移ると、切り分けと対応の範囲が1社にまとまります。
VMwareからNutanixへの
移行について相談する ▶
3. 移行の進め方
3段階に分ける
全仮想マシンを一度に移さず、優先順位を付けて3段階で進めます。
| 段階 | 対象 | 目的 | 時期の目安 | 選ぶ基準 |
| 1段階目 | 開発環境、検証環境 | 移行手順を固め、運用チームが慣れる | 2か月目 | 業務への影響が小さく、動作確認と切り戻しを安全に行えること |
| 2段階目 | 情報系(ファイルサーバー、グループウェアなど) | 実運用に近い環境で移行の実績を積む | 3〜4か月目 | 影響の範囲が部門内にとどまること |
| 3段階目 | 基幹業務システム | 本番系の移行を完了する | 5〜6か月目 | 停止できる時間を確保できること |
数十台の規模では、全体を約6か月で終えるケースが多くあります。1か月目に現環境の棚卸しと計画の策定、Nutanix 環境の構築を行います。5〜6か月目で基幹業務を移し、旧環境の撤去まで終えます。数百台になると1年から2年かかるため、段階をより細かく分けます。
事前に棚卸しする4項目
移行の成否を分けるのは事前の準備です。プロジェクトの開始時に、次の4項目を棚卸しします。
- 全仮想マシンの OS、CPU、メモリ、ディスク、用途、管理者を一覧にした台帳
- アプリケーション間の通信と共有ストレージの利用状況を示した依存関係の一覧
- 実際の資源の使用状況(過剰な割り当ての是正も移行と同時に行う)
- 仮想マシンごとの移行の難度(互換性の懸念、停止できる時間、依存関係の複雑さ)
依存関係の一覧は、移行の順序を決めるときにそのまま使います。難度の評価は、どの段階に割り当てるかの判断材料になります。
棚卸しの結果は、アプリケーションの担当、ネットワークの担当、セキュリティの担当と共有します。仮想化基盤の変更は全社の業務システムに及ぶため、この3者との合意がないまま段階の割り当てを決めると、後から対象の入れ替えが起きます。
1台あたりの手順
各仮想マシンの移行は、次の6つの手順で進めます。
- 移行対象のスナップショットを取得する(切り戻し用の復帰点を確保する)
- Nutanix Move で移行を実行する(vCenter と Nutanix 環境を接続し、移行タスクを設定する)
- 移行後の動作を確認する(アプリケーションの正常性、ネットワークの疎通、性能)
- DNS と IP を切り替える(必要に応じて名前解決先と接続先を新環境に向ける)
- 一定期間、並行して監視する(旧環境の仮想マシンは停止した状態で残す)
- 旧環境の仮想マシンを削除する(監視の期間に問題がなければ完了とする)

切り戻しの手順は、各段階で必ず用意し、事前に試してください。手順を書いただけで試していない状態で本番に入ると、問題が起きたときに戻す判断ができません。1段階目の開発環境で切り戻しまで一度通しておくと、以降の段階で判断が速くなります。
4. Nutanix Move の前提条件
Nutanix Move は、vSphere 環境から AHV 環境への移行を自動化するツールです。前提条件を先に確認しておくと、作業の工数と失敗の可能性を減らせます。
確認する3点
1つ目は、ネットワークの疎通です。 vCenter が動いている管理ネットワークと、Nutanix の管理ネットワークが通信できる必要があります。分離されている場合は、ルーターを経由させる対応が要ります。
2つ目は、対応する OS です。 Windows Server、RHEL、CentOS など主要な OS は対象ですが、版によって対応の状況が違います。自社の仮想マシンを OS の版ごとに数え、対応表と突き合わせてください。
3つ目は、物理サーバーから仮想化した仮想マシンです。 P2V を経由した古い仮想マシンは、その仮想マシン自体の版やドライバーの構成が移行の障害になることがあります。事前の検証を念入りに行ってください。
操作の流れ
Move の管理コンソールに vCenter のアドレスと認証情報を登録すると、vCenter 配下の仮想マシンが一覧に出ます。対象を選び、移行先のクラスターとネットワークを指定して移行タスクを作ります。
タスクを実行すると、まずデータが Nutanix 側に複製されます。この時点では元の仮想マシンは vSphere 上で動いたままです。複製が終わったらカットオーバーを実行し、元の仮想マシンが停止して Nutanix 上の仮想マシンが起動します。
この停止から起動までの時間が、実際の停止時間になります。 業務への影響が小さい時間帯に実施してください。
移行後は VMware Tools の動作が保証されないため、カットオーバーの後に手動で無効化または削除します。Windows ではサービスの無効化、Linux では open-vm-tools の扱いを確認してから対処します。
5. 実際に起きたトラブルと対処
複数のプロジェクトで繰り返し起きた事象と、その対処、予防策を挙げます。
| 起きたこと | 原因 | 対処 | 予防 |
| 移行後に通信できない | 仮想 NIC のドライバーの違い。vmxnet3 で動いていたゲストが VirtIO に切り替わる | AHV に対応するドライバーへ更新する | 事前の検証環境で、同じ OS の動作を確認しておく |
| 特定のアプリケーションの応答が遅くなる | ストレージの入出力の経路が変わる。外部 SAN の応答時間に合わせていたアプリケーションで起きる | Nutanix 側でデータの配置階層の設定を調整する | 移行後1〜2週間は入出力の監視を強め、しきい値でアラートが出る設定にしておく |
| バックアップの処理が失敗する | 旧バックアップ製品が AHV に対応していない。ESXi 専用の API に依存している製品で起きる | Nutanix 標準のバックアップ機能へ切り替える | 移行の前に、使用中の製品の AHV 対応状況をメーカーに確認する |
3つとも、移行の前に確認しておけば防げます。とくにバックアップ製品の対応状況は、非対応だった場合に製品の入れ替え費用が移行の見積もりに加わります。棚卸しの段階でメーカーに確認し、その結果を費用の試算に反映してください。後から分かると、予算の追加を説明することになります。
6. 移行後に変わったこと
費用
VMware のサブスクリプション費用と、外部ストレージの保守費用が不要になります。3層構成から HCI への統合で、物理機器の総量も減ります。移行の作業費用を含めた5年間の総額で比べても、VMware を継続した場合より下がるケースが多くありました。
削減額は環境と契約の内容によって変わります。 外部ストレージの更新時期が重なっていた企業では、効果が大きくなっています。
運用
管理する画面が、vCenter、ESXi、ストレージ、バックアップソフトの複数から Prism に集約されます。障害の原因の切り分けが1社の範囲で済むようになり、復旧までの時間も短くなります。
1台ずつ順に適用する更新の方式により、従来は計画停止を伴っていた更新作業を業務時間中に行えます。
安定性
HCI の冗長構成と AHV の高可用性の機能により、計画外の停止の頻度が下がります。ストレージの処理の詰まりが解消され、性能も安定します。
ただし、運用が不要になるわけではありません。 監視も、容量の管理も、障害への対応も残ります。減るのは、製品ごとに分かれていた手順の数です。
7. よくある質問
Q. 運用チームが Prism に慣れるまで、どのくらいかかりますか。
基本の操作は1〜2週間で習得できるケースが多くあります。仮想化の基本の考え方は VMware と共通するため、設計の知識はそのまま使えます。書き直しが必要なのは、製品固有の操作手順です。既存の手順書は Prism を前提に全面的に改訂することになりますが、移行の段階と並行して進められます。
Q. アプリケーションが AHV に対応しているかは、どう確認しますか。
アプリケーションのメーカーに直接確認します。対応していない場合は、アプリケーションの更改と移行の時期を合わせる計画が必要になります。この確認は、棚卸しの段階で済ませてください。移行の計画を立てたあとに非対応が分かると、段階の割り当てから組み直すことになります。
Q. ネットワークの構成は、そのまま持ち込めますか。
そのままは持ち込めません。ESXi 環境の構成をそのまま再現しようとせず、AHV 環境に合わせて設計し直すほうが、移行後の問題が減ります。仮想スイッチの設定、VLAN の割り当て、NIC の構成が対象です。
Q. 移行と同時に進めておくとよいことはありますか。
過剰な資源の割り当ての是正と、バックアップ方式の見直しです。どちらも仮想マシンを1台ずつ確認する作業を伴うため、移行の棚卸しと重なります。別々に行うと、同じ確認を2回することになります。
8. まとめ
VMware から Nutanix への移行は、ライセンス費用の上昇をきっかけに始まることが多いものの、進め方を決めるのは製品の選定ではありません。事前の棚卸しの質と、段階を分けた計画の精度です。
進め方は3段階です。開発と検証の環境で手順を固め、情報系で実績を積み、基幹系を移します。1台あたりは、スナップショットの取得から旧環境の削除までの6つの手順を繰り返します。
移行ツールには前提条件があります。管理ネットワークの疎通、対応する OS、P2V を経由した仮想マシンの3点を、棚卸しの段階で確認してください。この3点と、バックアップ製品の対応状況を先に押さえておけば、移行の途中で計画を組み直す事態は避けられます。
VMwareからNutanixへの
移行について相談する ▶
関連記事
VMwareと併存させながら段階的に移行する進め方と検証結果
本記事のポイント 動かせない仮想マシンが [&helli...
HCIとは|VMware代替として検討する前に押さえる仕組みと制約
本記事のポイント HCIは各ノードの内蔵 [&helli...
VMwareとNutanixの比較|構成・費用・運用の3つの違い
本記事のポイント VMware は3層で [&helli...
この記事を書いた人

- 斉藤 朋子
この投稿者の最新の記事
- 2026年9月1日ブログVMwareからNutanixへの移行事例|複数プロジェクトに学ぶ進め方
- 2026年8月27日ブログVMwareと併存させながら段階的に移行する進め方と検証結果
- 2026年8月27日ブログHCIとは|VMware代替として検討する前に押さえる仕組みと制約
- 2026年8月27日ブログVMwareとNutanixの比較|構成・費用・運用の3つの違い