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 Vultr Console 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.

1. Create a snapshot of the GCP instance disk using the Google Cloud Console or the gcloud command.

   CONSOLE

   Copy

   $ gcloud compute disks snapshot <DISK_NAME> --snapshot-names=<SNAPSHOT_NAME> --zone=<ZONE>

   Explain Code

   Powered by Vultr AgentBeta

   Replace <DISK_NAME>, <SNAPSHOT_NAME>, and <ZONE> with your values.

2. Alternatively, create a machine image that includes all attached disks and metadata.

   CONSOLE

   Copy

   $ gcloud compute machine-images create <IMAGE_NAME> --source-instance=<INSTANCE_NAME> --source-instance-zone=<ZONE>

   Explain Code

   Powered by Vultr AgentBeta

   Replace <IMAGE_NAME>, <INSTANCE_NAME>, and <ZONE> with your values.

3. Verify the backup was created successfully.

   CONSOLE

   Copy

   $ gcloud compute snapshots list

   Explain Code

   Powered by Vultr AgentBeta

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.

1. List running services to identify those that must be migrated.

   CONSOLE

   Copy

   $ systemctl list-units --type=service

   Explain Code

   Powered by Vultr AgentBeta

2. List ports used by applications.

   CONSOLE

   Copy

   $ ss -tuln

   Explain Code

   Powered by Vultr AgentBeta

3. View user-specific cron job files.

   CONSOLE

   Copy

   $ sudo ls -l /var/spool/cron/crontabs/

   Explain Code

   Powered by Vultr AgentBeta

   Each file corresponds to the active cron jobs of a Linux user.

4. Check the system-wide cron job file.

   CONSOLE

   Copy

   $ cat /etc/crontab

   Explain Code

   Powered by Vultr AgentBeta

   If the file contains entries, include them in the migration plan.

5. View existing user accounts.

   CONSOLE

   Copy

   $ cat /etc/passwd

   Explain Code

   Powered by Vultr AgentBeta

   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.

6. View existing user groups.

   CONSOLE

   Copy

   $ cat /etc/group

   Explain Code

   Powered by Vultr AgentBeta

   Each line follows the format:

   group_name:x:GID:member_list
   • GID: Unique group ID number.
   • member_list: Comma-separated users in the group.

7. List installed packages.

   • Debian/Ubuntu:

     CONSOLE

     Copy

     $ dpkg --get-selections

     Explain Code

     Powered by Vultr AgentBeta

   • CentOS/RHEL:

     CONSOLE

     Copy

     $ rpm -qa

     Explain Code

     Powered by Vultr AgentBeta

8. 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.

9. 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.

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

   CONSOLE

   Copy

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

   Explain Code

   Powered by Vultr AgentBeta

   Output:

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

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

   CONSOLE

   Copy

   $ 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

   Explain Code

   Powered by Vultr AgentBeta

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

3. Transfer these files to the Vultr instance.

   CONSOLE

   Copy

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

   Explain Code

   Powered by Vultr AgentBeta

   Replace <VULTR_IP> with your Vultr instance IP address.

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

   CONSOLE

   Copy

   $ 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

   Explain Code

   Powered by Vultr AgentBeta

5. Transfer user home directories from the GCP instance to the Vultr instance. Replace <USERNAME> with the actual username.

   CONSOLE

   Copy

   $ sudo rsync -avz /home/<USERNAME>/ linuxuser@<VULTR_IP>:~/<USERNAME>/

   Explain Code

   Powered by Vultr AgentBeta

   Repeat this command for each user directory you need to migrate.

6. On the Vultr instance, move the directories to /home/ and set correct ownership and permissions.

   CONSOLE

   Copy

   $ sudo mv ~/<USERNAME> /home/<USERNAME>
   $ sudo chown -R <USERNAME>:<USERNAME> /home/<USERNAME>
   $ sudo chmod 700 /home/<USERNAME>

   Explain Code

   Powered by Vultr AgentBeta

   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.

1. On the Vultr instance, install all necessary runtime components, such as web servers, application runtimes, and databases.

   • For Debian/Ubuntu servers:

     CONSOLE

     Copy

     $ sudo apt update
     $ sudo apt install -y <required-packages>

     Explain Code

     Powered by Vultr AgentBeta

   • For RHEL/CentOS/Fedora servers:

     CONSOLE

     Copy

     $ sudo dnf install -y <required-packages>

     Explain Code

     Powered by Vultr AgentBeta

2. Copy the complete application directory from the source instance to the destination instance using rsync or another secure transfer tool.

   CONSOLE

   Copy

   $ sudo rsync -avz /path/to/application/ linuxuser@<VULTR_IP>:~/application/

   Explain Code

   Powered by Vultr AgentBeta

   Replace /path/to/application/ with the actual application directory path.

