A managed Google Cloud service that copies running virtual machines into Compute Engine with very little downtime.

A virtual machine, usually shortened to VM, is a computer made of software. One physical server can host many VMs, each with its own operating system, its own disks, and its own applications, all sharing the same hardware without seeing each other. Companies adopted VMs because they made expensive hardware far more efficient.

Migrate to Virtual Machines is Google Cloud’s service for moving those VMs into Compute Engine, which is Google’s own service for running VMs. It takes a VM that lives somewhere else, continuously copies its disk data to Google Cloud, and lets you start a matching VM on Google’s infrastructure when you are ready. The approach is called lift and shift, because you lift the machine as it is and set it down in a new place, making only the small changes needed for it to run there.

The service is delivered “as a service”. You use the Google Cloud console or an API to define sources, pick VMs, and drive the migration. You do not buy migration software, install a heavy management server, or license anything extra. The documentation describes the current generation as the 5.x line, which is the version this guide follows.

What it is not

It does not rewrite your application, split it into smaller pieces, or turn it into containers. It does not move databases into managed database services. It does not decide what to move. It is a transport and conversion service for whole virtual machines. Knowing that boundary early prevents unrealistic expectations later.

The reasons are usually money, speed, risk, or a deadline that cannot move.

Before learning the tool, it helps to know why anyone uses it. Moving to a cloud is rarely a technology hobby. It is almost always a business decision with a reason attached, and the reason shapes how you migrate.

Where lift and shift sits among the migration strategies

People often describe migration choices with a short list of strategies. Rehost means move as is. Replatform means move with small improvements, such as swapping a self-managed database for a managed one. Refactor means redesign the application for cloud-native patterns. Retire means switch it off. Retain means leave it where it is for now. Migrate to Virtual Machines is a rehost tool. It is the right choice when speed and low risk matter more than immediate redesign.

Eight terms unlock almost every sentence in the official documentation.

Cloud tools come with their own vocabulary. Learn these terms once, and the rest of this guide reads like plain English.

Two more words appear later. A group is a bundle of VMs that you migrate together, usually because they belong to the same application. OS adaptation is the set of small automatic changes that make a VM from another platform boot and behave correctly on Compute Engine.

A control plane in Google Cloud, a data path from the source, and Compute Engine as the destination.

The easiest way to understand the architecture is to separate the brain from the pipes. The brain is the Migrate to Virtual Machines service running in your host project. It records which sources exist, which VMs are being migrated, what state each one is in, and what you have asked it to do next. The pipes are the connections that move bytes of disk data from the source into Google Cloud storage and finally into Compute Engine disks.

flowchart LR
  subgraph SRC["Migration Sources"]
    V["vSphere data center"]
    G["Google Cloud VMware Engine"]
    A["AWS account"]
    Z["Azure account"]
  end
  subgraph HOST["Host Project"]
    API["Migrate to Virtual Machines service"]
    CON["Console, API and IAM"]
  end
  subgraph TGT["Target Project"]
    CE["Compute Engine VM or Persistent Disk"]
  end
  V -->|Migrate Connector| API
  G -->|Migrate Connector| API
  A -->|cloud source link| API
  Z -->|cloud source link| API
  CON --> API
  API -->|replicated data, clone, cut-over| CE
        

The main building blocks

On-premises VMware, VMware Engine, AWS and Azure.

Google documents four sources for the current generation of the service. Each has the same overall migration flow, but a slightly different way of connecting.

Limits worth knowing

A single host project can hold a maximum of fifteen cloud sources at a time, counting AWS and Azure sources together. You might host ten AWS sources and five Azure ones, or any other split, but not sixteen. If you reach the ceiling, you delete an unused source before adding another. For large enterprises with many accounts, this limit is a real planning factor, and it is a good reason to use more than one host project when the estate is big.

Operating system support

The VM must run an operating system that Google lists as supported for its particular source. The list differs by source and changes over time, so always check the current “supported operating systems” reference before promising a date to your business. Some Compute Engine features also rely on agents and services inside the guest operating system, which is another reason to read that page early.

Most migration problems are planning problems that show up late.

A migration tool is only the engine. The route, the order and the timing are decided by humans before the engine starts. Teams that skip this step usually do not fail loudly. They fail slowly, with surprise outages, unexpected bills and wasted weekends.

Step one: know what you own

You cannot move what you cannot list. Build an inventory of every VM: its operating system, number of CPUs, memory, disk sizes, how busy it really is, and which applications run on it. Google offers a wider platform called Migration Center that helps with discovery of the current environment, cost estimates and assessment, and Migrate to Virtual Machines is documented as one of the tools within that journey. Third-party discovery tools also work well when your estate is mixed.

