It is the Google Cloud service that copies existing virtual machines into Compute Engine with little change and little downtime.

The simple definition

Migrate to Virtual Machines is a managed Google Cloud service that moves virtual machines from another place, such as a VMware data center, Amazon Web Services or Microsoft Azure, into Compute Engine, which is Google Cloud’s virtual machine service. It makes a complete copy of each server, including the operating system, the installed programs and the data on its disks. While the copy is being made, the original server keeps running. When you are ready, you switch users over to the copy in Google Cloud. You may see its older names, such as Migrate for Compute Engine, in books and older blog posts.

The problem it solves

Most companies already own hundreds or thousands of servers. Rewriting every application so that it fits the cloud perfectly could take years and a large budget. Meanwhile data center leases expire, hardware ages and costs pile up. Many teams therefore want a faster first step: move the servers as they are, gain the benefits of the cloud, and improve the applications later. This approach is called lift and shift, and Migrate to Virtual Machines is built for it.

Where it is used

It is used by infrastructure teams who need to leave a data center by a deadline, by companies consolidating clouds, by businesses merging after an acquisition, and by teams who want to move legacy applications whose original installers or developers no longer exist. It handles both Linux and Windows servers, which makes it practical for mixed estates.

A successful migration is a project with phases. Moving the server is only one of them.

Google describes cloud migration in four broad phases. Understanding them keeps you from the common mistake of treating the copying tool as the whole project.

There is more than one way to move an application, and the right choice depends on time, risk and value.

When lift and shift is a good choice

Google Cloud offers several migration services, and each handles a different kind of thing.

A dozen words explain almost everything you will see in the service.

A managed service in Google Cloud talks to your source, copies disk data, and builds the new virtual machines.

The big picture

The service is delivered as a managed part of Google Cloud, reachable through the console, the command line and an application programming interface. You register a source, and the service discovers the machines in it. For VMware environments, a small helper called the connector is installed in your data center as a virtual appliance. It talks to your VMware management system and sends disk data securely to Google Cloud. For Amazon Web Services and Azure, the service reads the machines directly through the provider’s own interfaces using credentials that you provide, so no appliance is needed.

flowchart LR
  A["VMware data center"] --> C1["Migrate connector appliance"]
  B["Amazon Web Services or Azure account"] --> M["Migrate to Virtual Machines service"]
  C1 --> M
  M --> S["Replicated disk data in Google Cloud"]
  S --> T["Test clone in Compute Engine"]
  S --> V["Cutover to production virtual machine"]
  V --> N["Customer traffic switched over"]
        

Not every server can be moved with every tool, so check what is supported before you plan.

Common sources

Operating system support

The service supports a range of Linux and Windows Server versions. The exact list of supported versions, kernels and disk layouts changes over time, so always read the current compatibility table in the official documentation before committing to a plan. Very old operating systems, unusual file systems, special hardware dependencies and disks beyond certain limits may need extra work or a different approach.

Replication is the heart of the service, and it is simpler than it sounds.

First a full copy, then only the changes

When you start a migration, the service first copies the entire contents of the machine’s disks to Google Cloud. This first cycle is the longest, because every block of data must travel across your connection. After that, the service repeats the process in regular cycles, but each later cycle copies only the blocks that changed since the last one. To know which blocks changed, it relies on the snapshot and change-tracking abilities of the source platform. Because the later cycles are small, the copy stays close to the live server, usually only a few hours behind.

Consistency and the final sync

Because each cycle starts from a snapshot, the copy is consistent as of a certain moment, similar to what you would get after a sudden power cut. Most operating systems and well-built applications recover from that without trouble. For the final cutover, the service takes one last cycle after you stop the source application, which makes the copy complete and current. For applications such as databases, many teams stop the application or take a database-aware backup before cutover to be extra safe.

Follow a single server from its life in the old data center to its life in Google Cloud.

flowchart TD
  A["Register the source"] --> B["Discover source virtual machines"]
  B --> C["Create a migration and set target details"]
  C --> D["Start replication: first full copy"]
  D --> E["Repeating delta cycles keep copy current"]
  E --> F["Run test clone and verify"]
  F --> G{"Test passed?"}
  G -- "No" --> H["Fix settings or source and test again"]
  H --> F
  G -- "Yes" --> I["Schedule cutover window"]
  I --> J["Cutover: final sync and start in Compute Engine"]
  J --> K["Verify application and switch traffic"]
  K --> L["Finalize: remove replication resources"]
        

