Cross-Cloud Migration Data Strategies: Weighing Images, Sync, and Object Storage

The core challenge of cross-cloud migration is how to transfer the data. Since direct image interoperability between different clouds is usually not supported, you must choose from several transmission methods.

The selection criteria are primarily based on three factors: data volume, acceptable downtime, and network conditions.

Comparison of Four Solutions

Solution 1: rsync Incremental Sync (Recommended)

The advantage lies in the ability to pre-sync multiple times. During the official cutover, only the incremental changes need to be synchronized, resulting in very short downtime.

# ① Pre-sync (can be executed repeatedly without interrupting business)
rsync -avz --delete 
  -e 'ssh -p 22' 
  /var/www/html/ root@TargetIP:/var/www/html/

# ② Before the official cutover, stop writes and sync again (this time will be fast)
rsync -avz --delete 
  -e 'ssh -p 22' 
  /var/www/html/ root@TargetIP:/var/www/html/

# ③ Verify consistency
# The file count on source and target should match
find /var/www/html -type f | wc -l

# Exclude directories that do not need syncing
rsync -avz --delete 
  --exclude='cache/' --exclude='*.log' 
  /var/www/html/ root@TargetIP:/var/www/html/

# Limit speed (to avoid saturating bandwidth and affecting business)
rsync -avz --bwlimit=10000 ...   # Unit: KB/s

--bwlimit is critical in production environments. When syncing hundreds of GB, saturating the bandwidth will slow down running services.

Solution 2: Object Storage Relay

When dealing with large data volumes or unstable direct transmission between endpoints, use object storage as an intermediate layer:

# ① Package and upload to object storage
tar -czf /tmp/site.tar.gz -C /var/www html

# All major cloud providers offer CLI tools with similar usage
ossutil cp /tmp/site.tar.gz oss://bucket/site.tar.gz

# ② Download on the target side
ossutil cp oss://bucket/site.tar.gz /tmp/site.tar.gz
tar -xzf /tmp/site.tar.gz -C /var/www/

Database Migration

Databases are typically handled separately and not synced along with files:

# ① Export (with full parameters)
mysqldump -u root -p --default-character-set=utf8mb4 
  --single-transaction --routines --triggers --events dbname > db.sql

# ② Transfer (use scp for small files, object storage for large files)
scp db.sql root@TargetIP:/tmp/

# ③ Create database and import on the target side
mysql -e "CREATE DATABASE dbname DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql --default-character-set=utf8mb4 dbname < db.sql

If the database is large and extremely short downtime is required, consider using Master-Slave Replication: set the target as a slave to catch up before switching. However, this requires network connectivity between both ends and correct configuration.

Migration Steps

① Prepare the environment on the target side (compare versions and extensions)
② Pre-sync files (can be done multiple times without affecting business)
③ Pre-import database (do it once first to verify the process)
④ Schedule the cutover window
⑤ Stop writes (or enter maintenance mode)
⑥ Final incremental sync + database export/import
⑦ Validate on the target side (using hosts file or temporary methods)
⑧ Switch DNS resolution
⑨ Retain the old environment for a period

Key Considerations

① Compare Environments First

# Compare target and source (do not rely on memory for installation)
php -v
php -m | sort > /tmp/new_modules.txt
diff /tmp/old_modules.txt /tmp/new_modules.txt

mysql --version
nginx -v

② Maintain Data Consistency

# Stop writes before cutover to prevent data divergence
# For businesses that cannot stop writing (e.g., e-commerce orders), consider:
# - Scheduling the cutover during off-peak hours
# - Or accepting that some data may require manual merging

For businesses that cannot accept write divergence, writes must be stopped before the cutover. Otherwise, if both databases write independently, the cost of merging far exceeds the brief downtime.

③ Do Not Decommission the Old Environment Too Early

# Retain the old environment for at least 48 hours after cutover
# Process it only after confirming the new environment is stable

Decision Tree