3. Move the application directory to the destination path.

   CONSOLE

   Copy

   $ mv ~/application /path/to/application

   Explain Code

   Powered by Vultr AgentBeta

4. On the Vultr instance, ensure that the application files are owned by the appropriate user and group, and have correct permissions.

   CONSOLE

   Copy

   $ sudo chown -R <app_user>:<app_group> /path/to/application
   $ sudo chmod -R 755 /path/to/application

   Explain Code

   Powered by Vultr AgentBeta

5. 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.

6. Edit configuration files to reflect the new environment for example, updating database connection details, file paths, or API endpoints.

7. Set up your web server (e.g., Nginx, Apache) or application process manager (e.g., Gunicorn, PM2) to serve the application.

8. On the GCP instance, list existing cron jobs.

   CONSOLE

   Copy

   $ crontab -l

   Explain Code

   Powered by Vultr AgentBeta

   On the Vultr instance, add the same cron jobs.

   CONSOLE

   Copy

   $ crontab -e

   Explain Code

   Powered by Vultr AgentBeta

   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.

9. 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

     Copy

     $ sudo ufw allow 80,443/tcp
     $ sudo ufw reload

     Explain Code

     Powered by Vultr AgentBeta

   • firewalld (RHEL/CentOS/Fedora):

     CONSOLE

     Copy

     $ sudo firewall-cmd --permanent --add-service=http
     $ sudo firewall-cmd --permanent --add-service=https
     $ sudo firewall-cmd --reload

     Explain Code

     Powered by Vultr AgentBeta

   • iptables (generic):

     CONSOLE

     Copy

     $ sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
     $ sudo iptables -A INPUT -p tcp --dport 443 -j ACCEPT
     $ sudo service iptables save

     Explain Code

     Powered by Vultr AgentBeta

   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.

10. Enable the site configuration and restart the necessary services.

    CONSOLE

    Copy

    $ sudo systemctl restart <service_name>

    Explain Code

    Powered by Vultr AgentBeta

11. 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.

1. Check the database versions on both instances.

   CONSOLE

   Copy

   $ mysql --version

   Explain Code

   Powered by Vultr AgentBeta

   Verify the versions match or are compatible.

2. Export all databases from the GCP instance. Replace db_user with the actual username.

   CONSOLE

   Copy

   $ mysqldump -u db_user -p --all-databases > all_databases_backup.sql

   Explain Code

   Powered by Vultr AgentBeta

   The command prompts for the user's password before creating all_databases_backup.sql.

3. Transfer the dump file to the Vultr instance using rsync. Replace 192.0.2.1 with the destination IP.

   CONSOLE

   Copy

   $ rsync -avz /home/linuxuser/all_databases_backup.sql linuxuser@192.0.2.1:/home/linuxuser/

   Explain Code

   Powered by Vultr AgentBeta

4. Import the dump into the target database server.

   CONSOLE

   Copy

   $ mysql -u root -p < /home/linuxuser/all_databases_backup.sql

   Explain Code

   Powered by Vultr AgentBeta

   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.

1. Check that all relevant services are active.

   CONSOLE

   Copy

   $ sudo systemctl status <service_name>

   Explain Code

   Powered by Vultr AgentBeta

   Replace <service_name> with your service names such as nginx, apache2, mysql, or other application services.

2. Verify cron jobs are configured correctly.

   CONSOLE

   Copy

   $ sudo crontab -l -u <username>

   Explain Code

   Powered by Vultr AgentBeta

   Replace <username> with the relevant user account.

3. View server performance and resource usage.

   CONSOLE

   Copy

   $ top

   Explain Code

   Powered by Vultr AgentBeta

   Press q to exit. Review CPU usage, load averages, and running processes.

4. Check RAM utilization.

   CONSOLE

   Copy

   $ free -h

   Explain Code

   Powered by Vultr AgentBeta

5. Inspect application logs for warnings or errors.

   CONSOLE

   Copy

   $ sudo tail -n 50 /var/log/<application>/error.log

   Explain Code

   Powered by Vultr AgentBeta

   Replace <application> with the relevant log path for your services.

6. Test web applications and API endpoints. If using temporary domains or hosts file overrides, expect certificate warnings.

7. Run application health checks and confirm endpoints respond correctly.

8. Monitor system resources for anomalies using the Vultr Console or command-line tools.

Cutover Checklist

1. Lower DNS TTL at least 30min hours before migration to speed propagation.
2. Test the new instance using a temporary subdomain or local hosts file entry before updating DNS records.
3. Update DNS records to point production domains to the Vultr instance and monitor application logs, health checks, and system metrics after traffic shifts.
4. 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.