The new home must be ready before the first box arrives. In Google Cloud, this prepared home is called a landing zone.

What a landing zone contains

Switching on the needed services

Before the first migration, the migration service and Compute Engine must be enabled in the right projects, and the service must be given permission to create resources in your target project. The people running the migration need suitable roles for managing the service and for creating machines. As always, give them only the roles they need. The exact list of interfaces to enable and roles to grant is in the current setup guide.

Good migrations begin with knowing exactly what you own.

What to collect about each server

Tools that help

Migration Center, Google’s discovery and planning service, can collect inventory from your environment, group machines, estimate whether and how they fit in Google Cloud, and give cost estimates for different options. You can also import inventory from existing tools or spreadsheets. The more of this data you gather before starting, the fewer mistakes you will make later.

Moving everything at once is risky. Moving in planned waves lets you learn and improve with each step.

Building waves

Bandwidth: a quick reality check

The first full copy is limited by your network connection. As a rough example, one terabyte of data is about eight thousand gigabits. Over a perfect one gigabit per second connection, that takes about eight thousand seconds, a little over two hours. Real links are never perfect, they are shared with other traffic, and compression, protocol overhead and the source’s own speed all matter. A realistic planning figure is often much slower than the theoretical one. Multiply by the number of servers and the number of waves and you will see why bandwidth planning matters.

The service can only move what it can see, so connecting the source safely is the first practical step.

VMware sources

For a VMware environment, you deploy the connector, a ready-made virtual appliance, inside your data center. You give it an account that can read your VMware management system, and it registers itself with the migration service in Google Cloud. From then on the service can list the machines in that environment and ask the connector to read disk changes. The connector only needs to make outgoing secure connections to Google Cloud, which usually makes firewall approvals easier than opening inbound doors.

Amazon Web Services and Azure sources

For these clouds, no appliance is needed. You create a limited account in the source cloud, with only the permissions that the migration needs, such as reading machine details and working with snapshots. You give those credentials to the service when you register the source. The service then reads machines and disk data through the provider’s standard interfaces. Because this account can read your servers’ data, it deserves the same care as any powerful credential.

For each machine you decide, in advance, what the copy in Google Cloud should look like.

Right-size now or later?

A common question is whether to choose the same size as the old server or a smaller one. The safest approach is usually to choose a size informed by measured usage and a safety margin, start there, and use Google Cloud’s sizing recommendations after the move to fine-tune. Choosing the exact size of an old oversized server copies waste into your new bill. Choosing too small risks a poor first impression of the cloud.

A test clone lets you check a working copy in Google Cloud while the real server continues to serve users.

What a test clone does

A clone job creates a temporary virtual machine in Compute Engine from the latest replicated data. The source server is not stopped and replication continues in the background. You can start the clone in an isolated network so that it cannot clash with the live server, log in, run the application and ask its owners to test it. When you are done, you delete the clone, and your replication carries on as if nothing happened.

A good test checklist

Cutover is the planned moment when the new virtual machine takes over from the old server.

What happens during cutover

When you start a cutover job, the service takes one final replication cycle so that the copy in Google Cloud contains the latest data. Usually the source machine is shut down before this final cycle, which ensures that no new data is written during the last sync. Then the service creates the Compute Engine virtual machine from the replicated disks, using your target details, and starts it. After that, you check the application and move users to the new server, usually by changing a domain name entry or a load balancer setting.

A good plan includes the way back, and a clean way to close the project for each server.

Rolling back safely

If something goes wrong after cutover, the simplest recovery is to return to the original server. As long as you have not deleted the source machine and have not allowed new data to be written to the cloud copy that you want to keep, you can power the source back on and switch users back. If the new machine has already accepted real business data, rollback becomes harder, because the old server lacks it. For this reason, set a clear decision window, for example the first few hours after cutover, and agree who may call a rollback.

flowchart LR
  A["Cutover complete"] --> B{"Application healthy in decision window?"}
  B -- "Yes" --> C["Keep source switched off for a safety period"]
  C --> D["Confirm stable operation"]
  D --> E["Finalize migration and retire source"]
  B -- "No" --> F["Roll back: start source and switch traffic back"]
  F --> G["Investigate and plan a new attempt"]
        

Finalization

