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:

Assessment Item Check Content
OS Version Ubuntu 22.04 vs 24.04, CentOS 7 vs Rocky Linux 9
Software Stack Version PHP/Node.js/Python/Java version consistency
Database Version MySQL/PostgreSQL version compatibility
System Architecture x86 vs ARM (architecture change may require recompiling applications)
Network Planning VPC CIDR, subnet planning, security group rules
Managed Services Whether using provider's managed services (RDS, Redis, OSS, etc.)

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

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)

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)

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.