VMwareのクラウド移行とは？オンプレミス継続か迷う企業・自治体向けに移行先や手順を解説

1. VMwareのクラウド移行が増えている背景

VMware基盤のクラウド移行は、ライセンスや契約条件の変化、インフラ更新を巡る制約を背景に、多くの企業で検討されるようになっています。

本章では、VMwareのクラウド移行が増えている理由について、次の3つの観点から解説します。

• ライセンス変更でオンプレミス運用の負担が増している
• ハード老朽化やDC（データセンター）契約更新が迫っている
• BCPやコスト最適化が経営課題になっている

【関連コラム】VMware買収によるユーザーへの影響とは

1-1. ライセンス変更でオンプレミス運用の負担が増している

BroadcomによるVMware買収後、ライセンス体系が再編され、従来の永続ライセンスは新規販売が終了しました。現在はサブスクリプション型を中心とした契約形態に移行しており、オンプレミス環境を長期間維持する場合でも、定期的な契約更新や費用の見直しが避けられない状況となっています。

さらに、製品エディションの統合が進んだことで、必要な機能だけを選んで利用する運用は難しくなっています。中堅規模の環境でも、VMware vSphere Foundation（VVF）やVMware Cloud Foundation（VCF）などのパッケージを軸に構成を検討するケースが増えており、更新費用や契約内容の予測が立てにくく、運用に対する不安を感じる企業も少なくありません。

このような変化の中で、従来通りの方法でオンプレミス環境を維持し続けることは、コストや契約条件の変動リスクを避けられない状況になっています。更新のたびに対応を迫られる状況を回避するために、クラウド上でVMwareを運用する選択肢が検討されることが増えており、これは近年の特徴的な傾向と言えるでしょう。

1-2. ハード老朽化やDC（データセンター）契約更新が迫っている

ライセンス面の制約に加えて、物理インフラを取り巻く環境もVMware環境の見直しを後押ししています。オンプレミス環境では、物理サーバーの保守期限に合わせて、数年ごとの機器入れ替えが必要です。これに伴い、調達、設計、構築、設置といった工程が発生し、そのたびに一定期間インフラ対応に人手が取られます。

一方、インフラを担当できる人材が限られているため、物理作業を伴う更新作業の負担が増してきています。さらに、サーバー機器の価格上昇や納期の長期化により、計画通りに更改作業が進められないケースも増えています。

データセンター契約の更新時期が重なると、機器更新とあわせて大きな費用が一度に発生します。こうした設備投資が前提となる運用を続ける場合、数年先を見越した費用見通しや更新計画を立てる必要があり、社内調整の負担が増すこともあります。

このような状況下で、ハードウェアや設置場所に依存せず、VMware環境を柔軟に維持できる手段としてクラウド移行を検討するケースが増えています。クラウドでは、物理機器の更新時期に影響されることなく、必要に応じてリソースを調整できるため、将来のシステム拡張や運用継続の計画において重要な要素となります。

1-3. BCPやコスト最適化が経営課題になっている

ライセンスや設備更新に加え、事業継続（BCP）やコスト管理の観点から、IT基盤の見直しが求められるケースが増えています。特に、災害や障害発生時に業務を止めないことはもちろん、「停止した場合にどこまで影響が及ぶのか」「どの程度の時間で復旧できるのか」といった点は、経営陣が押さえておくべき重要な課題です。

オンプレミス環境でBCP対策を講じる場合、遠隔地への設備配置やバックアップ基盤の構築が必須ですが、その分設備費や運用負荷が増大します。対応範囲を広げるほど、投資規模も膨らみ、想定した対策が実際に実装できるかどうかにギャップが生じる場合もあります。

一方、クラウド環境では、地理的に離れたリージョンを利用して拠点分散や冗長構成を迅速に構築できます。自前で可用性やバックアップの仕組みを作るのではなく、提供されているサービスを組み合わせて活用できる点は、オンプレミス環境と大きな違いです。

さらに、オンプレミス環境では、サーバー本体の価格だけでなく、電力や空調、保守対応、障害時の人員確保といった周辺コストが継続的に発生します。特に公共機関や大規模組織では、各種ガイドラインへの対応やネットワークの制約も加わり、運用が複雑になります。結果として、「限られた予算内でどこまで対策を講じるか」を都度説明する必要があり、基盤維持が負担になってしまうケースも少なくありません。