Step two: map dependencies

Applications talk to each other. A web server talks to an application server, which talks to a database and to a file share. If you move the web server to Google Cloud while the database stays in your data center, every page load now crosses a long network link, and it may feel painfully slow. Dependency mapping tells you which machines must move together.

Step three: classify and sequence

Step four: decide the destination shape

Decide the machine type, region, zone, network and disk type for each target. The service provides usage-driven analytics to help you right-size destination instances, which matters because a physical-era server is often over-provisioned. Copying a half-idle sixteen-core machine as sixteen cores simply carries yesterday’s waste into tomorrow’s bill.

Projects, APIs, identities, networks and quotas must exist before the first byte moves.

Google’s own guidance tells you to build the foundation on Google Cloud and prepare the source environment before migrating VMs. The foundation is the part that is boring, careful and absolutely worth doing right, because every later step depends on it.

The resource hierarchy

Google Cloud organizes everything inside projects, which group resources, billing, permissions and APIs. Migrate to Virtual Machines requires one host project and one or more target projects. A common design uses one host project for the entire migration program and several target projects, each mapped to a business unit, an environment such as production or testing, or a team that will own the VMs afterwards.

Enabling the service

In the host project you enable the VM Migration API and the other services the migration depends on. This is a one-time setup per host project. Doing it in the console is straightforward, and teams that manage infrastructure through automation usually record the same step in their standard project templates.

Identity and permissions

Two kinds of identities matter. First, the people who run migrations need roles that let them create sources, start replication and perform cut-overs. Second, service accounts let the service act on your behalf in target projects when it creates disks and VMs. Follow the principle of least privilege. Grant the migration team what they need for the duration of the program, and review the grants when it ends.

Networking

Networking decides both the speed of replication and the behaviour of the migrated VM. Plan these pieces:

• Connectivity between source and Google Cloud. Replication needs outbound connectivity from the source environment to Google Cloud. Many companies use a private connection such as Cloud VPN or Cloud Interconnect for predictable bandwidth and stronger privacy, while others rely on the internet with encrypted traffic.
• Target VPC network and subnets. Decide in advance which network and subnet each migrated VM will join, and how it gets an internal IP address.
• Firewall rules. The VM arrives with its application listening on certain ports. Make sure the target network allows the needed traffic and blocks everything else.
• Name resolution. Applications often find each other by name. Plan how DNS will point to the new addresses during cut-over.

Quotas and billing

Compute Engine has default limits for CPUs, disks and addresses per region. A large wave can exceed them. Request increases before the migration window, not during it. Also confirm that billing is attached to every target project, because VMs cannot be created without it.

Connect the service to the place your VMs live, and get the source ready to be copied.

Once the foundation is in place, you turn to the source. The preparation differs by source type, but the goal is always the same: let the service see your VMs and read their disks safely, without disturbing the people who use them.

Preparing a vSphere or VMware Engine source

For these sources you deploy the Migrate Connector as a virtual appliance inside your VMware environment. After it starts, you register it with your Google Cloud host project, and then you create a source in the console that represents your vCenter. From that moment, the service can list the VMs in that vCenter and show them as candidates for migration.

A few practical points matter here. The connector needs enough compute and network resources to move data at the speed you expect. It needs access to vCenter with an account that has just the privileges required for the job. And it needs a path to Google Cloud. Because the connector initiates the outbound connection, you generally do not need to open inbound holes in your firewall, which security teams appreciate.

Preparing an AWS or Azure source

For cloud sources you create a source in the console and grant the service the permissions it needs inside your cloud account. In AWS this means an identity with defined permissions over EC2 and related storage. In Azure it means an application identity with rights over compute and disks in the chosen subscription. The service then discovers VMs in that account and can launch short-lived helper resources there to read disk data.

Getting the VMs themselves ready

The heart of the service is a steady, non-disruptive copy of disk data.

Replication is where most of the migration time is spent, so it is worth understanding properly. The key promise from Google is that replication copies disk data from the source VM to Google Cloud continuously without causing downtime on the source. Your users keep working on the old VM while the new copy builds up quietly in the background.

The two phases of replication

How changes are noticed

Virtualization platforms keep track of which disk blocks change over time. The service relies on the source platform’s snapshot and change-tracking abilities to find just the modified blocks, instead of re-reading everything. This approach avoids installing a monitoring agent inside each guest operating system. Google highlights this as a benefit: no client-side agent inside your workload means no extra load on the workload itself and no need to open network access into the machine.

