How to Migrate Your Website to a New Ubuntu VPS (Zero-Downtime Guide)

Pre-Migration Planning: Inventory Everything

Migrations fail not because the transfer itself is hard, but because something gets forgotten. Before you touch a single file, create a complete inventory of your current server.

File and Application Inventory

# List all websites and applications
ls -la /var/www/

# Find all document roots in Nginx
grep -r "root " /etc/nginx/sites-enabled/

# Or in Apache
grep -r "DocumentRoot" /etc/apache2/sites-enabled/

# Check for cron jobs (ALL users)
for user in $(cut -d: -f1 /etc/passwd); do
  crontab -l -u "$user" 2>/dev/null | grep -v '^#' | grep -v '^$' && echo "--- User: $user ---"
done

# List running services
systemctl list-units --type=service --state=running

# Check disk usage per directory
du -h --max-depth=2 /var/www/ | sort -rh | head -20

Database Inventory

# List all databases
mysql -e "SHOW DATABASES;"

# List database sizes
mysql -e "SELECT table_schema AS 'Database', 
  ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Size (MB)' 
  FROM information_schema.tables GROUP BY table_schema ORDER BY 
  SUM(data_length + index_length) DESC;"

# List database users
mysql -e "SELECT user, host FROM mysql.user;"

DNS and SSL Inventory

# Record current DNS settings (do this for EVERY domain)
dig yourdomain.com A +short
dig yourdomain.com MX +short
dig yourdomain.com TXT +short
dig yourdomain.com CNAME +short
dig www.yourdomain.com A +short

# Check SSL certificate details
openssl s_client -connect yourdomain.com:443 -servername yourdomain.com 2>/dev/null | \
  openssl x509 -noout -dates -issuer

# List all Let's Encrypt certificates
certbot certificates

Save this entire inventory in a document. You will reference it throughout the migration.

Step 1: Lower DNS TTL (48 Hours Before Migration)

This step is critical and must happen well before the actual migration. DNS records have a TTL (Time To Live) that tells resolvers how long to cache the record. If your TTL is 86400 (24 hours), changing the DNS record means some users will still reach the old server for up to 24 hours.

# Log into your DNS provider and set TTL to 300 seconds (5 minutes)
# for these records:
# - A record for yourdomain.com
# - A record for www.yourdomain.com
# - A record for any other subdomains (mail, api, etc.)
#
# Wait at least 48 hours for the old TTL to expire everywhere
# before proceeding with the migration

# Verify the new TTL is propagated
dig yourdomain.com +noall +answer
# Look for the TTL value (second column) - should show 300

Do not skip this step. A 48-hour wait with low TTL means your DNS cutover will propagate in minutes instead of hours or days.

Step 2: Choose Your Destination Tier

Your migration is an opportunity to right-size your hosting. Where you are coming from determines the best destination:

From Shared Hosting → Cloud VPS

If you are leaving shared hosting (GoDaddy, Bluehost, HostGator, etc.) because you have outgrown the resource limits, a MassiveGRID Cloud VPS starting at $1.99/mo is the natural next step. You get root access, your choice of OS, and resources that scale independently. The performance improvement over shared hosting will be immediate and dramatic.

From Another VPS Provider → Cloud VDS

If you are leaving DigitalOcean, Vultr, Hetzner, or Linode because of noisy neighbors, inconsistent performance, or lack of high availability, a MassiveGRID Cloud VDS from $8.30/mo gives you dedicated CPU and RAM on Proxmox HA clusters with Ceph NVMe storage. No more shared resource lottery.

From Self-Managing → Managed Dedicated

If you are migrating because you are tired of being the sysadmin, MassiveGRID Managed Cloud Dedicated Servers handle everything. You hand over the operational burden and focus on your business. The migration itself can be assisted by MassiveGRID's support team.

Step 3: Set Up the Destination Server

Deploy your new server and configure the base environment before transferring any data:

# After deploying your MassiveGRID VPS/VDS, connect via SSH
ssh root@new-server-ip

# Update the system
apt update && apt upgrade -y

# Install your web stack (example: Nginx + PHP + MySQL)
apt install -y nginx mysql-server php8.3-fpm php8.3-mysql \
  php8.3-curl php8.3-gd php8.3-mbstring php8.3-xml php8.3-zip

# Configure the firewall
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 'Nginx Full'
ufw enable

# Set the timezone
timedatectl set-timezone UTC

# Configure fail2ban
apt install -y fail2ban
systemctl enable fail2ban

Match the software versions on your new server to the old one as closely as possible. PHP version mismatches are the most common cause of post-migration issues.

Step 4: Transfer Files with rsync

rsync is the best tool for migration because it is incremental—it only transfers changes after the initial sync. This means you can do a first sync while the old server is still live, then a quick final sync during cutover.

Initial Sync (While Old Server Is Still Live)

# From the NEW server, pull files from the old server
# Dry run first to see what will be transferred
rsync -avz --dry-run --progress \
  --exclude '.cache' \
  --exclude 'tmp/' \
  --exclude '*.log' \
  --exclude 'node_modules/' \
  --exclude '.git/' \
  root@old-server-ip:/var/www/ /var/www/

