Migrating to a Cheaper VPS: The Real Commands, Configs, and Gotchas

Moving to a cheaper VPS is one of the most effective ways to cut your hosting bill, but a botched migration can cost you hours of downtime and data loss. This guide covers the actual commands, configuration files you need to move, and the common pitfalls that cause migrations to fail.

Before You Start: Audit What You Actually Need

The biggest mistake people make is migrating everything they have, including unused files, old kernels, and cached packages. Before you move, audit your current server:

# Check disk usage by directory
du -sh /* 2>/dev/null | sort -rh | head -20
# List installed packages
apt list --installed | wc -l
# Check running services
systemctl list-units --type=service --state=running
# Find large files
find / -type f -size +100M 2>/dev/null

This tells you what you actually need on the new server. Most VPS migrations can be reduced to a few GB of application data, config files, and databases.

Step 1: Set Up the New VPS

Order your new, cheaper VPS from any budget VPS provider. Install the same OS version as your old server to avoid compatibility issues. Apply the same initial security hardening: disable root login, set up a firewall, and install fail2ban.

Step 2: Migrate Data with rsync

rsync is the fastest and most reliable tool for transferring files. It only copies differences, so the final sync is fast even if you have been testing changes:

# From the old server
rsync -avz --progress /var/www/ user@new-server-ip:/var/www/
rsync -avz --progress /etc/nginx/ user@new-server-ip:/etc/nginx/
rsync -avz --progress /etc/letsencrypt/ user@new-server-ip:/etc/letsencrypt/

Run rsync with the --delete flag on the final sync to remove any files you deleted from the old server. This keeps the two servers in sync until you are ready to switch.

Step 3: Migrate Databases

For MySQL or MariaDB, use mysqldump to create a portable SQL file, then import it on the new server:

# On old server
mysqldump --all-databases --single-transaction --quick > db_backup.sql
# Transfer to new server
rsync -avz db_backup.sql user@new-server-ip:/tmp/
# On new server
mysql < /tmp/db_backup.sql

For SQLite databases, just copy the .db file directly with rsync — make sure the application is stopped first.

Step 4: Switch DNS with a Low TTL

Set your DNS TTL to 300 seconds (5 minutes) at least 24 hours before the migration. This ensures that when you change the A record, the update propagates within minutes instead of hours. After the migration, you can increase the TTL back to 3600 or higher.

Step 5: Test Everything Before Cutting Over

Edit your local hosts file to point your domain to the new server IP before changing DNS. This lets you test the new server in isolation:

# On your local machine /etc/hosts
new-server-ip yourdomain.com www.yourdomain.com

Test all your sites, APIs, and services. Check that SSL certificates work, that databases are intact, and that cron jobs are running. Only then should you update the DNS records.

Common Gotchas That Break Migrations

• SSL certificate paths — Certbot certificates reference the old server IP. Run certbot renew on the new server after pointing DNS.
• Hardcoded IPs — Any configuration file with the old server IP in it will break. Search with grep -r "old-ip" /etc/
• Cron jobs with absolute paths — If the new server has a different user setup, update cron job paths.
• SMTP and email reputation — If you send email from the server, the new IP may have a cold reputation. Warm it up gradually.
• Firewall rules — Do not forget to copy your ufw or iptables rules to the new server.

How Much Can You Save?

Migrating from a $15/month VPS to a $7/month plan with similar specs saves $96 per year. If you switch from a $30/month managed plan to a $10/month unmanaged VPS, the savings jump to $240 per year. The one-time migration effort takes a few hours and pays for itself every month after. Compare your options at affordablevpsserver.com to find a cheaper plan that still meets your needs.

Bottom Line

A VPS migration is a straightforward process when you follow the right steps: audit what you need, use rsync, dump databases, lower TTL, test locally, then switch. The biggest risk is not the migration itself — it is rushing through the testing phase. Take your time, verify everything, and you will be on a cheaper server with zero downtime.