sequenceDiagram
  participant S as Source VM
  participant P as Source platform or connector
  participant G as Google Cloud service
  participant D as Replicated disk data
  S->>P: Application keeps writing data
  P->>G: Initial full copy of all disk blocks
  G->>D: Store full baseline
  loop Every replication cycle
    P->>P: Identify changed blocks
    P->>G: Send changed blocks only
    G->>D: Apply changes to baseline
  end
  Note over D: Cloud copy stays close to the live VM
        

What affects replication speed

• Total disk size. More data means a longer first copy.
• Change rate. A busy database writes constantly, so each cycle carries more data than a quiet file server.
• Network bandwidth and latency. The pipe between source and Google Cloud is usually the bottleneck.
• Source platform load. Reading disks costs the storage system a little work, so heavily loaded storage can slow everything down.
• Number of VMs replicating at the same time. They share the same pipe, so ten parallel VMs each get a smaller slice.

Pausing and managing replication

You can pause replication if the network is needed for something else or if a source is undergoing maintenance, and resume it later. The service handles picking up from where it left off. This control is useful during business-critical periods such as month-end processing, when you may not want any extra load on storage.

Every VM travels the same ordered path, and the service moves it along automatically.

Google describes a VM migration lifecycle: each VM you migrate goes through an ordered set of phases, and the service advances it through them. Understanding the lifecycle lets you predict what happens next and plan human actions around it.

flowchart TD
  A["Add VM to migration"] --> B["Replicating: baseline and incremental copies"]
  B --> C{"Ready to rehearse?"}
  C -->|Yes| D["Test clone in Google Cloud"]
  D --> E{"Tests pass?"}
  E -->|No| F["Fix issues and retest"]
  F --> D
  E -->|Yes| G["Schedule cut-over"]
  C -->|Skip rehearsal| G
  G --> H["Final sync and production VM starts"]
  H --> I["Validate in production"]
  I --> J["Finalize and clean up"]
        

The lifecycle, one step at a time

Why the test clone is the best feature

A test clone lets you rehearse the real thing without risk. The clone boots from a snapshot of the replicated data, so changes you make during testing do not touch the source or the replication stream. You can check that the application starts, that services are reachable, that licenses activate and that performance feels right. If something is wrong, you fix it on the source side or in the target configuration, run another clone, and repeat until the checklist is green.

Cost during the lifecycle

Test clones and cut-over VMs are normal Compute Engine instances, so they are billed at ordinary Compute Engine prices for as long as they exist. Delete test clones as soon as the check is done. Replicated data also occupies storage until you finalize or remove the migration.

Small automatic changes let a VM from another platform boot properly on Compute Engine.

A VM running on VMware does not know it has been moved. It was built around virtual hardware that VMware presents: a specific disk controller, a specific network card, and often helper software called guest tools. Compute Engine presents different virtual hardware. If you simply copied the disk across, the operating system might fail to find its boot disk, or the network card might be unrecognized, leaving the machine up but unreachable.

To solve this, the service applies OS adaptations automatically. Google describes these as configuration changes that VMs need in order to work properly on Google Cloud, applied by the service to the VMs you migrate. In broad terms they cover:

Why adaptation still needs your attention

Automation covers the standard cases. Unusual setups can still need a human eye: custom kernels, hand-tuned boot loaders, special storage drivers, or software that ties itself to old virtual hardware identifiers. That is why the test clone exists. If an adaptation does not fit your VM, you find out in the rehearsal rather than on launch night.

Applications that remember hardware

Some licensed software generates its license key from the machine’s hardware fingerprint, such as its network card address. When the VM moves, the fingerprint changes, and the license may stop working. Check with software vendors before migration and collect any activation steps you will need after the first boot in Google Cloud.

Move applications, not isolated servers, and move them in manageable batches.

Real applications rarely live on a single VM. A typical business system has web servers, application servers, a database and perhaps a batch processor. If you migrate them one at a time with no coordination, the app may be half in the old place and half in the new place for weeks. The service offers groups so that VMs belonging together can be migrated together.

What a group gives you

• One action for many VMs. You can test-clone or cut over every VM in the group together rather than clicking through each one.
• A shared story. Application owners can see all machines of their system in one view.
• A natural unit for scheduling. A group maps neatly to a change window on the calendar.

Google’s marketing material describes a range from migrating a single app with a few clicks to running a migration sprint of around a hundred systems using groups, and it points to the API for teams that want to build their own migration factory.

