How to Migrate Google Cloud Compute Engine Instances to Vultr Cloud Compute

Vultr Cloud Compute provides virtual servers that run applications, host websites, and support workloads in the cloud. Migrating an instance from Google Cloud Compute (GCP) to Vultr offers benefits such as modern hardware for improved performance, an intuitive customer portal for management, and predictable, competitive pricing.

This guide explains the application-level migration process from GCP to Vultr. It shows how to back up the source instance, inspect system configuration, migrate user accounts and groups, transfer applications and data using rsync, migrate databases, and validate functionality after cutover. This approach avoids GCP-specific configurations that may not work on Vultr and provides a clean, controlled migration path.

Prerequisites

Before you begin, you need to:

Have access to a Google Compute Engine instance as a non-root user with sudo privileges.
Have access to a Vultr Cloud Compute instance with equal or greater resources (CPU, memory, disk).
Ensure SSH key-based authentication is configured between the source and destination instances for secure, password-less rsync transfers.
Record critical application details such as installed packages, configuration paths, and active services before starting migration.

Why Application-Level Migration?

This guide uses application-level migration rather than raw disk image migration. Raw images from GCP often include cloud-specific configurations (network settings, Cloud Init scripts, APT repositories) that may not work properly on Vultr, leading to boot failures or misconfigurations. Application-level migration provides:

Clean environment: Start with a fresh Vultr instance, avoiding GCP-specific settings.
Selective transfer: Migrate only necessary applications, users, and data.
Flexibility: Upgrade to a newer OS version or restructure during migration.
Minimal downtime: Move workloads incrementally and test before cutover.

Backup the Source GCP Instance

Before starting migration, create a backup of the source instance to protect against data loss or mistakes during the process.

Create a snapshot of the GCP instance disk using the Google Cloud Console or the gcloud command.
console
```
$ gcloud compute disks snapshot <DISK_NAME> --snapshot-names=<SNAPSHOT_NAME> --zone=<ZONE>
```
Replace <DISK_NAME>, <SNAPSHOT_NAME>, and <ZONE> with your values.
Alternatively, create a machine image that includes all attached disks and metadata.
console
```
$ gcloud compute machine-images create <IMAGE_NAME> --source-instance=<INSTANCE_NAME> --source-instance-zone=<ZONE>
```
Replace <IMAGE_NAME>, <INSTANCE_NAME>, and <ZONE> with your values.
Verify the backup was created successfully.
console
```
$ gcloud compute snapshots list
```

Keep this backup until migration is complete and the Vultr instance is stable in production.

Inspect Your GCP Instance Before Migration

Before starting the migration, collect details about the current GCP instance. Record active services, open ports, cron jobs, user accounts, groups, installed packages, and important configuration paths. This information helps verify that all components work correctly after migration.

List running services to identify those that must be migrated.
console
```
$ systemctl list-units --type=service
```
List ports used by applications.
console
```
$ ss -tuln
```
View user-specific cron job files.
console
```
$ sudo ls -l /var/spool/cron/crontabs/
```
Each file corresponds to the active cron jobs of a Linux user.
Check the system-wide cron job file.
console
```
$ cat /etc/crontab
```
If the file contains entries, include them in the migration plan.
View existing user accounts.
console
```
$ cat /etc/passwd
```
Each line follows the format:
```
username:x:UID:GID:comment:home_directory:login_shell
```
- UID: Unique user ID number.
- GID: Primary group ID number.
Normal user accounts typically have UID values above 1000.
View existing user groups.
console
```
$ cat /etc/group
```
Each line follows the format:
```
group_name:x:GID:member_list
```
- GID: Unique group ID number.
- member_list: Comma-separated users in the group.
List installed packages.
- Debian/Ubuntu:
  console
  $ dpkg --get-selections
- CentOS/RHEL:
  console
  $ rpm -qa
Record critical data and configuration paths, such as /etc/nginx/, /var/www/, /opt/app/, and database directories.

Note
The above files and configuration directories depend on your application setup. Refer to the official application documentation to identify other important directories specific to your environment.
If the instance uses GCP VPC firewall rules, recreate them on Vultr by configuring a Firewall Group and linking it to the target instance.

Migrate User Accounts and Groups

