---
cuppy_hub: gcp
cuppy_path: reference/migration/migrate-to-virtual-machines.md
cuppy_section: docs
cuppy_doc: QQ7K-1M6W
cuppy_doc_uuid: 46d7f02c-0959-4cf8-9b51-619cd8f1c721
cuppy_permalink: https://cuppy.io/gcp/d/QQ7K-1M6W
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/migration/migrate-to-virtual-machines
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 2632b47c5245826b8bfd310b57ddb56d0686693a316990c83027521ef0dbd75b
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# 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:

1. 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);
2. **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.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->