このような背景から、設備投資を抑えつつ必要なリソースを段階的に確保できる「クラウドでのVMware活用」が検討されています。BCP対策とコスト管理を同時に進めるため、クラウド移行を含めた基盤見直しが避けて通れない課題となっているのです。

【関連コラム】クラウド構築をベンダーに外注することによるコスト削減と効率化の実現

VMwareの技術を活用したクラウド基盤「地域エッジクラウド タイプV」の資料はこちら

2. VMwareのクラウド移行の選択肢

VMware基盤をクラウドへ移行する際は、複数のパブリッククラウドから提供される専用サービスの中から、自社の状況に合うものを選ぶ必要があります。

ここでは、VMwareのクラウド移行における代表的な選択肢と、それぞれが向いているケースについて解説します。

【関連コラム】脱？続？VMwareライセンス改定に対する市場の反応を調査してみた

2-1. 既存環境を活かして移行したい場合は「VMware Cloud on AWS」

VMware Cloud on AWSは、AWS上でVMware環境をサービスとして利用できる形で提供します。オンプレミスで使ってきたvSphere（仮想化基盤）やvCenter（仮想化管理ツール）の操作体系を保ったままクラウドへ移せるため、移行時の変更範囲を抑えたいケースに向いている選択肢です。

物理基盤の運用やホスト管理を自社で担う必要がないため、インフラ更改やデータセンター対応に伴う作業を抑えつつ、既存の運用手順を大きく変えずに環境を切り替えられます。

また、VMware HCXが標準機能として利用できる点も特徴です。L2延伸（離れた拠点間を同じLANネットワーク内にいるかのような状態でつなぐ技術）を利用すれば、IPアドレスを維持したまま仮想マシンを移行でき、アプリケーション修正やネットワーク変更を初期段階で行わずに進められます。

移行期限が決まっている場合や、まずは現行の構成を保ったままクラウドへ移したいケースで検討されることが多い方法です。

2-2. AWS上でVCFを自社運用に近い形で使いたい場合は「Amazon EVS」

Amazon Elastic VMware Service（Amazon EVS）は、AWSアカウント内のVPC上でVMware環境を動かせるサービスです。VMware Cloud on AWSのように運用を任せる形ではなく、ハイパーバイザーやネットワーク構成まで含めて、利用者側で管理できる範囲が広い点がメリットになります。

もう一つの利点は、VMware Cloud Foundation（VCF）のライセンスを持ち込めることです。既存のVMware契約を継続しながらAWS上で環境を展開できるため、ライセンスの組み替えで手戻りが出にくく、移行計画を立てやすくなります。

また、VPC（仮想プライベートクラウド）設計やAWSの周辺サービスと組み合わせた構成を取りやすく、外部ストレージやバックアップなどを含めて、要件に合わせて作り込みやすい点も強みです。AWS上でVMwareを維持しつつ、周辺システム連携や構成の柔軟性を重視したいケースでは有効な選択肢になります。

一方で、管理できる範囲が広い分、運用作業の受け持ちも増えます。体制や運用手順を用意できるか、どこまで自社側で運用を回すかを先に決めたうえで進めることが重要です。

2-3. Azure連携を前提にVMwareを移行する場合は「Azure VMware Solution」

Azure VMware Solution（AVS）は、Microsoft Azure上でVMware環境を動かせるサービスです。Windows ServerやSQL Serverを中心に運用している環境では、既存の運用手順を大きく変えずに移行でき、移行後もMicrosoft側の運用サービスとつなげられる点がメリットになります。

Azure Hybrid Benefit（購入済みのOSライセンスをAzureへ持ち込み、利用料を安くできる割引制度）を使えば、すでに保有しているWindows Serverライセンスをクラウド側でも活用できます。新たにライセンスを買い直す必要を減らせるため、移行に伴う費用の跳ね上がりを抑えられます。

さらに、Azure BackupやAzure Monitorと連携することで、バックアップや監視をAzure側のサービスに寄せた構成が取れます。その結果、VMwareとAzureでバックアップや監視の運用を二重に持たずに済みます。

Microsoft Entra IDと連携できる点も、Microsoft製品を中心に運用している企業にとってはメリットです。ID管理やアクセス制御をMicrosoft側に寄せられるため、運用の分断を減らし、将来的にガバメントクラウドを見据える自治体でも話を進めやすい選択肢になります。

