package/vm-migration-to-gcp
Large-Scale VM Migration to GCP
Two thousand-plus virtual machines moved from VMware vSphere to Google Cloud, in waves, with a rollback path that was tested rather than described.
Program design ~$30,000–$45,000 fixed
Starts with Discovery & Scoping
Floors reflect typical engagements. Larger, regulated, or multi-region estates are scoped and quoted after Discovery.
Execution billed at day rate, or $60–120 per VM depending on complexity band.
Where this usually starts
The lease is up in fourteen months, or the hardware refresh quote arrived and it has a number on it that makes the migration business case write itself. Either way there is a date, and between here and the date sit several hundred to several thousand virtual machines that nobody has a complete inventory of.
The inventory is the first surprise. vCenter knows what exists. It does not know which of those machines matter, which are running something that was decommissioned in 2019 but never powered off, or which one has an undocumented dependency on a licence server that lives on a machine three waves later in the plan.
The second surprise is licensing. Windows Server and SQL Server licences bought with software assurance can often move, but only onto sole-tenant nodes, and the cost model on sole-tenant is different enough that it changes which machines should move at all. Getting this wrong is expensive in a way that is not visible until the first full month of billing.
The third is that the first wave costs a multiple of the last. Anyone quoting a flat per-VM rate across the whole estate has either padded the early waves enough to cover the learning curve or is going to run out of budget in month three.
Program design and execution are priced separately, and that is deliberate
Program design is a fixed fee. It covers discovery and dependency mapping, wave planning, migration factory setup, and cutover runbooks — the work that determines whether the execution phase goes well.
Execution is billed at day rate, or per VM within a complexity band. It is not quoted as a flat per-VM rate across the estate, because that number is a fiction. A simple Linux web server with no local state and a well-understood dependency graph is not the same unit of work as a Windows application server with a licence dependency, a local database, and an owner who left the company.
Complexity banding happens during program design, once the dependency map exists. You get a per-band rate and a count of machines in each band, which is a number you can actually plan against.
Discovery and dependency mapping
The inventory comes out of vCenter and gets enriched with what is actually talking to what. Network flow data matters more than documentation here, because documentation describes what the architecture was supposed to be and flow data describes what it is.
The output is a dependency graph and a decommission list. On most estates a meaningful fraction of the machines should not be migrated at all — they are idle, superseded, or serving something nobody uses. Finding them before the migration is cheaper than migrating them and finding them afterwards.
Wave planning
Waves are built from the dependency graph, not from the org chart. Machines that talk to each other move together or the traffic between them crosses the WAN at cutover, which is how a migration that looked fine in testing produces a latency incident on Monday morning.
Each wave gets a schedule, a cutover window, a rollback decision point, and a named owner on your side. The first wave is deliberately small and deliberately low-stakes — its job is to find the things the plan got wrong while the cost of being wrong is low.
The migration factory
Migrate to Virtual Machines is configured and the replication path from vSphere is established. Snapshot-based cutover means machines replicate continuously while still running in the source environment, and the actual cutover window is short — measured in the time it takes to stop the source, sync the final delta, and start the target.
VirtIO driver injection is handled as part of the process rather than discovered during the first Windows cutover. OS licensing is resolved per machine: bring-your-own-licence onto sole-tenant nodes where the terms allow and the economics work, pay-as-you-go where they do not.
Rollback is designed and tested. The source machine is not deleted at cutover. There is a defined window and a defined procedure for going back, and it is exercised during the first wave rather than being a paragraph in a document.
Hypercare
The first waves run with hypercare: elevated support during and after each cutover, with someone who knows the migration path available while the workload settles. Problems in the first forty-eight hours after a cutover are common, usually small, and much cheaper to fix with the person who did the migration still engaged.
What is not included
Application remediation. If an application needs code changes to run correctly after the move, that work belongs to whoever owns the application. Migration moves the machine; it does not fix what runs on it.
Database platform changes. Moving a SQL Server VM to Google Cloud is in scope. Converting it to Cloud SQL or AlloyDB is a different engagement with a different risk profile, and bundling the two is how migrations slip by quarters.
Non-GCP target environments. This is a Google Cloud practice. A migration that is really a multi-cloud programme is better served by someone who does that.
How the engagement runs
- Week 0 Discovery & Scoping Estate size, source platform, licensing position, and target date. Produces the fixed quote for program design.
- Weeks 1–3 Inventory and dependency mapping vCenter inventory enriched with network flow data. Dependency graph built. Decommission candidates identified and confirmed with application owners.
- Weeks 4–5 Wave plan and complexity banding Waves built from the dependency graph, each with a cutover window and rollback decision point. Machines banded by complexity, producing per-band execution rates.
- Weeks 6–7 Migration factory M2VM configured, replication established from vSphere, target landing structure confirmed. Licensing decisions resolved per band, including any sole-tenant node requirement.
- Week 8 Runbooks and pilot wave Cutover runbooks delivered. Pilot wave executed end to end, including a tested rollback, before the plan is committed to.
- Execution Waves, with hypercare Waves run to the schedule with hypercare through the early ones. Billed at day rate or per VM by band, against the plan produced above.
These figures are starting points, not quotes. Final pricing depends on the size and complexity of your estate and is fixed in writing at the end of Discovery & Scoping.
What this engagement does not cover
Named here rather than discovered later. This is the list that makes the fixed price hold when scope starts moving.
- application remediation
- database platform changes
- non-GCP target environments
What this is based on
- 2,000+ VMs migrated to Google Cloud using Migrate to Virtual Machines with snapshot-based cutover, for a national logistics operator.
- VirtIO driver injection and OS licensing handling across mixed Windows and Linux estates.
- Sole-tenant node deployments for bring-your-own-licence positions.
- Google Cloud Professional Cloud Architect and Professional Network Engineer.
What buyers ask
Our source is VMware vSphere. Does that change anything?
It is the expected case. The 2,000+ VM programme behind this practice ran from VMware vSphere to Google Cloud using Migrate to Virtual Machines, and the tooling, the driver handling, and the cutover pattern are all built around that path.
Other source hypervisors are possible but are scoped case by case, because the replication path and the driver work differ.
Why not quote a single per-VM price for the whole estate?
Because the first wave costs several times what the last one does, and a blended rate across the estate is either padded at the front — in which case you are overpaying for the easy machines — or accurate at the front and loss-making at the back, in which case the engagement gets renegotiated mid-programme.
Complexity banding produces a rate per band and a machine count per band after dependency mapping. That is a real number you can budget against, and it arrives before you commit to execution.
Can we keep our Windows and SQL Server licences?
Often, yes, but the answer depends on your licence terms and on whether the economics work. Bring-your-own-licence on Google Cloud generally requires sole-tenant nodes, which change the cost model — you are paying for dedicated hardware rather than shared, and the machine placement matters.
The licensing position is worked out during program design, per complexity band, with the sole-tenant cost modelled against pay-as-you-go so you can see both numbers. On some estates BYOL saves a great deal. On others the sole-tenant overhead eats the saving, and that is worth finding out before the migration rather than in the first full billing month.
What happens if a cutover goes wrong?
The source machine is not deleted at cutover. Each wave has a rollback decision point with defined criteria and a defined window, and the procedure is exercised during the pilot wave rather than written down and hoped for.
Snapshot-based cutover helps here: because replication is continuous while the source keeps running, the cutover window is short and the rollback path stays open.
How long does a 500-VM estate take?
Program design runs roughly eight weeks regardless of estate size, because the work is dependency mapping and factory setup rather than per-machine effort.
Execution depends almost entirely on the complexity distribution and on how many cutover windows your business will accept per month. Neither is knowable before the dependency map exists, which is why execution is not quoted until program design is complete.
Questions about pricing, terms, and ownership across every engagement are on the FAQ.
Start with Discovery & Scoping
$4,500 fixed, 3–5 days. A current-state review, a gap analysis, a written scope, and a fixed quote for this engagement. Half the fee is credited against the work if you proceed within 60 days.