DMIT Migration Guide: Zero-Downtime Service Migration

Preparing for migration to DMIT

Migrating an existing service to a DMIT cloud server requires planning. Rushing can lead to data loss or downtime. This article provides a complete migration flow: assessment, execution, cutover and verification.

Step 1: Assess your current environment

Inventory your current server's resource usage before migrating:

# CPU usage
top -bn1 | grep "Cpu(s)"

# Memory
free -h

# Disk
df -h
du -sh /var/www/ /opt/ /home/

# Network traffic
vnstat -m   # if installed

Choose a suitable DMIT plan based on the assessment. See How to Choose and Plan Value Analysis.

Step 2: Prepare the target server

After purchasing a DMIT plan, follow the First Deploy Checklist for base configuration:

• System updates and timezone
• SSH hardening (key auth/disable password/firewall)
• Install required runtime (Nginx/database/language runtimes)
• Create a snapshot as a rollback point

Step 3: Migrate data

Website files

# rsync incremental sync
rsync -avz --progress /var/www/ deploy@new-server:/var/www/

# For large data, pack on the old server first
tar czf /tmp/www-migrate.tar.gz /var/www/
scp /tmp/www-migrate.tar.gz deploy@new-server:/tmp/
ssh deploy@new-server "tar xzf /tmp/www-migrate.tar.gz -C /"

Database

# MySQL/MariaDB export
mysqldump -u root -p --all-databases --single-transaction > /tmp/dump.sql
scp /tmp/dump.sql deploy@new-server:/tmp/
# Import on new server
mysql -u root -p < /tmp/dump.sql

# PostgreSQL export
pg_dump -U postgres -F c -f /tmp/db.dump dbname
# Import on new server
pg_restore -U postgres -d dbname /tmp/db.dump

Config files

# Nginx config
scp /etc/nginx/sites-available/* deploy@new-server:/etc/nginx/sites-available/
# Check paths, SSL certs and upstreams

# Systemd services
scp /etc/systemd/system/*.service deploy@new-server:/etc/systemd/system/

SSL certificates

# Migrate Let's Encrypt
scp -r /etc/letsencrypt/ deploy@new-server:/etc/letsencrypt/
# Or re-issue on the new server
certbot --nginx -d example.com

Step 4: Verify the new server

Before switching DNS, verify the service works on the new server:

# Add to local hosts file
# Windows: C:\Windows\System32\drivers\etc\hosts
# Linux/Mac: /etc/hosts
# Add: 123.45.67.89 example.com

# Test
curl -I https://example.com
curl -I https://example.com/api/health

Verification checklist:

• Homepage loads correctly
• API endpoints return correct responses
• Database read/write works
• HTTPS certificate is valid
• Static assets (images/CSS/JS) load
• Admin panel accessible

Step 5: Cut over traffic

Option A: DNS cutover (recommended)

Point the DNS A record to the new server IP. DNS propagation takes time:

• Lower DNS TTL beforehand (e.g. 300s) to speed up propagation
• Switch during low-traffic hours
• Monitor old server logs after switch to confirm traffic has moved

Option B: Reverse proxy cutover (zero downtime)

Configure Nginx on the old server to proxy to the new server, then switch gradually:

# Old server Nginx
location / {
    proxy_pass http://new-server-ip:80;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}

After confirming, switch DNS to the new server and remove the reverse proxy from the old server.

Step 6: Post-migration verification

Common migration issues

Can't connect to database?

• Check database bind-address (allows remote connections?)
• Check firewall allows the database port
• Check database user permissions include the new server IP

File permissions wrong?

# Fix web directory permissions
chown -R www-data:www-data /var/www/
find /var/www/ -type d -exec chmod 755 {} \;
find /var/www/ -type f -exec chmod 644 {} \;

502 Bad Gateway?

• Check backend service: systemctl status your-app
• Check Nginx upstream port config
• Check SELinux/AppArmor blocking

Migration timeline

After migration, create a snapshot and configure automated backup. See Monitoring and Backup. SSH hardening in SSH Hardening.

Checked 2026-08-18. Migration details depend on your specific service architecture.