Pattern — lift and shift a VM estate onto Google Cloud, with the decisions named
The end-to-end handoff for moving VMs from AWS, Azure or vSphere: assess with measured utilisation, land in a prepared project and network, migrate with the host/target split, then re-platform as a named follow-on. With the known-bad configurations that make a lift-and-shift permanent.
markdownpatternv1WE5R-CT3Kstage: deploytrust: officialfamily: migrationservice: migrate-to-virtual-machinesinterface: anylift and shiftVM estatemigrate to virtual machineshost projecttarget projectright-sizingwaveszonal diskre-platformegressknown-bad configuration
Lift and shift a VM estate
The handoff
source: vSphere | AWS | Azure | Google Cloud VMware Engine
│
├─ 1. ASSESS Migration Center → inventory WITH utilisation, network dependencies, waves
│
├─ 2. PREPARE target project(s) · one GLOBAL VPC with regional subnets · firewall rules
│ quota increases requested · zones chosen · disk family chosen
│
├─ 3. MIGRATE host project controls → target project receives
│ target = Compute Engine VMs + Persistent Disk / Hyperdisk volumes
│
└─ 4. RE-PLATFORM a NAMED follow-on project, not an implied oneAssessment detail: guides/migration/assess-before-you-move.md. The estimate method:
guides/parity-and-migration-method.md.
The decisions, and where each is documented
| Decision | Made at | Document |
|---|---|---|
| machine series and shape | step 2 | reference/compute/compute-engine.md — custom types exist only for N and E series, and cost more |
| zone | step 2 | reference/overview/regions-zones-and-locations.md — a zonal disk must share its instance's zone, and does not move |
| disk family | step 2 | reference/storage/persistent-disk-and-hyperdisk.md — Hyperdisk performance is independent of size, Persistent Disk's is not |
| network shape | step 2 | reference/networking/vpc.md — one global VPC with a subnet per region, not one network per region |
| host / target project split | step 3 | reference/migration/migrate-to-virtual-machines.md §2 |
| wave boundaries | step 1 | from the network dependency graph, never the org chart |
Known-bad configurations
1. Sizing from provisioned capacity instead of measured utilisation
Why it is bad: most estates are provisioned at several times their usage. Lifting the provisioned shape carries that waste onto a cloud where it is billed by the second. Migration Center's inventory includes performance metrics precisely so this is avoidable, and right-sizing is usually the largest single saving in the whole project.
2. One VPC network per region, mirroring the source
Why it is bad: a Google Cloud VPC is global. Reproducing N regional networks also reproduces the
transit object you no longer need, and then you pay to connect networks that would have been one. Build one
network with a subnet per region (guides/parity/networking.md §2).
3. An auto-mode network
Why it is bad: auto mode's ranges all come from 10.128.0.0/9, so they collide with every other auto-mode
network — including the one you will later need to peer with. Custom mode, with a planned address space.
4. Closing egress last
A fresh VPC is implied deny on ingress and implied allow on egress. A lifted estate therefore arrives with unrestricted outbound.
Why it is bad: it is the opposite of most on-premises postures, and the moment to fix it is while the estate is still being built — not after the first review.
5. Choosing the zone after the migration has started
Why it is bad: a zonal disk "must be in the same zone" as its instance and does not move zones. Fixing it afterwards is a copy, not a reconfiguration.
6. Waves drawn by team
Why it is bad: two chatty systems land in different waves and their traffic crosses clouds at egress rates for as long as the gap lasts. This is the most expensive avoidable planning error in a migration.
7. Treating re-platforming as implied
Why it is bad: a lift-and-shift is the cheapest migration and the most expensive destination. The estate arrives with its old sizing, its old patching model and its old operating model. Write re-platforming into the plan as its own project with its own number, or it will be discovered as a surprise when the invoice arrives.
What this pattern deliberately does not describe
The replication cycle, the test clone and the cut-over mechanics. The architecture page read for this
release does not detail them in the content read, and they are exactly what a cut-over window depends on.
Read the product's own lifecycle pages before scheduling one, and treat any remembered sequence as unverified
(reference/migration/errors.md).
Verification, per wave
| Test | Expected |
|---|---|
| the migrated VM boots and its application answers | yes, before cut-over |
| the instance and all its disks are in the same zone | yes |
| egress rules are explicit, not implied-allow | yes |
| the wave's systems can still reach their dependencies | yes — and if a dependency is in a later wave, you have found a wave boundary error |
| the destination quota was sufficient | yes. If the wave half-failed, §3 of reference/migration/errors.md |
| measured utilisation after the move | compared against step 1's figure. That comparison is the input to the next wave's sizing |