After a stable period, you finalize the migration. This tells the service that you no longer need replication for this machine, and it removes the replicated data and temporary resources it created. Finalizing saves money and keeps the project tidy. But finalizing is a one-way step: once the replication data is gone you can no longer run another cutover from it. Only finalize when you are certain, and after your retention period for the old server has passed.

Operating systems and software licenses often cause the most unexpected migration issues.

What the service adjusts for you

A virtual machine built for VMware, Amazon or Azure expects the virtual hardware of that platform. Google Cloud’s virtual hardware is different, so the operating system needs the right drivers and settings to boot and use its disks and network. The migration service prepares the machine for this as part of creating the target, adding the needed components and adjusting configuration. You should still test, because applications with special hardware assumptions or unusual boot setups can still need attention.

Licensing options

Servers do not live alone. How they find and reach each other is a major part of a safe migration.

Connectivity during the migration

For the period when some servers have moved and others have not, the old site and Google Cloud must talk to each other reliably and securely. This is usually provided by a private link such as a virtual private network or a dedicated interconnect. Applications that were in the same data center and now sit in different places will see higher latency between them, which is another reason to move dependent servers together.

DNS preparation

A migration moves copies of your most important data. Protecting them in transit and at rest is not optional.

Layers of protection

Cleaning up after the move

Servers arriving from the old environment may carry old accounts, old remote access settings and outdated software. Use the move as a moment to scan and harden them. Remove accounts that are no longer needed, apply updates, enable the cloud’s patch and vulnerability tools, and apply firewall rules that allow only the traffic each server needs.

Replication shares your network and your servers with real business traffic, so it must be tuned with care.

What affects speed

Practical tuning habits

The migration tool itself is only a small part of the bill. The larger numbers are the resources you create.

Cost of the migration service

Google has offered Migrate to Virtual Machines at no additional charge for the service itself. Prices and terms can change, so always confirm on the official pricing page. What you pay for are the Google Cloud resources used by the migration and the resulting machines.

Ways to reduce the bill

You should always be able to answer three questions: what is running, how far along is it, and what has failed.

What to watch

A migration dashboard for the whole project

Besides the technical views, keep a simple dashboard for managers: how many servers are assessed, replicating, tested, cut over and finalized, grouped by wave. Add the planned and actual dates. This shows the real pace of the project, exposes blocked servers and gives early warning when a deadline is at risk.

Cutover is the end of the move, but only the start of getting the benefits of the cloud.

Clicking through a console is fine for ten servers. For hundreds, you need automation and good habits.

Ways to automate

Habits that make scale manageable

Teams that migrate smoothly tend to repeat a few simple designs.

These mistakes appear again and again in delayed and painful migrations.

A short, practical checklist you can print and put on the wall.

Best practices

• Assess before you copy. Know every server, its owner, its size, its dependencies and its allowed downtime.
• Retire what you can. The cheapest server to migrate is the one nobody needs.
• Build the landing zone first. Networks, access, logging and guardrails should be ready before the first machine arrives.
• Test the connection early. Prove connectivity and the connector’s health weeks before the plan depends on them.
• Start replication early. Let the long first copy finish well before the cutover window.
• Test with real business checks. A booting server is not a working application.
• Write and rehearse the runbook. Include owners, times, go and no-go points and the rollback deadline.
• Move applications together. Keep dependent servers in the same wave.
• Label everything. Owner, application and wave labels make cost and governance simple.
• Finalize and clean up. Delete test clones, replication resources and temporary firewall rules once they are no longer needed.

Most migration problems fall into a small number of families, and a calm checklist finds them quickly.

A calm order of investigation

The same service solves very different problems depending on the organization.

No migration approach is perfect. Knowing the trade-offs helps you pick the right path for each workload.

Choosing the right tool for each workload

Most real migrations mix several of these. The point is not to use one tool for everything, but to match each workload with the approach that gives the best balance of speed, risk and long-term benefit.

Migrations succeed or fail on coordination as much as on technology.

Who needs to be involved

A calm cutover weekend

You do not need to do everything at once. A staged plan delivers value early and reduces risk.

How to know it is working

Good signs include steady wave completion with few surprises, cutovers that match their rehearsed timings, short and calm rollback decisions when needed, falling cost per server after right-sizing, fewer incidents than in the old environment and a data center exit that happens on schedule.

