A few simple ideas before we meet the service.

What is a virtual machine?

A virtual machine, often shortened to VM, is a pretend computer that runs as software inside a real, physical computer. It has its own operating system, its own programs and its own files, but several of them can share one physical server. Most companies run hundreds or thousands of VMs in their own data centers, often using a virtualization platform such as VMware vSphere.

Why do companies move to the cloud?

There are many reasons. Data centers are expensive to build, power, cool and staff. Old hardware reaches end of life and must be replaced. Capacity must be bought in advance and often sits unused. A cloud provider lets you rent capacity by the hour, add more when demand grows and give it back when demand shrinks. Moving also opens the door to modern services, better security tooling and global reach.

Why migration is hard

Each server in a data center has a history. Someone installed software years ago, configured settings by hand, linked it to other servers and then left the company. Rebuilding every server from scratch in the cloud means rediscovering all of that. It is slow, risky and expensive. A much easier path for many servers is to copy them as they are, a method called lift and shift.

A managed Google Cloud service that moves VMs into Compute Engine.

Migrate to Virtual Machines is a Google Cloud service for moving virtual machines from other environments into Compute Engine, Google Cloud’s virtual machine service. It supports sources such as VMware environments in your own data centers, and virtual machines running in other public clouds. It was previously known as Migrate for Compute Engine, and it grew from technology that Google acquired for fast, low-downtime migration.

The central idea is replication. The service continuously copies the disks of a source machine to Google Cloud while that machine keeps running normally for your users. Because the copying is incremental, only changed data is sent after the first full copy. When you are ready, you test a clone in the cloud, and when you are happy, you perform a cutover that finishes the last small sync, shuts down the source and starts the cloud VM. The downtime is typically short.

A short dictionary of migration words.

Not every workload should move the same way.

Before pressing any button, decide what you want to do with each application. Cloud professionals often describe a handful of common strategies. Migrate to Virtual Machines is the tool for one of them, lift and shift, but it is useful to see the whole menu.

Migrating is a project, not a single click.

flowchart LR
    A[Discover and assess] --> B[Plan landing zone and waves]
    B --> C[Connect and configure migration service]
    C --> D[Replicate VM disks]
    D --> E[Test clone]
    E --> F{Test passed?}
    F -->|No| G[Fix settings or application]
    G --> E
    F -->|Yes| H[Cutover]
    H --> I[Validate and optimize]
        

The engine inside the service.

Replication is the process of copying a virtual machine’s disks to Google Cloud. The first replication cycle copies all the data on the disks. After that, further cycles copy only the blocks that changed since the last cycle, which is much smaller. The source VM continues to run and serve users throughout, so you can replicate for days or weeks before cutover. The data lands in Google Cloud storage as a staging copy that is later turned into disks for the new VM.

How the data is read depends on the source. For VMware environments, the migration connector, an appliance running in your environment, reads the VM disks using the virtualization platform’s features and sends the data securely to Google Cloud, without installing software on each VM. For other cloud sources, the service connects through the provider’s programming interfaces with credentials you supply and reads the disks through snapshots. Supported sources, operating systems and versions evolve, so check the current compatibility list.

sequenceDiagram
    participant SRC as Source VM
    participant CON as Connector or source API
    participant MS as Migrate to VMs Service
    participant ST as Staging Storage in Google Cloud
    SRC->>CON: Disk data, first cycle copies everything
    CON->>MS: Encrypted transfer over private link or VPN
    MS->>ST: Store replicated data
    SRC->>CON: Later cycles, changed blocks only
    CON->>MS: Send incremental changes
    MS->>ST: Update staging copy
    Note over SRC,ST: Source keeps running for users throughout
        

A smooth migration needs a well-prepared destination.

The landing zone

A landing zone is the prepared cloud environment where migrated servers will live. It includes your organization structure, projects, identity and access rules, network design, security controls, logging and billing arrangements. Building this before migrating avoids moving servers into an untidy place that must be reorganized later.

Connectivity

The source and Google Cloud must be able to talk. Common options are a VPN tunnel for modest volumes and a dedicated or partner interconnect link for large or steady transfers. Firewalls must allow the migration traffic, and address ranges must be planned so that cloud and on-premises networks do not overlap, since overlapping ranges cause routing problems.

Identity and permissions

The migration service needs permissions to create resources such as disks and VMs in your projects. Create dedicated service accounts with only the permissions needed, and limit who can start migrations. For other cloud sources, create read-only style credentials for the connection, and store them securely.

Capacity and quotas

Check that your Google Cloud projects have enough quota for the VMs, disks and addresses you will create. Large waves can hit default limits, and requesting increases takes time, so plan ahead.

flowchart LR
    subgraph SRC[Source Environment]
        VM1[VMs] --> CONN[Migration connector or cloud source API]
    end
    CONN -->|VPN or Interconnect| LZ
    subgraph LZ[Google Cloud Landing Zone]
        MS[Migrate to Virtual Machines]
        NET[VPC network and firewall rules]
        IAM[Identity and access controls]
        CE[Compute Engine VMs]
        MS --> CE
        NET --- CE
        IAM --- MS
    end
        

Where the new server will live and how big it should be.

For each migrating machine, you specify target details that describe the Compute Engine VM that will be created. These choices shape performance, cost and security, so make them thoughtfully.

The safety net of the whole process.