2-4. 要件に合うクラウドでVMwareを運用したい場合は「GCVE／OCVS」

Google Cloud VMware Engine（GCVE）とOracle Cloud VMware Solution（OCVS）は、特定のクラウド上でVMware環境を動かすサービスです。どちらも汎用的な移行先というより、性能や運用条件に明確な要件がある場合に候補に挙がります。

GCVEは、Google Cloudの分析系サービスと同じ環境内でつなげられるため、移行後に別基盤へデータを移し直す手間を減らし、早い段階で分析・活用まで進めやすくなります。VMware基盤を移したあと「次にデータ活用の基盤を作る」という二度手間を避けたいケースで活躍します。

一方、OCVSはハイパーバイザーのルート権限を利用でき、オンプレミスに近い運用条件を維持できる点が強みです。既存の設計変更を増やしたくない場合や、Oracle Databaseを含む基幹系の構成変更を最小限にして移行したいケースでは、有力な選択肢になります。

2-5. VMwareを維持しつつ一部刷新する場合は段階的なモダナイズを検討

VMware基盤をすべてそのまま使い続けるのではなく、移行後のライセンス費用や将来の選択肢を見据えて、段階的に構成を見直す進め方も有効です。特に、短期間での全面刷新が難しい場合でも、移行と刷新を分けて進められる点が利点になります。

初期段階では、VMware環境をそのままクラウド上で動かせる「VMware系クラウドサービス（例：Azure VMware Solutionなど）」を利用して移行時の手戻りを最小限に抑え、その後、更新タイミングに合わせて、影響の少ないワークロードから順次、AWSやAzureの標準IaaSへ移行します。Webサーバーや開発・検証環境から始めることで、業務への影響を抑えながら費用削減を進めやすくなります。

この方法では、期限対応を最優先にしつつ、将来的にVMware依存を減らす道を残しておくことができます。

VMwareの技術を活用したクラウド基盤「地域エッジクラウド タイプV」の資料はこちら

3. Vmwareのクラウド移行のメリット

クラウド移行の検討を進めるうえでは、「移行できるか」だけでなく、「移行した後に何が変わるのか」を具体的に把握しておくことも重要です。

ここでは、VMware基盤をクラウドへ移行した場合に得られる主なメリットを解説します。

• 更改・保守・調達の負担を軽減できる
• 計画次第で段階的な移行を進めやすい
• BCP／DR（Disaster Recovery：災害復旧）を実装しやすい
• 運用系サービスをクラウドと連携しやすい

3-1. 更改・保守・調達の負担を軽減できる

VMware環境をクラウドへ移行すると、ハードウェアの更改や保守対応、調達に伴う作業を大きく減らせます。機器選定や見積取得、発注、設置といった工程を都度回す必要がなくなり、インフラ更新にかかる手間を抑えられます。

オンプレミス環境では、ハードウェア更改や保守期限にあわせて、構築・入替・調整作業が一時期に集中しがちです。一方、クラウドでは、サーバーの追加や性能変更を管理画面から随時行えるため、作業を特定のタイミングにまとめる必要がありません。故障対応やデータセンター作業、電力・空調といった設備面の手配も不要となり、運用側の対応範囲を絞れます。

こうした作業を減らすことで、インフラ担当者が定期的な更改作業や設備対応に追われる場面を減らせます。その結果、日常運用を維持したまま、障害対応や改善作業にリソースを割きやすくなります。

3-2. 計画次第で段階的な移行を進めやすい

VMwareを活用したクラウド移行は、環境を一気に切り替えずに済む点が大きな利点です。まずは影響の小さい範囲から移し、問題がなければ次の範囲へ広げる、という進め方が取りやすくなります。

多くのVMwareクラウドサービスでは、オンプレミスとクラウドをネットワークで接続し、仮想マシンをクラウド側へ移せます。IPアドレスを保ったまま移行できる構成を選べば、移行のためのネットワーク変更やアプリ修正を先に入れずに済みます。移行に合わせて大きく手を入れない分、切り替え作業に集中できます。

進め方としては、まず開発・検証などの周辺環境で手順を固め、影響の小さい業務から本番へ広げていきます。切り替え後に問題が発生した場合でも、仮想マシン単位で切り戻しが可能なため、業務停止が長期化するリスクを抑えられます。