Designing waves

Building a migration factory with the API

When hundreds of VMs are involved, clicking in a console becomes the bottleneck. Because every console action also exists in the API, teams create their own tooling that reads the plan from a spreadsheet or a database, creates groups, starts replication, triggers test clones, records results and posts status messages to team chat. The advantage is repeatability: every VM follows the same path with the same checks, and the plan is auditable afterwards.

A migration moves your most valuable data across networks, so security has to be part of the design.

Security is not a separate phase for migrations. It runs through every step: who can start the process, how data travels, where it rests, and what the migrated VM looks like when it wakes up.

Access control

Use IAM to give migration staff only the roles they need, and separate duties where sensible. For example, the people who can create sources may differ from those who can perform production cut-overs. Review who holds those roles on a regular schedule, and remove them at the end of the program.

Data in transit and at rest

Replicated data moves from your source to Google Cloud over encrypted channels, and on Google Cloud, storage is encrypted at rest by default. If your company must control its own encryption keys, evaluate customer-managed encryption options for the target disks and confirm how they apply to the migration path you have chosen. For especially sensitive workloads, run replication over a private connection rather than the public internet.

Network exposure

• The Migrate Connector initiates outbound connections, so you typically avoid opening inbound access to your data center.
• Give migrated VMs private addresses by default and add public addresses only when truly needed.
• Place test clones in isolated networks so they cannot reach production data stores by accident.
• Use firewall rules that allow only the ports an application genuinely needs.

Credentials left behind

Servers often carry old secrets: service account passwords in configuration files, shared keys, forgotten local administrator accounts. Migration is a golden opportunity to find and rotate them. At minimum, scan the migrated VM for hard-coded credentials and rotate the important ones soon after cut-over.

Compliance and location

Choose target regions that satisfy data residency rules for your industry or country. Record where data lived before and after the move so auditors can follow the trail. Keep migration logs, because they show who did what and when.

You need to see replication health, cut-over progress and the behaviour of the migrated VM.

A migration that runs for weeks needs observation. The service shows the state of each VM migration in the console, including whether replication is healthy, how recent the latest cycle is, and what the next lifecycle step is. Google Cloud’s logging and monitoring tools capture activity and let you build alerts around it.

What to watch during replication

What to watch after cut-over

Once the VM runs in Compute Engine, treat it as any other production VM. Check CPU, memory, disk and network metrics, and the health of the application itself. Compare these numbers with what you saw on the old platform, since differences can reveal sizing mistakes or missed settings.

Typical troubleshooting scenarios

The service itself is free, but the resources around it are not.

Google provides Migrate to Virtual Machines at no charge for migrations into Google Cloud. That is a major reason many organizations choose it. But “free tool” does not mean “free migration”. Several real costs sit around the service, and a good plan accounts for all of them.

Estimating the bill

Use the Google Cloud pricing calculator to estimate the monthly running cost of your target VMs once they are live. Add a short-term migration budget for the overlap period, when you pay for the old environment, the replicated data and the new VMs at the same time. Teams that forget this overlap often see a cost spike in the middle of the program and mistakenly think something has gone wrong.

Ways to keep costs under control

• Delete test clones as soon as testing is finished.
• Finalize migrations promptly after validation so replication resources are released.
• Right-size VMs using real usage data instead of copying old sizes blindly.
• Shut down and decommission the old environment on a planned date so you stop paying twice.
• Consider committed use discounts for steady workloads once you are confident in the sizing.

Patterns are habits that repeatedly work; anti-patterns are habits that repeatedly hurt.

After many migrations, experienced teams converge on a handful of habits. Here are the ones that appear again and again, along with the traps that catch new teams.

Patterns that work

flowchart LR
  P["Plan and assess"] --> F["Build foundation"]
  F --> PI["Pilot wave"]
  PI --> W["Production waves"]
  W --> O["Optimize and right-size"]
  O --> D["Decommission old environment"]
        

Anti-patterns to avoid

Migrate to Virtual Machines is excellent at one job; other jobs deserve other tools.

Choosing the right migration path matters more than polishing the wrong one. The table below compares the main options at a high level so you can place this service in the bigger picture.

Situations where caution is wise

• Unsupported operating systems. If your VM runs an operating system outside the supported list for its source, plan for extra testing or an alternative route.
• Specialized hardware dependencies. Software that needs a hardware dongle, special cards or very specific virtual hardware may not run unchanged.
• Extremely write-heavy databases. A VM that changes enormous amounts of data every minute may keep replication permanently behind. Consider database-level replication for these.
• Strict zero-downtime requirements. The final cut-over still involves a short switch. Truly zero-downtime systems usually need application-level clustering and traffic shifting designed for it.