Select Migration Solution
├─ Small Data Volume (within tens of GB)
│  └─ rsync Incremental Sync (shortest downtime)
├─ Large Data Volume (over hundreds of GB)
│  ├─ Stable Network → rsync + Speed Limiting
│  └─ Unstable Network → Object Storage Relay
├─ Full Server Migration
│  └─ Image (note format compatibility)
└─ Database
   ├─ Standard: Dump + Import
   └─ Extremely Short Downtime Required: Master-Slave Replication Catch-up

General Steps
├─ Compare and confirm target environment first (do not rely on memory)
├─ Pre-sync + Pre-import (run through the process first)
├─ Stop writes during cutover window
└─ Retain old environment for 48 hours

Scenario Simulation: Cross-Cloud Migration Interrupted Mid-Transfer

Phenomenon: During a cross-cloud platform migration with a large data volume,
the transfer was interrupted halfway; after retransmission, the file counts on both sides did not match, and it was impossible to determine which files were complete and which were not.

1. Abandon the intuition of “full retransfer” → Transferring large volumes over the public internet almost inevitably leads to interruptions; starting over will likely result in another interruption.
2. Switch to a method supporting breakpoint resume → Incremental replication only transfers differences. If interrupted, resuming continues from where it left off rather than starting from scratch.
3. Migrate static data first → Move rarely changing content like images and attachments first to reduce the amount transferred during the final cutover.
4. Place database migration in the final cutover window → The rate of data change is the core issue; the shorter the cutover window, the smaller the difference between the two sides.
5. Verify consistency using checksums → After transfer, calculate checksums on both sides for comparison instead of just comparing file counts.
6. Keep the source site serving until verification is complete → Have a fallback ready before switching.

# Breakpoint resume + Re-executable
rsync -avzP --partial /source/dir/ user@TargetIP:/target/dir/
# -P is equivalent to --partial --progress; running it again after interruption resumes the transfer

# Verification: Confirm consistency without actual transfer
rsync -avnc /source/dir/ user@TargetIP:/target/dir/ | head -20

# Database: Export first, compress, transfer, then import on target
mysqldump --single-transaction --quick dbname | gzip > dump.sql.gz

# Final incremental sync before cutover
rsync -avzP --delete /source/dir/ user@TargetIP:/target/dir/

Root Cause: Using a method that does not support resume to transfer large data volumes in one go.
After interruption, it is impossible to judge which files are complete, forcing a full restart, which will likely fail again.

Two Key Takeaways:

• Large-scale migrations must use methods that support breakpoint resume and can be rerun at any time.
  Tools that require restarting from scratch upon failure are nearly impossible to complete in cross-public-network scenarios.
• Consistency must be verified using checksums, not just file counts.
  It is very common for file counts to match while content is incomplete; only checksums can confirm true consistency.

8 Common Pitfalls

1. No speed limiting during sync: Slows down online services.
2. No pre-sync, starting transfer only at cutover: Results in extremely long downtime.
3. Installing target environment based on memory: Missing extensions.
4. Allowing simultaneous writes on both sides during cutover: Data divergence with high merge costs.
5. Switching DNS without validation: Issues directly exposed to users.
6. Decommissioning old environment immediately after cutover: No fallback option.
7. Handling database and files separately but out of sync: Version mismatches.
8. Ignoring character sets: Garbled text after import.

Real Customer Feedback (From Cloud Market Reviews and Inquiries for Similar Products)

The following excerpts are taken from real buyer reviews and inquiries for similar operations services on Alibaba Cloud / Tencent Cloud / Huawei Cloud marketplaces (service providers include our store and peers, provided solely for reference of real feedback, not fictional tickets from this site):

10***31 2022-11-17 5.0 On-time delivery | Timely response | Affordable price System migration successful 10***31 2022-11-17 5.0 Skilled technology | Safe and reliable | Affordable price Migration successful

1****n Rating: 5.0 points 2018-01-04 18:04

45***76 2021-04-14 5.0 On-time delivery Excellent