Get a free GCVE migration assessment →
Who this guide is for
This is written for the team that has a Broadcom renewal on the calendar, already runs meaningful workloads on Google Cloud, and wants to know what a move to GCVE actually involves before committing to a multi-year term. It assumes you run vSphere today and care more about a defensible plan than a vendor pitch.
If you are still deciding whether GCVE belongs on the shortlist at all, start with the GCVE pricing and comparison page, which covers node rates, the three-node minimum, and committed-use discounts. This guide picks up after that decision and covers the migration itself.
What actually moves the VMs
GCVE runs a genuine VMware stack, so migration is a relocation rather than a conversion. That single fact removes most of the risk that makes Proxmox, Hyper-V, or OpenShift projects long. VMware HCX is the engine:
- HCX bulk migration. Replicates VMs in the background and cuts them over during a scheduled window. The workhorse for the bulk of an estate, and the option that tolerates the widest range of source versions.
- HCX vMotion. Live migration with no downtime, for the handful of workloads that genuinely cannot take a reboot. Slower per VM, so reserve it rather than defaulting to it.
- Replication-assisted vMotion. Combines the two: bulk-style replication followed by a live switchover. Useful for large VMs where a full vMotion would run too long.
- HCX Network Extension. Stretches your existing layer 2 segments into the private cloud so VMs keep their IP addresses. This is what makes phased waves possible, because a half-migrated application still functions.
The licensing catch that changes the business case
This is the part that reframes the whole project. Google no longer sells a fully licensed committed-use option for new GCVE purchases. New commitments are portable license, which means you bring VMware Cloud Foundation licensing yourself. Older fully licensed and legacy commitments remain valid, but they are not available for new deals.
The practical consequences:
- You are still a Broadcom customer. If the objective was to end the Broadcom relationship, GCVE does not do it. You keep negotiating VCF licensing, just with your hosts in a Google region.
- The node rate is not the cost. Google's published per-node price excludes your VCF licensing entirely, so any comparison built on node rates alone understates GCVE by a wide margin.
- Two renewal clocks. You now manage a Google commitment term and a Broadcom licensing term that will not line up. Misaligned expiries are how organizations end up with no leverage on either.
None of this makes GCVE a bad choice. It makes it a specific choice: the right one when the driver is data-center exit or Google adjacency, and the wrong one when the driver is escaping Broadcom pricing. See what changed in VMware licensing for the underlying detail.
Network and storage decisions to make early
| Decision | Options | What it drives |
|---|---|---|
| Connectivity | Cloud VPN or Cloud Interconnect (Dedicated / Partner) | Migration throughput and cutover duration. VPN is fine for pilots and small estates; Interconnect is what large waves need. |
| Lead time | VPN in days, Interconnect in weeks | Usually the single longest pole in the schedule. Order it first, not after discovery. |
| Storage | vSAN on node NVMe, or external Google Cloud NetApp Volumes | Whether capacity growth forces you to buy more nodes than you need for compute. |
| Cluster size | Three-node production minimum; single node for pilots only | The floor on your run cost, regardless of how small the workload is. |
| Identity and tooling | Existing vCenter operations continue | Runbooks, backup agents, and monitoring mostly carry over, which is GCVE's real advantage. |
The storage decision deserves particular attention. Because vSAN capacity is tied to nodes, a storage-heavy estate can hit the capacity ceiling long before the compute ceiling and force you into nodes you have no CPU need for. Decoupling capacity onto external volumes is often the difference between a sensible cluster and an oversized one.
Downtime and wave planning
Sequence by dependency, not by convenience. The pattern that holds up:
- Discovery and dependency mapping. Establish what talks to what before you group anything. Surprise dependencies are the main cause of failed cutover windows.
- Pilot wave. A small, non-critical, self-contained application. The goal is to prove the pairing, throughput, and rollback, not to make progress on volume.
- Bulk waves. Grouped by application boundary so an entire tier moves together. Stretched networking lets you slip a wave without breaking the app.
- Sensitive tier last. Databases, licence-bound appliances, and anything with a hardware dongle or strict latency budget.
- Un-stretch and decommission. Move to native segments, then release the source hardware. The savings only start here.
Use the migration timeline guide for a full schedule template and the migration checklist for the pre-cutover items that get forgotten.
Cost, risk, and timeline
| Dimension | What to expect |
|---|---|
| Typical project length | Six to sixteen weeks for a straightforward estate. Interconnect lead time and change-window availability dominate, not the migration tooling. |
| Migration effort | Low relative to any conversion-based path, because no VM is re-platformed. |
| Run cost floor | Three nodes minimum, plus your own VCF licensing, plus storage, backup, IP addresses, and egress. Committed-use discounts apply to node usage only. |
| Commitment risk | Google commitments cannot be cancelled. Size for the estate you will have after cleanup, not the one you have during migration. |
| Biggest hidden cost | Outbound data transfer on hybrid patterns that were free when both ends sat in your own data center. |
For the per-VM project math that applies to any destination, see the migration cost guide, and model three-year totals in the cost calculator.
Common mistakes
- Comparing Google's node rate to your current all-in cost. The node rate excludes VCF licensing. This is the single most common way GCVE gets made to look cheaper than it is.
- Sizing on a single-node pilot. Production starts at three nodes. A pilot proves the process, never the price.
- Ordering Interconnect after discovery. It has the longest lead time of anything in the project and it gates every large wave.
- Treating stretched networking as permanent. It quietly keeps you tied to the data center you were trying to leave.
- Letting commitment terms drift apart. A three-year Google commitment paired with a one-year Broadcom term hands away your negotiating position on both.
- Migrating the estate you have. Right-sizing and decommissioning before the move is the cheapest capacity reduction available, and it is much harder once you are committed.
Where GCVE fits and where it does not
| Good fit when | Poor fit when |
|---|---|
| You already run significant workloads on Google Cloud and want adjacency | Ending Broadcom licensing is the actual objective |
| A data-center lease or hardware refresh is forcing a deadline | The estate is small enough that a three-node floor dominates the bill |
| The team's vSphere skills and runbooks are worth preserving | You were prepared to re-platform and want the largest possible cost reduction |
| You need to move quickly with minimal application risk | Workloads are storage-heavy with modest compute needs |
| Analytics or AI services in Google Cloud are on the roadmap | You want a single vendor to own both infrastructure and licensing |
The comparison nobody runs: staying on VMware for less
If the driver is Broadcom pricing rather than Google specifically, price the managed-VMware path before committing to a hyperscaler term. A VCSP provider keeps vSphere intact, absorbs the licensing relationship, and avoids both the three-node floor and the portable-license problem. Look at multitenant VMware cloud and the full alternatives matrix before you sign anything multi-year.
How to decide
Compare three-year totals, not migration prices: the status quo (Broadcom renewal times three plus hardware) against GCVE (one-time migration, plus node commitment, plus your VCF licensing, plus storage and egress, times three). Run the numbers in the free cost calculator, or get a priced comparison across GCVE, the other hyperscalers, and managed VMware with a free assessment.
GCVE migration FAQ
Does GCVE require converting VMs?
No. GCVE runs a real vSphere stack, so VMs move without disk-format or hypervisor conversion. This is the main reason it is faster and lower-risk than a Proxmox, Hyper-V, or OpenShift migration.
Can we keep our IP addresses?
Yes, using HCX Network Extension during the migration. Plan the cutover to native NSX segments rather than leaving the stretch in place indefinitely.
Do we still need VMware licenses?
For new committed-use purchases, yes. Google sells portable-license commitments, so you supply VMware Cloud Foundation licensing. Legacy fully licensed commitments remain valid but are no longer sold.
What is the smallest production GCVE deployment?
Three nodes. Single-node private clouds exist for pilot work only and should not be used to size the business case.
How long does the project take?
Six to sixteen weeks is typical. Cloud Interconnect provisioning and change-window availability usually set the pace, not the migration tooling.