A test clone creates a temporary VM in Google Cloud from the replicated data, without touching the source or interrupting replication. You can start it, log in, run the application and check that it behaves correctly. Because the source continues running, there is no pressure and no risk to production while you test.

A planned, short, rehearsed switch.

flowchart TD
    A[Cutover starts in the agreed window] --> B[Stop application cleanly]
    B --> C[Final replication cycle]
    C --> D[Power off source VM]
    D --> E[Create and start VM in Compute Engine]
    E --> F{Checks pass?}
    F -->|Yes| G[Switch users and dependencies, monitor]
    F -->|No| H[Rollback: power on source, investigate]
    G --> I[Keep source off for a safety period, then decommission]
        

Servers rarely live alone.

A typical business application has several servers: a web server, an application server and a database. If you move only one of them, the rest of the chain may break or become painfully slow because traffic must cross the link between your data center and the cloud. This is why migrations are planned in waves. Each wave contains servers that belong together and can move together, ideally with minimal dependencies on servers that remain behind.

Cutover is not the finish line.

A lift-and-shift migration gets servers into the cloud quickly, but the work of making them cloud-ready continues afterward. The first weeks are for stabilizing: watch performance, fix small issues and keep the safety net of the source for a while. Then improve.

Data in motion needs protection too.

Protecting the data in transit

Replicated disk data travels from the source to Google Cloud over an encrypted channel. Prefer private connectivity, such as VPN or interconnect, over the public internet when moving sensitive systems, and restrict which addresses and ports may be used for migration traffic.

Protecting credentials

Credentials used to connect to source environments can read your servers’ disks, so treat them as highly sensitive. Create dedicated, narrowly scoped accounts for migration, store secrets in a secret manager, and remove or disable them when the project ends.

Controlling who can migrate

Migration permissions can create and start VMs. Limit them to a small group, require approvals for cutovers, and keep audit logs to answer who did what and when.

Protecting data at rest

Data in Google Cloud is encrypted at rest by default, and you can use customer-managed keys if rules require it. Remember that staging copies and test clones also contain real data, so protect them like production and delete them when finished.

Hardening the migrated VM

Servers that were safe behind a data center firewall may not be safe if exposed in the cloud. After migration, review open ports, remove unnecessary public addresses, update operating systems, apply cloud firewall rules and enable security scanning.

flowchart TD
    A[Private connectivity and restricted migration traffic] --> B[Scoped, short-lived migration credentials in a secret manager]
    B --> C[Limited migration permissions with approvals]
    C --> D[Encryption at rest, protect staging copies and clones]
    D --> E[Harden migrated VMs: patch, close ports, least privilege]
    E --> F[Audit logs and clean-up of temporary resources]
        

Most problems fall into a few familiar families.

Use the migration service’s status views, replication history and logs to see what each machine is doing, and Cloud Logging and Monitoring to watch the new VMs after cutover. Set alerts for failed replication and for migrated VMs that show high errors or resource pressure.

The service helps migrate, but the resources it uses are not always free.

Google has offered Migrate to Virtual Machines itself at no additional service charge, but you pay for the Google Cloud resources involved. Check the current pricing page to confirm terms. Typical cost items include storage for replicated data and snapshots, compute for test clones and the migrated VMs, network transfer and connectivity such as VPN or interconnect, licenses for operating systems and software that run in the cloud, and the engineering time of your team and any partners.

A balanced view.

Lessons from teams who have done this many times.

Best practices at a glance

Anti-patterns to avoid

It replicates the disks of source virtual machines to Google Cloud while they keep running, lets you test cloned copies, and then performs a cutover that starts the machine in Compute Engine with a short downtime.

Supported sources include VMware environments and virtual machines in other public clouds. The list of sources, operating systems and versions changes over time, so check the current compatibility documentation before planning.

Much less than offline copying. Downtime is usually limited to the final sync, shutdown and startup during cutover, which you can rehearse with test clones to estimate accurately. Application-specific steps may add to it.

For VMware sources, a migration connector appliance reads disk data without requiring an agent on each VM. Other source types use their own mechanisms. Check the documentation for details by source.

A test clone is a temporary VM created in Google Cloud from replicated data. It does not affect the source or interrupt replication, so you can safely test and then delete it.

Yes, provided you plan for it. Keep the source machine intact and powered off for a safety period, define rollback criteria and steps in advance, and remember that data written in the cloud after cutover must be considered if you go back.

Choose sensible target sizes using assessment data, and plan to right-size again after observing real usage. Cloud machines can be changed far more easily than physical servers.

It is a fast first step, but not the end. After migration, optimize cost, security and operations, and modernize selected workloads to use managed services or containers over time.

Start with a pilot of low-risk, relatively independent systems, such as development or test environments. Then move in waves of related servers based on dependency maps and business priorities.

Google has offered the migration service without an extra service charge, but you pay for the underlying resources such as storage, compute, networking and licenses. Check the current pricing page to confirm.

Migrate to Virtual Machines gives organizations a practical, low-drama way to move servers into Google Cloud. By replicating disks while the source keeps running, offering safe test clones and supporting a short, rehearsed cutover, it turns a risky move into a controlled project. Success comes from the surrounding discipline: assess and plan first, build a proper landing zone, map dependencies, migrate a pilot, test every machine, rehearse the cutover with a rollback plan, and then right-size, secure and modernize afterward. Treat the migration as the beginning of your cloud journey rather than the end, and the servers you move today become the foundation for the improvements you make tomorrow.