3-3. BCP／DR（Disaster Recovery：災害復旧）を実装しやすい

クラウドへ移行すると、遠隔地データセンターの確保や専用設備の追加といった手配を減らしながら、BCP／DRの構成を組みやすくなります。オンプレミスでDR環境を用意する場合に比べ、拠点や機器を新たに準備する負担を抑えられる点は、対応を急ぐ状況では大きなメリットです。

クラウドでは複数リージョンを利用できるため、本番とは別リージョンへデータを複製し、障害時に切り替える構成を比較的短期間で組めます。バックアップやレプリケーション（リアルタイムでデータの複製を別の場所に作り続ける仕組み）もサービスとして提供されており、個別に専用機器を用意して運用する方式に比べて、設計や運用の手間を抑えやすい点も特長です。

自治体や公共系のように、継続性を重視しつつ大きな設備投資を避けたい組織では、段階的にDRを整備できる点が利点になります。

3-4. 運用系サービスをクラウドと連携しやすい

クラウド移行後は、監視やログ管理、バックアップ、情報セキュリティ対策を、クラウド側で用意されている標準サービスを活用して構成できます。個別に運用ツールを選定・構築する必要がなく、移行後すぐに運用を始められる点がメリットです。

クラウド標準の監視サービスを活用すれば、リソース状況の確認やアラート通知を一元的に管理できます。障害発生時の通知や初動対応をルール化しやすく、夜間や休日の対応負担を減らせます。

情報セキュリティ面でも、WAF（Web Application Firewall）やEDR（Endpoint Detection and Response）などを必要に応じて追加し、ログをまとめて追える状態にすれば、運用確認や監査対応で「追えない」「証跡が出ない」といった詰まりを減らせます。

VMwareの技術を活用したクラウド基盤「地域エッジクラウド タイプV」の資料はこちら

4. Vmwareのクラウド移行の注意点・リスク

前章で挙げたように、VMwareのクラウド移行には多くのメリットがありますが、移行先や構成を選ぶ際に押さえるべき点を見落とすと、コストや運用面で想定外の負荷が生じることもあります。

ここでは、VMwareのクラウド移行を進めるうえで事前に把握しておきたい注意点とリスクを解説します。

• 構成によってはTCO（Total Cost of Ownership：総所有コスト）が増える
• ネットワーク設計の難易度が高い
• 移行後の運用負荷が増える可能性がある
• 契約形態によりサポート範囲が異なる

4-1. 構成によってはTCO（Total Cost of Ownership：総所有コスト）が増える

VMwareのクラウド移行では、環境をそのまま持ち上げるだけの移行を行うと、想定以上にTCOが増えるケースがあります。VMware Cloud on AWSやAzure VMware Solutionは、専用ホストを占有する構成となるため、使われていないリソースを抱えたまま移行すると、その分コストに跳ね返ります。

オンプレミス環境に過剰に割り当てられていた仮想マシンや、稼働率の低いワークロードを精査せずに移すと、「動いていないのに費用だけが発生する」状態になりやすい点には注意が必要です。

さらに、Broadcomによるライセンス体系変更の影響で、実際には使わない機能を含むエディションを選ばざるを得ず、想定より費用が膨らむケースもあります。

コストを抑えるには、すべてをVMware基盤に載せたまま移行しないことが重要です。負荷の低いシステムや用途が限られたものは、ネイティブIaaSへ切り分けることで、全体の費用を抑えられます。

4-2. ネットワーク設計の難易度が高い

ネットワーク設計は、VMwareのクラウド移行でつまずきやすい領域です。既存構成を大きく変えずに移行する場合、アドレス設計や到達性を崩さないために、L2延伸などの方式を検討する必要があります。

L2延伸は移行時の影響を抑えられる反面、オンプレミスとクラウドをまたぐ通信経路が増え、ルーティングやFW境界、DNS（ドメイン名とIPアドレスを紐づけて管理するシステム）の参照先といった設計が複雑になりがちです。通信は成立しているように見えても、遅延や経路の揺れが発生したり、どこで問題が起きているのか特定しにくくなったりする、移行方式とあわせて慎重に設計する必要があります。

