🌍 Intercontinental VM Migration Using Google Cloud Storage Snapshots Over a Private Network in Under 30 Minutes

User Story

In this real-world project, I served as a Cloud Specialist responsible for migrating a critical application and MySQL database for a major U.S. healthcare clinic. The challenge was to perform an intercontinental workload migration from the us-west1 (Oregon) region to australia-southeast1 (Sydney) using only private Google Cloud infrastructure. The entire process was executed with a focus on security, speed, and availability, completing the migration in under 30 minutes.

Solution Architecture

🧱 Project Structure

Part 1 — Infrastructure Setup in Oregon (USA)

Initially, we provisioned two virtual machines (VMs):

• usa-application-01 (Node.js application)
• usa-database-01 (MySQL 8.0 database)

Both were created in zone us-west1-b running Debian 12 (Bookworm). After setting up services, the application was configured to connect to the database via private IP, ensuring internal-only communication.

Key configurations:

• usa-database-01: MySQL setup with secure credentials.

• usa-application-01: Node.js application configured with updated index.js, dependencies installed via NPM, and port 3000 opened via firewall rule for testing.

We tested the app by registering sample patients: “Mike Mouse,” “Doug Dog,” and “Cirrus Cloud.”

🔄 Part 2 — Migration with Snapshots via Private Network

Once everything was validated, we began the intercontinental migration with zero visible downtime and no exposure to the public internet, following these steps:

📸 Creating Snapshots

With both VMs stopped, we created snapshots of the disk volumes:

gcloud compute disks snapshot usa-application-01 \
  --snapshot-names usa-application-snapshot --zone us-west1-b

gcloud compute disks snapshot usa-database-01 \
  --snapshot-names usa-database-snapshot --zone us-west1-b

🌐 Replicating to Australia

Next, we created new disks in australia-southeast1-a using the snapshots as source:

gcloud compute disks create aus-app01 \
  --source-snapshot usa-application-snapshot --zone australia-southeast1-a

gcloud compute disks create aus-db01 \
  --source-snapshot usa-database-snapshot --zone australia-southeast1-a

🖥️ Provisioning New VMs

We then launched two new VMs using the newly created disks:

gcloud compute instances create aus-app01 \
  --machine-type e2-micro --zone australia-southeast1-a \
  --disk name=aus-app01,boot=yes,mode=rw

gcloud compute instances create aus-db01 \
  --machine-type e2-micro --zone australia-southeast1-a \
  --disk name=aus-db01,boot=yes,mode=rw

With the VMs running, we updated index.js to point to the new database's private IP and restarted the app:

npm install
node src/index.js

✅ Validation and Final Check

Access the application via the public IP of aus-app01:3000 and confirm that all data migrated successfully — including the sample records from the original deployment in the U.S.

• 🔒 Entire migration over private internal network
• ⚡ Total migration and boot time: ~30 minutes
• 🌐 Improved latency in the new region (Australia)

📷 Evidence

• Screenshot of all 4 VMs (2 in the U.S., 2 in Australia)

• Screenshot of the application running in aus-app01 with migrated records

🧹 Resource Cleanup

• Delete unused VMs, disks, and snapshots to prevent unnecessary billing
• Retain logs via Cloud Logging for traceability and auditing

🧠 Conclusion

This project showcases the power and efficiency of Google Cloud Platform in handling critical, sensitive, and geographically distributed migrations. Leveraging DevOps practices and native tools such as snapshots and internal networks, we achieved a secure, fast, and scalable migration solution — with zero exposure to the public internet.