A few wrong beliefs cause many delays. Clearing them up early saves time and money.

Each of these myths leads to either a missed deadline or an unexpected bill. The cure is the same every time: plan carefully, test early, ask the right owners and keep the way back open until the new system has proven itself.

Some servers carry more risk than ordinary application machines, and each needs its own thinking.

This example is fictional, but it shows how the pieces of this guide fit together for a single application.

The situation

A regional retailer runs an order management application on four servers in its own data center: a web server, an application server, a database server and a small batch server that runs nightly jobs. The data center lease ends in six months. The application is stable but old, nobody wants to rewrite it, and the business accepts a downtime window of three hours on a Sunday night.

What you measure shows you early whether the program is healthy, and gives leaders honest information.

Using the numbers well

Review the metrics at the end of every wave. If the test pass rate is low, improve assessment and target details before the next wave. If cutovers run long, simplify the runbook or move more steps ahead of the window. If post-move incidents are high, add checks to the test list. Treat the program as a learning system, so each wave is smoother than the last.

A quick reference for the words used in this guide, in alphabetical order.

No. The source keeps running while data is copied. It may feel a small extra load on disks and network, so start big copies in quiet hours and watch the effect on production. The source is stopped only at cutover, so that the final sync is complete.

It depends mostly on the amount of data and your network speed, because the first full copy must move everything. Small servers can finish in hours, large ones in days. Later cycles are small, and the cutover itself is usually measured in minutes to a couple of hours.

A test clone makes a temporary copy for checking and leaves the source and replication untouched. A cutover is the real switch: it takes a final sync, usually after shutting down the source, and creates the machine that will serve users.

Yes, if you have kept the source machine and have not allowed important new data to be written only to the cloud copy. Power the source on and switch users back. Agree a decision window and a person who can call the rollback before the cutover starts.

Start with simple, low-risk servers with few dependencies, such as test or internal systems, to prove the process and train the team. Leave the most critical and complex systems to later waves, when you have experience and polished runbooks.

It can work, but databases that write heavily or have a managed equivalent are often better handled with a database migration service, which keeps data in sync continuously and moves into managed offerings. Decide per database during assessment.

Usually little or nothing, which is the main benefit of lift and shift. You may need to update addresses, names, license settings and firewall rules, and you should test carefully. Deeper changes can be made later as part of modernization.

The migration service itself has been offered without an extra charge, but you pay for the resources it uses, such as replicated storage, network links and the new virtual machines, plus any licenses. Confirm current terms on the official pricing page and delete clones and replication resources promptly.

Use a dedicated source account with minimum permissions, give the team least-privilege roles, rely on encrypted transfer and storage, set organization guardrails, keep audit logs and remove credentials and temporary firewall rules when finished. Harden migrated servers instead of copying old weaknesses.

It stays until you finalize the migration. Finalizing removes the replication data and temporary resources, saving cost, but it is a one-way step, so do it only after the new server has proven stable and your safety period has ended.

Yes. Use waves, a repeatable factory process, templates and automation through the command line or the programming interface. Keep a single plan table as the source of truth and give each application a named owner for testing and approval.

Watch the new machine closely, run the agreed checks, keep the source intact for a safety period, then add monitoring agents, backups and patching, review size recommendations, tighten security and finally finalize the migration and retire the source.

Migrate to Virtual Machines gives you a managed, low-change route to move existing servers from VMware, Amazon Web Services and Azure into Compute Engine. It works by copying disks once, then keeping the copy fresh with small replication cycles while the source keeps running. You test with clones, switch with a short cutover, keep a way back, and finalize only when the new server has proven itself. Around that technical core sit the real success factors: honest assessment, a ready landing zone, careful wave planning, secure access, clear licensing, rehearsed runbooks and good communication. After the move, right-sizing, monitoring and modernization turn a simple relocation into real long-term value.

Remember the moving company from the beginning: photograph every room, pack carefully, keep the old house usable, test a sample room and move the last boxes in one quiet window.

A short self-check for your own migration

Ask yourself a few questions. Do you have an inventory with owners, dependencies and allowed downtime for every server? Have you decided what to retire, retain, rehost or modernize? Is your landing zone, network link and access ready? Has at least one server completed a full test clone with real business checks? Do you have a written, rehearsed cutover runbook with a rollback deadline? Do you know who will finalize and clean up afterwards? If any answer is unclear, that is the place to start.