また、移行期間中の大量データ転送により既存回線の帯域を圧迫し、業務通信に影響が出るケースもあります。自治体や公共系では、LGWANや閉域網などの制約やガイドライン要件により、使える経路や接続方式が限られるため注意が必要です。

そのため、事前に検証環境で、遅延・帯域・経路（往復）などの通信特性を確認し、段階的に移行範囲を広げていくのが安全です。

4-3. 移行後の運用負荷が増える可能性がある

クラウド移行をすれば、運用が軽くなるとは限りません。パブリッククラウドでは基盤側はクラウド事業者が担う一方で、OSやミドルウェアの保守、バックアップ設定、権限管理、情報セキュリティ設定などは利用者側の作業として残ります。

移行後は、従来の運用ツールに加えてクラウド側の管理機能も併用することになり、監視画面が二つに分かれる・ログの確認先が複数になる・権限管理が別々になるといった形で手間が増えるケースがあります。

さらに、障害時は、最初に「回線なのか、クラウド側の設定なのか、OSなのか、アプリなのか」を切り分ける必要があり、慣れていないと初動が遅れてしまいます。

こうした運用負荷を増やさないためには、移行の段階で「監視はどのツールに集約するか」「ログはどこに集めて検索するか」「バックアップはどの方式で取るか」を決めておくことが有効です。あわせて、権限の管理方法、変更手順、緊急時の連絡ルートまで移行後に合わせて整えておけば、移行後の混乱を抑えられます。

4-4. 契約形態によりサポート範囲が異なる

VMwareのクラウドサービスは、契約形態によってサポート範囲や問い合わせ窓口が変わります。ここを曖昧にしたまま移行すると、障害時に「どこへ連絡すべきか」の確認や切り分けで初動が遅れやすい点に注意が必要です。

たとえば、VMware Cloud on AWSやAzure VMware Solutionは、契約経路によって一次窓口が異なります。障害原因がはっきりしない場合、「ネットワークなのか、クラウド側の基盤なのか、ゲストOSなのか、VMware機能なのか」で確認先が分かれ、やり取りが増えることがあります。

また、Broadcomライセンスを持ち込む（BYOL：Bring Your Own License）場合は、ライセンス契約とサポート条件の組み合わせを事前に確認しておく必要があります。移行する前に「誰に何を問い合わせるか」「どの情報を添えて連絡するか」を決めておけば、障害対応の確認や調整に要する時間を抑えられます。

NTT東日本が提供する「地域エッジクラウド タイプV」の資料はこちら

5. Vmwareからの移行先を選ぶ際の判断ポイント

前章で触れたとおり、VMwareのクラウド移行では選択肢ごとに特性や制約が異なります。メリットだけで進めてしまうと、移行時期や運用面で想定外の調整が必要になることもあります。

そこで本章では、移行先を選ぶ際に押さえておきたい基準について解説します。

• 更新期限までに移行判断が間に合うか
• 基盤・アプリをどこまで刷新するか
• ネットワーク要件を満たせるか
• 中長期TCOにおいて合理的な選択はどれか

5-1. 更新期限までに移行判断が間に合うか

データセンター契約の満了日やサーバー保守の期限まで、実質的に移行に使える期間がどれくらい残っているかは、最初に確認すべきポイントです。期限まで1年を切っている場合、構成を作り込む余裕がなく、移行スピードを優先した選択が必要です。

短期間での移行が前提であれば、既存の仮想マシンを大きく変えずに移せる「VMwareベースのクラウド」が有力な選択肢です。VMware Cloud on AWSやAzure VMware Solution、Amazon EVSは、オンプレミスとの互換性が高く、形式変換や再設計を最小限に抑えられます。

一方で、ネイティブクラウドへの移行は、検証や構成調整に一定の時間がかかります。期限に余裕がない場合は、まずリホスト（システムの構成やプログラムを一切変えずにそのままクラウドへ移すこと）で移行を完了させ、期限対応を終えた上で最適化を進めるといった進め方が現実的です。

5-2. 基盤・アプリをどこまで刷新するか

VMwareのクラウド移行では、すべてのシステムを同じ範囲で刷新する必要はありません。どこまで構成を変えるかを先に決めることで、移行先の選択肢は自然に絞られます。

