robots: noindex

Migrating VMs to Compute Engine using CloudEndure

CloudEndure is deprecated. For migrating from other VM platforms, use Migrate for Compute Engine.

This guide shows you how to use the VM Migration Service, powered by CloudEndure, to import a server that is running a supported operating system from either an on-premises machine or a VM in another public cloud platform into Google Cloud. At the end of this exercise, you will have a virtual machine instantiated in your project that is a replica of a machine in another environment.

You can also read about best practices for migrating VMs to Compute Engine or try out the virtual disk import tool.


  • Launch the VM Migration Service from the Google Cloud Console.
  • Install the CloudEndure replication agent and copy the virtual machines into Compute Engine.
  • Launch the new virtual machines.


The VM Migration Service is free to use. You aren't billed for this service either from Google or CloudEndure.

For VM instances you import into Compute Engine, you are billed according to the Compute Engine price sheet for VM instances.

Before you begin


To use the VM migration service, the source machines from which you are migrating must be running one of the following operating systems:


The following Windows operating systems are supported. Note that Windows client operating systems and evaluation versions of Windows Server are not supported.

When migrating Windows operating systems to Compute Engine, a new on-demand SPLA license will be attached to Compute Engine VM instances. It is not possible to bring your own licenses to Compute Engine.

  • Microsoft Windows Server 2016 64-bit, Standard and Datacenter editions
  • Microsoft Windows Server 2012 R2 64-bit, Standard and Datacenter editions
  • Microsoft Windows Server 2012 64-bit, Standard and Datacenter editions

  • Microsoft Windows Server 2008 R2 64-bit, Standard and Datacenter editions

  • Microsoft Windows Server 2008 with Service Pack 2, 32-bit or 64-bit, Standard and Datacenter editions

  • Microsoft Windows Server 2003 with Service Pack 2, 32-bit or 64-bit, all editions

  • Microsoft Windows Server 2003 R2, with Service Pack 2, 32-bit or 64-bit, all editions

    If you are migrating a Windows Server 2003 environment, your instances are billed at the rate for Windows Server VMs.

Before you migrate a Windows Server environment to Google Cloud, you must prepare your Windows Server machine for the migration.


  • SUSE Linux (SLES) 11 or above
  • Debian Linux 8
  • Kali Linux 2.0
  • Ubuntu 12.04 or above
  • Red Hat Enterprise Linux (RHEL) 5.0 or above

  • CentOS 6.0 or above

  • Oracle Linux 6.0 or above

For SUSE, RHEL, and Oracle Linux, you must have an existing license to use the operating system. It is your responsibility to determine whether you are properly licensed to run the OS. For Windows, any existing license is converted to Google Cloud's pay-as-you-go licensing.

  1. Sign in to your Google Account.

    If you don't already have one, sign up for a new account.

  2. In the Cloud Console, on the project selector page, select or create a Google Cloud project.

    Go to the project selector page

  3. Make sure that billing is enabled for your Google Cloud project. Learn how to confirm billing is enabled for your project.

Create a service account and service account key

To use the CloudEndure VM Migration service, you must link it to your Google Cloud Console project using a service account key. You need this service account key for the CloudEndure portal.

  1. In the Cloud Console, go to the Service Accounts page.

    Go to the Service Accounts page

  2. If prompted, select a project.

  3. Click Create Service Account.

  4. Choose a name for the service account and grant the service account the Project Owner role.

    Adding a service account.

  5. Check the box next to Furnish a new private key and select JSON from the Key type list.

  6. Click Create to create the service account and follow instructions to download the key.

Start the VM migration service

The VM migration service is offered by CloudEndure, a third-party partner of Google Cloud. Before you can migrate your VM, you must sign up for CloudEndure. CloudEndure does not charge for this service.

  1. In the Cloud Console, open the VM Instances page.

    Go to the VM Instances page

  2. To start the migration service, click Import VM.

    Selecting the VM import button.

  3. Click Continue to go activate the migration service.

Activate the VM migration service

  1. On the CloudEndure Sign In page, click Sign up to sign up for the service.
  2. On the Activation page, fill in the required details.

    The CloudEndure activation page.

  3. If you accept the terms of service, select the I agree to the CloudEndure Terms and Conditions box, and click Activate My Account to complete your registration. CloudEndure sends a confirmation email to the email address you used to register.

  4. To activate your account, click the link the in the email.