The cut-over is the beginning of cloud life, not the end of the project.

Google’s own migration guidance ends with a step to optimize your environment after migration, and for good reason. A lifted server behaves like a guest in a new house: it works, but it has not unpacked yet. The first weeks after cut-over are the best time to make it feel properly at home.

Right-size the machines

Look at real CPU, memory and disk usage over a few weeks. Many VMs that were sized for peak loads years ago are far larger than they need to be. Compute Engine lets you change the machine type, and Google’s recommendation tools can suggest better sizes based on observed usage. Each step down saves money every month.

Adopt cloud-native operations

Plan the next modernization steps

Now that workloads are in Google Cloud, you can start improving them selectively. A self-managed database might move to a managed one. A stable web tier might be containerized. A batch job might become a scheduled serverless task. Choose the improvements that pay back fastest rather than modernizing everything at once.

Decommission the old environment

The final satisfying step is turning off what you left behind. Keep the old VMs switched off but available for a defined safety period, confirm nobody needs them, then remove them and release the hardware, licences and contracts. This is where the savings of the whole program truly arrive.

Four illustrative situations showing how the pieces fit together.

The scenarios below are illustrative composites, not case studies of specific named companies. They show how typical organizations apply the service.

A short checklist to keep nearby while you run the program.

Best practices

• Treat migration as a program, not a tool installation. Assign owners, a calendar, a communication plan and a decision-maker for go or no-go calls.
• Validate prerequisites in writing. Supported OS, connectivity, quotas, permissions and licensing are all checked before each wave.
• Keep the foundation consistent. Use standard naming, labels, network layouts and role definitions across all target projects.
• Automate the repeated steps. Use the API for groups, status reports and checks once your process is stable.
• Test like production. A test clone should exercise the same logins, jobs and integrations that real users depend on.
• Communicate widely. Application owners, help desk staff and end users should know the schedule and what to expect.
• Record lessons after each wave. A short retrospective improves the next wave measurably.
• Close the loop. Finalize migrations, delete clones, remove source VMs and update documentation.

Common mistakes

Quick answers to the questions beginners ask most.

The service itself carries no charge for migrations into Google Cloud. You still pay for the Compute Engine instances, storage and networking you use, and for source-cloud resources when migrating from AWS or Azure.

No agent is required inside each guest for the replication approach described here. For VMware sources you deploy a Migrate Connector appliance in the environment, which is separate from the VMs being moved.

Replication is designed to run without causing downtime on the source. Your source VM stays online. The short interruption happens at cut-over, when you switch users to the new VM.

It depends on disk size, how fast data changes, and available bandwidth. A small server may take hours; a multi-terabyte database server may take days for the first copy. Cut-over itself is usually short once replication is up to date.

Google documents four: on-premises vSphere, Google Cloud VMware Engine, AWS and Azure.

A test clone is a temporary rehearsal VM that does not affect the source or replication. A cut-over is the real switch that creates the production VM from a final sync.

Yes. The target can be either a Compute Engine VM instance or Persistent Disk volumes, which helps when you only need the data.

While the source VM remains intact and you have not finalized, you can return users to the source. That is why finalization should wait until validation is complete and the safety period has passed.

It makes only the small adaptations needed for the VM to run on Compute Engine. Your application code and design stay the same, which is both the strength and the limit of lift and shift.

Yes. The console actions are also available through an API, so teams can build their own repeatable migration factories that handle hundreds of VMs.

The host project controls the migration and holds the service. Target projects receive the migrated VMs. They can be the same project for a small test, but separate projects are usual in real programs.

A host project can hold at most fifteen cloud sources at a time, counting AWS and Azure together. Large estates often use more than one host project.

Migrate to Virtual Machines gives teams a calm, repeatable way to move whole servers into Google Cloud. It copies disks continuously while the originals keep working, lets you rehearse with test clones, applies the small changes each VM needs, and then swaps production over in a short, controlled cut-over. It costs nothing as a service, but the surrounding resources and the overlap period do cost money, so plan for them. The tool is dependable, but the outcome depends mostly on the human work around it: inventory, dependency mapping, grouping, rehearsal, clear communication and a firm date for switching off the past.

Remember the restaurant that needed to move without closing. The service is the moving crew, but you still choose the new building, pack with care, rehearse the first dinner and decide the day to hand over the keys.