長期間安定して稼働している基幹系システムは、構成を大きく変えずにVMware環境を維持できるクラウドへ移行する方が、移行リスクを抑えられるケースがあります。一方で、更新頻度が高いWeb系や分析基盤は、ネイティブIaaSやコンテナへ移すことで、構成変更やスケールに対応しやすくなります。

Broadcomによるライセンス変更以降、すべてをVMware基盤に載せ続けると、費用が膨らむ可能性があります。役割が固定されたものと、今後変えていくものを分けて考え、配置を決めることが重要です。

5-3. ネットワーク要件を満たせるか

ネットワーク要件は、移行先を絞り込む際の大きな判断材料になります。とくに、IPアドレスを変更できない仮想マシンが多い場合、選べる移行先は限られます。

IPの維持が必須となる環境では、L2延伸に対応したサービスでなければ対応が難しくなります。自治体や公共系では、これに加えてLGWANや閉域網接続、ガイドライン対応といった条件が重なり、対応できるクラウドや構成がさらに絞られます。

また、オンプレミスとクラウドを併用する期間は、通信遅延や経路の違いが業務に影響するケースがあります。ハイブリッド構成が前提になる場合、その影響を許容できるかどうかも含めて移行先を選ぶ必要があります。

5-4. 中長期TCOにおいて合理的な選択はどれか

移行先を選ぶ際は、初期費用の大小ではなく、3〜5年単位で見たTCOで比較することが欠かせません。この期間で見ないと、移行後に必ず発生するコストを判断に含められないためです。

オンプレミス環境は、移行直後だけを見ると既存資産を使える分、費用が抑えられているように見えます。しかし実際には、ハードウェア更改、仮想化基盤やOSの更新、データセンター利用料や保守対応といった固定費が、数年のうちに確実に積み重なります。

中長期でTCOを捉えておけば、「今いくらか」ではなく、次の更改まで含めてどの選択が最も合理的かという軸で説明できます。この説明ができるかどうかで、移行判断の納得感は大きく変わります。

NTT東日本が提供する「地域エッジクラウド タイプV」の資料はこちら

6. 失敗しないVmwareのクラウド移行の進め方

移行先の方向性が決まっても、進め方を誤るとコスト増や手戻りにつながります。そこで本章では、VMware環境のクラウド移行を進める際に押さえておきたい工程を、5つのステップに分けて解説します。

1. 資産棚卸しと依存関係の整理
2. サイジングとTCOの見積もり
3. PoCで移行・運用を事前検証
4. 移行方式と切り替え・切り戻し設計
5. 段階的に移行し運用を最適化

6-1. 資産棚卸しと依存関係の整理

最初に確認すべきなのは、「どのシステムが、どこと通信して動いているか」です。アプリケーションとデータベース、外部システムのつながりを把握しないまま切り離して移行すると、通信エラーや性能低下が発生しやすくなります。

具体的には、vCenterの稼働情報や通信状況をもとに、仮想マシン同士や外部との接続関係を洗い出します。あわせて、外部ベンダーとの専用線接続や、オンプレミス機器に依存した通信が残っていないかも確認しておくと、移行後の手戻りを防げます。

自治体の場合は、LGWAN系とインターネット系で通信経路が分かれているため、どのシステムがどちらに属しているかを明確にしておくことが欠かせません。この切り分けが曖昧なまま進めると、移行方式の見直しが必要になるケースがあります。

6-2. サイジングとTCOの見積もり

オンプレミス環境の最大割り当てをそのまま前提にすると、クラウド移行後も使われないリソースに費用を払い続けることになります。そのため、実際の稼働状況をもとに、必要なリソース量を見直すことが欠かせません。

CPUやメモリの使用状況を確認し、常時使われていない分を削ったうえで、必要なホスト構成を決めます。あわせて、ライセンス費用や保守費、運用にかかる工数を含めて見積もっておくと、想定と実際のコストに差が出るリスクを抑えられます。

経営層への説明では、サーバー単価だけを見るのではなく、リスク回避や日常運用にかかる手間まで含めた費用感を提示しておくと、移行後の追加調整を最小限に抑えられます。

6-3. PoC（Proof of Concept：概念実証）で移行・運用を事前検証

本番移行の前に余裕がある場合は、影響の少ない仮想マシンでPoCを行い、設計通りに動くかを事前に確認しておくと安心です。通信が想定通り成立するか、移行ツールの処理時間が許容範囲かなど、本番で止まりやすいポイントを先に確認することが目的になります。

