Migrate to Virtual Machines — the supported sources including AWS and Azure, and the four-project object model
The lift-and-shift service for VMs and disks. What it migrates from — vSphere, AWS, Azure and Google Cloud VMware Engine — the host-project and target-project split, and an explicit note on the mechanics this release did not read.
markdownreferencev1QQ7K-1M6Wstage: deploytrust: officialfamily: migrationservice: migrate-to-virtual-machinesinterface: anymigrate to virtual machinesVM migrationvSphereAWS sourceAzure sourceGoogle Cloud VMware Enginemigration sourcemigration targethost projecttarget projectlift and shift
Migrate to Virtual Machines
1. What it migrates, and from where
VMs and disks, from:
- vSphere data centers (on-premises)
- AWS
- Azure
- Google Cloud VMware Engine
AWS and Azure are first-class sources, which is the fact that makes this a cross-cloud service rather than an on-premises one. For the owner's use case — estimating and completing a move between hosting platforms — this is the execution tool for the compute half of it.
2. Four objects, and the project split is the one to get right
| Object | What it is |
|---|---|
| migration source | where the VMs come from |
| migration target | Compute Engine VMs or Persistent Disk volumes |
| host project | controls the migration process |
| target project | receives the migrated resources |
The host project and the target project are separate, deliberately. That separation is what lets a
migration team hold the controlling permissions without holding permissions in every destination project — and
it is what you design against the resource hierarchy
(reference/overview/projects-and-resource-hierarchy.md).
Get it wrong and you grant the migration tooling broad rights in production projects. Get it right and the migration's own blast radius is one project.
3. Where the migrated disks land
Targets are Compute Engine VMs or Persistent Disk volumes. Two consequences from the storage family:
- a zonal disk must be in the same zone as its instance, so the target zone is part of the migration plan,
not an afterthought (reference/overview/regions-zones-and-locations.md §3);
- Persistent Disk performance scales with capacity and Hyperdisk's does not
(reference/storage/persistent-disk-and-hyperdisk.md §1). A lift-and-shift that lands on Persistent Disk
and was sized on a different model will either over-provision capacity or under-provision throughput.
Decide the disk family deliberately, with the measured utilisation from Migration Center's inventory.
4. What this document does not claim
The architecture page read for this release does not, in the content read, detail the continuous-replication mechanics or the test-clone functionality. Both are central to how a low-downtime VM migration is actually run — a replication cycle, a test clone to validate before cut-over, then the cut-over itself.
Nothing about them is asserted here. Read the product's own migration-lifecycle pages before planning a
cut-over window, and treat any remembered sequence as unverified. Recorded as a gap in
changelog/2026-10-21-migration-family.md.
5. For an estimate
Three lines this service does and does not cover:
| Line | Covered? |
|---|---|
| moving the VM and its disks | yes — this service |
| the egress charged by the source cloud for the data leaving it | no. It is the source's bill, and it is frequently the largest unplanned cost |
| re-platforming the workload (to Cloud Run, GKE, or a managed database) | no — this is lift-and-shift. Re-platforming is the compute and databases families' work |
A lift-and-shift is the cheapest migration and the most expensive destination: the estate arrives with its old shape, its old sizing and its old operating model. Say so in the estimate, with the re-platforming as a named follow-on rather than an implied one.