Cross-Cloud Server Migration Guide: Complete Process from Provider A to B

Cross-Cloud Server Migration Guide: Complete Process from Provider A to Provider B

Switching cloud providers is common in real-world operations — driven by pricing factors, changing performance requirements, or promotions from another provider. But if the migration process is not handled properly, it can lead to prolonged website downtime or even data loss. This article provides a standardized migration workflow.

1. Pre-Migration Preparation

1.1 Assess Differences Between Old and New Environments

Before doing anything, compare the differences between old and new providers:

1.2 Create Migration Checklist

□ List all servers
□ Record current configuration (CPU/RAM/Disk/Bandwidth)
□ Export security group/firewall rules
□ Collect database connection information
□ Record scheduled tasks (crontab)
□ Backup SSL certificates and private keys
□ Export DNS records
□ Organize environment variables and configuration files

1.3 Plan the Migration Timeline

Splitting the migration into phases that can be rolled back is far safer than moving everything at once. A typical 3-7 day timeline:

Put the "switch" at off-peak hours like early morning or the weekend, and tell colleagues in advance so nobody is running batch jobs during the cutover.

2. Data Migration

2.1 File Migration

Using rsync is the safest and most efficient method:

# Full sync
rsync -avz --progress /var/www/ user@new-server:/var/www/

# Incremental sync (final sync before switchover)
rsync -avz --delete --progress /var/www/ user@new-server:/var/www/

2.2 Database Migration

# Export from source server
mysqldump -u root -p --single-transaction --quick --all-databases > all-dbs.sql

# Import to target server
mysql -u root -p < all-dbs.sql

# Or pipe directly
mysqldump -u root -p --single-transaction --all-databases | ssh user@new-server "mysql -u root -p"

2.3 Configuration Migration

Copy the following configuration files to the new server:

• Nginx/Apache configuration files
• PHP-FPM configuration
• Redis/Memcached configuration
• Supervisor process management configuration
• Environment variables (.env files)

2.4 Object Storage and Incremental Sync

If site images and attachments live in OSS/COS/S3-style object storage, rclone gives far more reliable incremental sync than download-and-reupload:

# Alibaba Cloud OSS -> Tencent Cloud COS (after configuring both remotes in rclone)
rclone copy aliyun:my-bucket tencent:my-bucket --progress --checksum

# Sync only files added in the last 7 days
rclone copy aliyun:my-bucket tencent:my-bucket --max-age 168h

For the filesystem, run rsync -avz --delete one final time inside the maintenance window, using -c (checksum) to verify by content rather than timestamp. For the database, export a consistent snapshot with --single-transaction plus --master-data=2, then apply one more incremental sync before cutover so you do not lose the last few minutes of data.

2.5 Data Validation

Before switching, spot-check consistency on the target database:

# Compare table counts
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables;"

# Spot-check row counts on core tables
mysql -u root -p -e "SELECT COUNT(*) FROM orders; SELECT COUNT(*) FROM users;"

# Compare file counts and sizes (dry run first)
rsync -avz --delete --dry-run /var/www/ user@new-server:/var/www/ | tail -5

3. Environment Reconstruction

3.1 Quick Reconstruction Methods

Method 1: Manual Installation (Recommended)

Reinstall the software stack on the new server to ensure latest versions and clean configuration:

# Ubuntu/Debian
apt update && apt install nginx mysql-server php-fpm redis-server

# Then copy configuration files
scp old-server:/etc/nginx/sites-enabled/* /etc/nginx/sites-enabled/

Method 2: Configuration Management Tools

If using Ansible, Puppet, or SaltStack, simply run the Playbook on the new server.

Method 3: Containerization

If the application is already containerized (Docker), migration is simplest — just run docker-compose up -d on the new server.

3.2 Data Validation

After migration, verify on the new server:

# Check service status
systemctl status nginx mysql php8.1-fpm

# Check database data
mysql -u root -p -e "SELECT COUNT(*) FROM information_schema.tables;"

# Test website functionality
curl -I http://localhost/

4. DNS Switchover

4.1 Reduce TTL

Lower the DNS TTL to 300 seconds (5 minutes) 48 hours before migration to speed up propagation after switchover:

www.example.com.  300  IN  A  123.456.789.0

4.2 Switch DNS

Update A/AAAA/CNAME records at the domain registrar to point to the new server IP.

4.3 Post-Switchover Monitoring

Monitor continuously for 24-48 hours after switchover:

# Check if DNS resolution has updated
dig example.com +short

# Monitor website response time
curl -o /dev/null -s -w "HTTP %{http_code}, Time: %{time_total}s\n" https://example.com/

# Check SSL certificate
openssl s_client -connect example.com:443 -servername example.com

5. Rollback Plan

Keep the old server running for at least 7 days after migration. If serious issues are found, rollback steps:

1. Point DNS records back to the old server IP
2. Confirm services on the old server are running normally
3. Investigate differences and re-prepare for migration
4. Choose off-peak hours for the next migration attempt

6. Common Cloud Provider Migration Scenarios

Alibaba Cloud → Tencent Cloud

• Note: Internal IP addresses will change — check for hardcoded IPs in configuration files
• Alibaba Cloud RDS users need to export data locally first, then import to Tencent Cloud CDB
• OSS files need to be downloaded via ossutil to local, then uploaded to COS

Domestic Cloud → Overseas VPS

• Note: Cross-border network latency and bandwidth limitations
• Use domestic relay servers to accelerate data transfer
• ICP filing: overseas servers do not require ICP filing

Traditional IDC → Cloud Server

• Physical servers need to be virtualized or environment-packaged first
• Evaluate post-migration architecture design (whether to split services)

Common Pitfalls and Troubleshooting

These are the most frequently hit traps in a migration; checking for them early saves a lot of time:

• Hardcoded IPs in configs: database connections, allowlists, and callback URLs may still reference the old internal IP — grep for it with grep -rn "<old-ip>" /etc /app;
• Timezone and charset drift: database default timezone and utf8mb4 charset must match, or you get garbled text and an 8-hour time offset;
• Missing security group / firewall rules: if ports like 3306/6379 are not opened on the new box, services "look fine" but cannot connect;
• Cache and queue data: Redis sessions and pending jobs do not migrate on their own, so login state and background tasks will be lost;
• SSL certificates and keys not carried over: moving the site without the certificate directory breaks HTTPS right after the switch.

Reference: rsync man page https://man7.org/linux/man-pages/man1/rsync.1.html, mysqldump docs https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html, rclone docs https://rclone.org/docs/

7. Summary

Cross-cloud migration requires careful planning. The key to success lies in thorough preparation and validation. It is recommended to perform migration during off-peak hours and conduct a full dry run before switching. Most migration issues stem from neglecting environmental differences and insufficient testing. Keeping the old environment and complete backups is the most important safety net throughout the migration process.