L2延伸を使ったIP維持の挙動や、閉域網経由でのアクセス可否、バックアップ処理にかかる時間などは、設計書だけでは判断しづらい項目です。PoCで一度動かしておくことで、移行手順や切り替えの際の注意点を具体化できます。

社内で対応が難しい場合は、パートナーと役割を分けて進めることで、移行後の運用を想定した確認まで進められます。

6-4. 移行方式と切り替え・切り戻し設計

まず、システムごとにどれくらいの停止を許容できるかを明確にします。この点が決まっていないと、移行方式を選びきれず、当日の対応が後手に回りがちです。あわせて、想定通りに進まなかった場合にどの時点で戻すかをあらかじめ決めておきます。

停止を極力避けたいシステムでは、VMware HCXなどを使った段階的な切り替えが選択肢になります。一方で、停止可能なシステムまで同じ方式を取ると手順が複雑になりやすいため、一括移行と使い分ける方が現実的です。

移行当日に迷わないためには、Go／No-Go（このまま次に進むか、中止・差し戻すかを判断する意思決定）の判断基準を事前に定めておくことが欠かせません。スナップショットやレプリケーションを活用した戻し方を含め、どこまで進んだら切り戻すかを文書にしておけば、当日の対応がぶれにくくなります。

6-5. 段階的に移行し運用を最適化

全環境を一度に移行するのではなく、開発や検証環境など影響の小さい領域から順に移行していきます。先に非本番環境で移行手順や運用を確認しておくことで、本番移行時の手戻りを抑えられます。

非本番環境、情報系、本番基幹系の順で進めれば、障害が発生した場合でも影響範囲を限定できます。移行後は、夜間停止や監視の自動化など、クラウド側で対応できる運用を徐々に取り入れることで、日常運用の負担を抑えられます。

VMware環境をクラウドへ移したあとも、すぐに全体を作り替える必要はありません。まずは安定稼働を優先し、必要な範囲から対応していくことで、過度な運用負荷をかけずに運用を継続できます。

NTT東日本が提供する「地域エッジクラウド タイプV」の資料はこちら

7. VMware移行後も安定運用を狙う「地域エッジクラウド」という選択肢

VMwareのライセンス変更を受けて、「このまま使い続けるのか」「別基盤へ切り替えるのか」で判断を迫られている企業は少なくありません。しかし、短期間でVMwareから完全に切り替えるには、移行費用やアプリ改修、運用変更の負担が大きく、現実的ではないケースも多いのが実情です。

そうした中で選択肢として検討されているのが、NTT東日本が提供する「地域エッジクラウド」です。VMware技術を用いたクラウド基盤を国内データセンターで提供しており、既存のvSphere構成や運用を大きく変えずに移行できます。

オンプレミスと同様の操作感を保ちながら、ハードウェア保守や設備管理はクラウド側に任せられるため、運用負担だけを切り離す形を取りやすい点が特徴です。また、閉域網接続や国内運用を前提としているため、情報セキュリティ要件やデータの取り扱いに制約がある企業や自治体でも導入しやすくなっています。

VMwareを今すぐやめるか、使い続けるかを決めきれない場合でも、安定運用を保ったまま、将来の選択肢を残すという選び方は可能です。将来的なモダナイズや別基盤への移行を見据えつつ、まずは現行環境の負担を軽くしたい場合は、ぜひ地域エッジクラウドの活用をご検討ください。

NTT東日本が提供する「地域エッジクラウド タイプV」の資料はこちら

8. まとめ

VMwareのライセンス変更をきっかけに、クラウド移行を急いで検討するケースが増えています。ただし、移行を急ぐあまり、構成や運用を十分に確認しないまま進めると、コスト増や運用負荷といった別の問題が生じる可能性があります。

本コラムで整理してきた通り、移行期限・ネットワーク要件・運用体制を踏まえたうえで、「どこまで変えるか」「どこは維持するか」を切り分けて進めることが重要です。

VMwareを継続するか、別基盤へ移行するかの判断は避けられませんが、すべてを一度に切り替える必要はありません。まずは現行環境を安定させ、将来の選択肢を狭めない形で移行を進めることで、無理のないクラウド活用につながります。

• 本コラムに記載されてる会社名、サービス名、商品名は、各社の商標または登録商標です。