You are redirected to the VM Migration Console. You can also access the console directly at any time.

Migrating your instance

You can use the VM Migration service to migrate your running Windows/Linux servers (physical/virtual/cloud-based) into a target cloud region of your choice, without any system disruption on your source infrastructure. The replication is continuous, and is done at the block level.

Below is a network diagram showing the networking and port requirements for the migration, followed by guidelines and some best practices for migrating your workload.

Network diagram explaining how VM migration process works

Prepare the staging network in the target region

In the target region, create a VPC network. This network is used as a staging network to host the CloudEndure replication servers. If you plan to use the default network, you can skip this step.

Configure your CloudEndure account

  1. Log in to your activated CloudEndure account.
  2. Provide your project ID and the JSON key for the service account that you created earlier.

Select replication options

Select the target region where you want to migrate your VMs. Then, choose the replication server network you created. If you didn't create a new network, select the default network.

Install the migration agent

Install the VM migration agent on each of the source machines that you want to migrate. The VM migration agent is required to copy the machine at the block level from the source to the destination. The agent can be installed on any supported operating system. This step copies data into Google Cloud but does not launch your final target machines.

To install the migration agent, download the agent to the machines you want to migrate using the following instructions.

In the VM Migration console, click Help, then click How to add machines. The help page includes an installation token, which you need to install the migration agent. Copy the installation token.


On Linux, download the installer with the following command:

wget -O ./

Then run the installer using the following command. Replace [TOKEN] with your installation token:

sudo python ./ -t [TOKEN]

The Linux installer will require Python 2.4 or greater installed on the machine. Other Python versions won't be able to run the installer.


Download the Windows installer.

In a command prompt window, run the installer using the following command. Replace [TOKEN] with your installation token:

installer_win.exe -t [TOKEN]

After the agent installation completes successfully, you can track the progress of the migration in the VM Migration Console, in the Migration tab.

The progress of the data copy into Google Cloud is shown under the Data Replication Progress column in the console.