Migrate user accounts with UID values above 1000 (normal user accounts). Avoid migrating system users (UID < 1000) or cloud-specific accounts (e.g., google-sudoers). Do not migrate application-specific users; most applications recreate their own user accounts during installation.

On the GCP instance, list user accounts with UID >= 1000.

                            console
                            
$ awk -F: '$3 >= 1000 && $3 != 65534 {print $1":"$3":"$4":"$5":"$6":"$7}' /etc/passwd

Output:

appuser:1001:1001::/home/appuser:/bin/bash

On the GCP instance, export user and group information to text files, excluding nobody and cloud-specific accounts.

                            console
                            
                        
$ sudo awk -F: '$3 >= 1000 && $3 != 65534 && $1 !~ /^(google-sudoers|ubuntu)$/ {print}' /etc/passwd > users_to_migrate.txt
$ sudo awk -F: '$3 >= 1000 && $3 != 65534 && $1 !~ /^(google-sudoers|ubuntu)$/ {print}' /etc/group > groups_to_migrate.txt
$ sudo awk -F: 'NR==FNR {users[$1]; next} $1 in users' users_to_migrate.txt /etc/shadow > shadow_to_migrate.txt
$ sudo awk -F: 'NR==FNR {users[$1]; next} $1 in users' users_to_migrate.txt /etc/gshadow > gshadow_to_migrate.txt

Review all four exported files and confirm that only the intended user accounts are included. Manually remove any unwanted or inconsistent entries before proceeding.

Transfer these files to the Vultr instance.

                            console
                            
$ rsync -avzP users_to_migrate.txt groups_to_migrate.txt shadow_to_migrate.txt gshadow_to_migrate.txt linuxuser@<VULTR_IP>:/tmp/

Replace <VULTR_IP> with your Vultr instance IP address.

On the Vultr instance, append the user and group entries to the appropriate files.

                            console
                            
                        
$ sudo tee -a /etc/passwd < /tmp/users_to_migrate.txt
$ sudo tee -a /etc/group < /tmp/groups_to_migrate.txt
$ sudo tee -a /etc/shadow < /tmp/shadow_to_migrate.txt
$ sudo tee -a /etc/gshadow < /tmp/gshadow_to_migrate.txt

Transfer user home directories from the GCP instance to the Vultr instance. Replace <USERNAME> with the actual username.
console
```
$ sudo rsync -avz /home/<USERNAME>/ linuxuser@<VULTR_IP>:~/<USERNAME>/
```
Repeat this command for each user directory you need to migrate.
On the Vultr instance, move the directories to /home/ and set correct ownership and permissions.
console
```
$ sudo mv ~/<USERNAME> /home/<USERNAME>
$ sudo chown -R <USERNAME>:<USERNAME> /home/<USERNAME>
$ sudo chmod 700 /home/<USERNAME>
```
Verify that each migrated home directory exists under /home/, is owned by the correct user and group, and has secure permissions.

Migrate Applications

Application migration steps vary based on the type of application. Follow these general steps to migrate any web or server-based application. Refer to the official documentation for application-specific best practices.

On the Vultr instance, install all necessary runtime components, such as web servers, application runtimes, and databases.
- For Debian/Ubuntu servers:
  console
  $ sudo apt update $ sudo apt install -y <required-packages>
- For RHEL/CentOS/Fedora servers:
  console
  $ sudo dnf install -y <required-packages>
Copy the complete application directory from the source instance to the destination instance using rsync or another secure transfer tool.
console
```
$ sudo rsync -avz /path/to/application/ linuxuser@<VULTR_IP>:~/application/
```
Replace /path/to/application/ with the actual application directory path.
Move the application directory to the destination path.
console
```
$ mv ~/application /path/to/application
```
On the Vultr instance, ensure that the application files are owned by the appropriate user and group, and have correct permissions.
console
```
$ sudo chown -R <app_user>:<app_group> /path/to/application
$ sudo chmod -R 755 /path/to/application
```
Export the database from the source instance, transfer it, and import it into the database server on the destination instance. Refer to the Migrate Database section for detailed steps.
Edit configuration files to reflect the new environment for example, updating database connection details, file paths, or API endpoints.
Set up your web server (e.g., Nginx, Apache) or application process manager (e.g., Gunicorn, PM2) to serve the application.
On the GCP instance, list existing cron jobs.
console
```
$ crontab -l
```
On the Vultr instance, add the same cron jobs.
console
```
$ crontab -e
```
If any cron jobs reference custom scripts, copy those scripts from the GCP instance to the Vultr instance first. Ensure the scripts retain their original paths and permissions before re-creating the cron jobs.
Open the necessary ports in the firewall on the Vultr instance to allow required traffic. Use one of the following tools based on your instance's firewall configuration.
- UFW (Ubuntu/Debian):
  console
  $ sudo ufw allow 80,443/tcp $ sudo ufw reload