# If the dry run looks correct, run the actual transfer
rsync -avz --progress \
  --exclude '.cache' \
  --exclude 'tmp/' \
  --exclude '*.log' \
  --exclude 'node_modules/' \
  --exclude '.git/' \
  root@old-server-ip:/var/www/ /var/www/

# Also transfer configuration files
rsync -avz root@old-server-ip:/etc/nginx/sites-available/ /etc/nginx/sites-available/
rsync -avz root@old-server-ip:/etc/nginx/sites-enabled/ /etc/nginx/sites-enabled/
rsync -avz root@old-server-ip:/etc/php/ /etc/php/

Important: The trailing slash on source paths matters in rsync. /var/www/ copies the contents of the directory. /var/www (no slash) copies the directory itself.

Transfer Cron Jobs

# Export cron jobs from old server
ssh root@old-server-ip 'crontab -l' > /tmp/old-crontab.txt

# Review and install on new server (check paths first!)
cat /tmp/old-crontab.txt
# Edit paths if needed, then:
crontab /tmp/old-crontab.txt

Step 5: Database Migration

Database migration requires care to avoid data loss. For MySQL/MariaDB:

Export from Old Server

# Export all databases (on old server)
mysqldump --all-databases --routines --triggers --events \
  --single-transaction --quick --lock-tables=false \
  > /tmp/all-databases.sql

# Or export specific databases
mysqldump --single-transaction --quick --lock-tables=false \
  --routines --triggers \
  database_name > /tmp/database_name.sql

# Check the dump file size
ls -lh /tmp/*.sql

# Transfer to new server
rsync -avz --progress /tmp/all-databases.sql root@new-server-ip:/tmp/

Import on New Server

# Import the database
mysql < /tmp/all-databases.sql

# Or for a specific database
mysql database_name < /tmp/database_name.sql

# Recreate database users with their passwords
# (check the inventory you made earlier)
mysql -e "CREATE USER 'appuser'@'localhost' IDENTIFIED BY 'secure-password';"
mysql -e "GRANT ALL PRIVILEGES ON database_name.* TO 'appuser'@'localhost';"
mysql -e "FLUSH PRIVILEGES;"

# Verify tables were imported correctly
mysql -e "USE database_name; SHOW TABLES;" | wc -l

For Large Databases

If your database is larger than 1 GB, use compression and pipe the transfer directly:

# Compressed direct transfer (no intermediate file)
ssh root@old-server-ip \
  "mysqldump --single-transaction --quick database_name | gzip" | \
  gunzip | mysql database_name

Step 6: Update Application Configuration

After transferring files and databases, update configuration files that reference the old server:

# Common changes needed:
# - Database host (if changed from remote to localhost)
# - File paths (if directory structure differs)
# - Domain URLs (in WordPress wp-config.php, .env files, etc.)

# WordPress example
# wp-config.php - usually just verify these are correct:
# define('DB_HOST', 'localhost');
# define('DB_NAME', 'wordpress');
# define('DB_USER', 'wpuser');
# define('DB_PASSWORD', 'password');

# Laravel/PHP example
# .env file:
# DB_HOST=127.0.0.1
# DB_DATABASE=myapp
# DB_USERNAME=appuser
# DB_PASSWORD=password
# APP_URL=https://yourdomain.com

# Fix file permissions
chown -R www-data:www-data /var/www/yourdomain.com/
find /var/www/yourdomain.com/ -type d -exec chmod 755 {} \;
find /var/www/yourdomain.com/ -type f -exec chmod 644 {} \;

Step 7: SSL Certificate Setup

Set up SSL on the new server before the DNS cutover so HTTPS works immediately:

# Install Certbot
apt install -y certbot python3-certbot-nginx

# Option 1: Get a certificate using DNS validation (works before DNS cutover)
certbot certonly --manual --preferred-challenges dns \
  -d yourdomain.com -d www.yourdomain.com

# Option 2: If you want to use HTTP validation after DNS cutover
# (do this AFTER changing DNS, or use the hosts file trick below)
certbot --nginx -d yourdomain.com -d www.yourdomain.com

# Set up auto-renewal
systemctl enable certbot.timer
certbot renew --dry-run

Step 8: Test Before DNS Cutover

This is the most important step. Verify everything works on the new server before sending real traffic to it.

The Hosts File Trick

# On your LOCAL computer (not the server), edit your hosts file
# to point your domain at the new server IP

# macOS/Linux: /etc/hosts
# Windows: C:\Windows\System32\drivers\etc\hosts
# Add these lines:
# NEW_SERVER_IP yourdomain.com
# NEW_SERVER_IP www.yourdomain.com

# Now open yourdomain.com in your browser
# You are viewing the new server while everyone else still sees the old one

Testing with curl

# Test HTTP response from the new server specifically
curl -H "Host: yourdomain.com" http://NEW_SERVER_IP/ -I

# Test HTTPS with the --resolve flag (bypasses DNS)
curl --resolve yourdomain.com:443:NEW_SERVER_IP https://yourdomain.com/ -I

# Check for correct content (look for your site title or specific text)
curl --resolve yourdomain.com:443:NEW_SERVER_IP https://yourdomain.com/ 2>/dev/null | \
  grep -i "