If the Status column shows a red stop sign icon, verify the following:

  • The source server (with the installed agent) can communicate with VM Migration management server ( over TCP port 443. Linux servers may require access to repositories during installation.

  • The replication servers in the target region in the staging area (replication server network) can communicate with the VM Migration Service management server ( over TCP port 443 and outbound Internet connectivity over TCP port 443 for downloading installation packages. By default, CloudEndure’s service automatically adds a firewall rule to allow this access to the project.

  • The source server (with the installed agent) can communicate with the replication servers in the target region's replication server network over TCP port 1500. This firewall rule is also added by CloudEndure.

Configure the target machine

Next, for each VM instance that you are migrating, review the virtual machine properties by clicking on that server in the VM Migration Console, which opens the Blueprint tab.

The Blueprint tab lets you set the properties of your target VM instance. For example, you can change the target network the VM is created in, or the internal IP, and so on. You can change these properties at any time after the agent is installed. You don't have to wait for replication to complete to modify these settings. These properties include:

  • The target instance's machine type

  • The target instance's machine name

  • The target VPC network/subnet

  • The internal IP

  • The type of each persistent disk used by the VM instance

To save your changes, click Save Blueprint.

Verify initial sync completion

Depending on the size of the source disk, and the zone that you are migrating your machine to, it might take several hours or more for the replication server to sync your data. When the initial sync is complete, in the Data Replication Progress column, the replicated machines show Continuous Data Protection , indicating that you can test the creation of your target instances. In the Status column, a purple launch icon is shown, indicating you can start the target machine in the target location.

Initial sync progress.

Test the creation of target VM instances

When you are ready to test the creation of the servers in the target location, select the server, then click Launch Target Machine, and click Test.

Selected instances for testing.

You can follow the progress of the target machine launch process in the Job Progress tab, which will also show if any errors were experienced during this process.

Test the availability of the target VMs

Go to the VM instances page and verify target VMs that were created. By default, the target VMs are prefixed with their original names. If you changed the name of the target instance in the blueprint, the target VM uses the name you chose.

Verify that you can log into the target machines. For Windows target machines, use RDP, and for Linux machines, use SSH.

Go to the VM Instances page

Use the source machine’s credentials for logging into its target machine. Please use external SSH and RDP clients rather than trying to connect through the web interface of the Google Cloud.

Test your applications on the target VMs

After creating test target VMs, you should test all your apps to see if they work correctly.

If anything needs to be adjusted, make adjustments in the Blueprint tab or on the source machine. Repeat this testing process until your applications work as expected.

Finalize your migrated instance

After testing your machines, you are ready to cut over to your instance on Google Cloud.

  1. Plan for a short window of downtime. You can estimate the downtime based on your experience during the testing phase). During the window, you create the latest target test machines and confirm that the target workload works correctly.
  2. Stop or disable access to your source server in order to prevent user access and potential last minute changes that may not replicate to the target VMs.
  3. After you are certain that no changes can be made to your source servers, select the servers on the VM Migration Console and click Cutover to launch a final copy of the target VMs most up-to-date application state.

Once the target machines have been successfully created, repeat your sanity tests to ensure everything works as expected, and then configure your DNS servers to point all users to the new target machines.

Post-migration steps

Install guest environment packages

If you are experiencing problems logging into the VM instance, you might need to install the Compute Engine guest packages on the instance. The guest packages will set up things like user accounts, the instance hostname, support for shutdown and startup scripts, and so on.

To install the guest environment, see installing the guest environment.

Remove the CloudEndure agent from source servers

When you are certain that the live migrated machines in the target region are now in use, and you no longer need to create additional target machines, remove the CloudEndure agent from the source servers:

  1. In the VM Migration Console, check the boxes next to the machines you want to remove the migration agent from.
  2. Click Machine Actions, and select Remove machines from this console.

This stops the continuous replication and uninstalls the VM Migration agent from the source machine.

Known issues

CloudEndure licensing issues

The migration agent license is valid for a limited time once it is installed on a source machine. Each source machine's agent license is a separate license.

If you get license errors from the CloudEndure console, such as Selected machine has an expired license and is therefore not Launchable., reach out to for assistance.

Service account issues

My service account was deleted and the VM migration service cannot move forward in the replication process.

If you deleted the service account that was originally being used for migration, follow the steps to create a new account and add the new JSON key to the CloudEndure account.

My service account permissions were changed and the VM migration service cannot move forward in the replication process.

If you changed the permissions of the service account or otherwise modified the account, reconfigure your account according to the steps to create a new account.

Limitations for Windows Server 2003 instances

Before migrating a Windows Server 2003 environment to Google Cloud, be aware of the following limitations:

  • You must not assign an external IP address to your Windows Server 2003 instance. Because support for Windows Server 2003 has ended, your instance might be vulnerable to security exploits. Use a VPC network to set up a private IP address for your instances.
  • After you have migrated your Windows Server 2003 VMs, your copies of Windows are not automatically activated. You must activate Windows on each instance using a Multiple Activation Key (MAK), which is part of your volume licensing agreement with Microsoft.
  • Support for Windows Server 2003 on Google Cloud is limited. Because Microsoft no longer supports Windows Server 2003, you might run into issues that cannot be fully resolved.
  • The following features of Compute Engine are not available for Windows Server 2003 instances:

    • Windows Server 2003 does not support the Volume Shadow Copy Service (VSS) for disk snapshots. If you want to take a snapshot of your disks, you must use the standard snapshot system.
    • Your instance cannot have multiple network interfaces.
    • Your cannot add GPUs or TensorFlow processing units (TPUs) to your instance.
  • Depending on your edition of Windows Server 2003, hardware support might be limited. During the migration process, you must select a machine type that is supported for your edition of Windows Server 2003.

    For example, Windows Server 2003 Standard Edition supports a maximum of 4 vCPUs, and 32 GB of memory. During the migration, you must choose a machine type that has a maximum of 4 vCPUs and 32 GB of memory.

  • The Windows guest environment for Compute Engine, which transfers information between Compute Engine and your VM, supports the following limited set of features:

    • You can create new user accounts on the migrated instance from the Console, gcloud command-line tool, or the API.
    • You can reset the password for user accounts that are already on the instance.
  • Windows Stackdriver Monitoring and Stackdriver Logging agents are not currently supported for Windows Server 2003 instances.

What's next

Var denne side nyttig? Giv os en anmeldelse af den:

Send feedback om...

Compute Engine Documentation