- firewalld (RHEL/CentOS/Fedora):
  console
  $ sudo firewall-cmd --permanent --add-service=http $ sudo firewall-cmd --permanent --add-service=https $ sudo firewall-cmd --reload
- iptables (generic):
  console
  $ sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT $ sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT $ sudo service iptables save
Note
The above example exposes HTTP (port 80) and HTTPS (port 443). Modify the commands as needed to open the specific ports required by your application.
Enable the site configuration and restart the necessary services.
console
```
$ sudo systemctl restart <service_name>
```
Access the application using the Vultr instance's IP or temporary domain to verify that it functions correctly before updating DNS records.

Migrating a Database

To migrate databases, use tools such as mysqldump to export data from the source instance, transfer the dump file to the destination, and restore it. The example below demonstrates the process with MySQL or MariaDB.

Note

This guide demonstrates MySQL and MariaDB server migration. For other database systems such as PostgreSQL or MongoDB refer to the official backup and restore documentation for those platforms.

Check the database versions on both instances.
console
```
$ mysql --version
```
Verify the versions match or are compatible.
Export all databases from the GCP instance. Replace db_user with the actual username.
console
```
$ mysqldump -u db_user -p --all-databases > all_databases_backup.sql
```
The command prompts for the user's password before creating all_databases_backup.sql.
Transfer the dump file to the Vultr instance using rsync. Replace 192.0.2.1 with the destination IP.
console
```
$ rsync -avz /home/linuxuser/all_databases_backup.sql linuxuser@192.0.2.1:/home/linuxuser/
```
Import the dump into the target database server.
console
```
$ mysql -u root -p < /home/linuxuser/all_databases_backup.sql
```
This restores all databases, users, and privileges from the backup file.

Test Service Functionality After Migration

After completing migration, verify that applications and services run as expected.

Check that all relevant services are active.
console
```
$ sudo systemctl status <service_name>
```
Replace <service_name> with your service names such as nginx, apache2, mysql, or other application services.
Verify cron jobs are configured correctly.
console
```
$ sudo crontab -l -u <username>
```
Replace <username> with the relevant user account.
View server performance and resource usage.
console
```
$ top
```
Press q to exit. Review CPU usage, load averages, and running processes.
Check RAM utilization.
console
```
$ free -h
```
Inspect application logs for warnings or errors.
console
```
$ sudo tail -n 50 /var/log/<application>/error.log
```
Replace <application> with the relevant log path for your services.
Test web applications and API endpoints. If using temporary domains or hosts file overrides, expect certificate warnings.
Run application health checks and confirm endpoints respond correctly.
Monitor system resources for anomalies using the Vultr Customer Portal or command-line tools.

Cutover Checklist

Lower DNS TTL at least 30min hours before migration to speed propagation.
Test the new instance using a temporary subdomain or local hosts file entry before updating DNS records.
Update DNS records to point production domains to the Vultr instance and monitor application logs, health checks, and system metrics after traffic shifts.
Keep the GCP instance online for a fallback period, then decommission it after confirming stable operation on Vultr.

Conclusion

You have successfully migrated a Google Cloud Compute instance to Vultr using application-level migration. This approach avoids GCP-specific configurations that may cause issues on Vultr and provides a clean, controlled migration path. Your applications now run on Vultr's modern infrastructure with predictable pricing and global availability.

Tags:

Vultr Cloud Compute

How to Migrate Google Cloud Compute Engine Instances to Vultr Cloud Compute

Prerequisites

Why Application-Level Migration?

Backup the Source GCP Instance

Inspect Your GCP Instance Before Migration

Migrate User Accounts and Groups

Migrate Applications

Migrating a Database

Test Service Functionality After Migration

Cutover Checklist

Conclusion

Comments

Products

Features

Solutions

Marketplace

Resources

Company

Tech Talks

Vultr Blogs