How to Migrate a Website to VPS Without Downtime: A Step-by-Step Plan

Migrating to a VPS is intimidating not because of complexity, but because of risk: the fear that your site will go dark for a day. This can be avoided entirely if you do not switch the domain as your first action. The correct order is: bring up a copy alongside the original, confirm it works, and only then direct visitors to it.

Step 0. Preparation One Day Before

Lower the TTL on your domain DNS records to 300 seconds. TTL is the time providers cache the response. If it is currently set to the standard 86400 seconds, the switch will take a full day to propagate; at 300 seconds the world will see the new address within five minutes.

This needs to be done in advance, one day before the migration, so the old value has time to expire everywhere.

Also compile a list of everything that lives on the old hosting besides files and the database: mailboxes on the domain, cron jobs, SSL certificates, subdomains.

Step 1. Prepare the Server

In the NodexGo control panel click Create Server: choose a location (your ping to each one is shown), a plan, a system image, and confirm the order. The server will be ready in about a minute, and the IP address and root password will appear in the panel and be sent to your email.

It makes sense to choose a location close to your site audience, and a plan with a small memory buffer: upgrading to a higher plan can be done later with a single Upgrade Resources button, and the disk and IP are preserved.

Perform basic configuration: updates, a separate user, SSH keys, a firewall. Install the same software stack as on the old hosting, and where possible the same versions, especially PHP and MySQL.

A PHP version mismatch between the old and new server is the most common cause of a blank white screen on the new server. To check the current version on the old hosting:

php -v

Step 2. Transfer Files

If the old hosting has SSH, the most reliable method is rsync: it can resume interrupted transfers and handles connection drops gracefully.

rsync -avz --progress -e ssh user@old-host:/var/www/site/ /var/www/site/

If there is no SSH, download via FTP, but make sure hidden files are included, as .htaccess and .env are the most commonly lost.

Step 3. Transfer the Database

On the old server, take a dump. The --single-transaction flag makes it consistent without locking tables, so the site keeps running during the export.

mysqldump -u username -p --single-transaction --routines database_name > dump.sql

On the new server, create the database and import the dump:

mysql -u username -p database_name < dump.sql

After that, update the connection credentials in the site config: wp-config.php for WordPress, .env for Laravel, settings.py for Django.

Step 4. Verify Without Touching the Domain

This is the key step that is most often skipped. Open the site on the new server via the hosts file on your own computer, so you see the new copy while everyone else continues to see the old one.

On Linux and macOS this is /etc/hosts, on Windows it is C:\Windows\System32\drivers\etc\hosts. Add a line with the new server IP:

203.0.113.10 example.com www.example.com

Now walk through the site as a visitor would: the homepage, catalog, contact form, admin login, checkout. Check file uploads and email sending. Everything you find now can be fixed calmly, and visitors will never know.

Step 5. Sync Changes and Switch DNS

If time has passed between copying and verification, run rsync and the database export again, otherwise orders and comments that appeared in the meantime will be lost. For the duration of the final sync it makes sense to enable maintenance mode on the old site for a few minutes.

Then update the domain A record to the new IP. With a TTL of 300 seconds the switch takes minutes. Do not shut down the old server for another couple of days: some providers hold their cache longer than promised.

Step 6. After the Migration

Issue an SSL certificate. This must be done after the DNS switch, because domain validation uses the domain's current address:

certbot --nginx -d example.com -d www.example.com

Transfer cron jobs, verify email delivery (after migration it often ends up in spam, so configure SPF and DKIM), restore TTL to its normal value, and set up backups. On the new server you are responsible for backups, not the hosting provider.

If Something Goes Wrong

While the domain has not been switched, there is nothing to roll back since the old site is still running. After the switch the fastest rollback is to restore the previous A record, which will propagate in the same five minutes.

If the server itself breaks and SSH is not responding, the server card in the panel has a VNC web console that works independently of the network and SSH. Nearby are Reboot and Reinstall OS buttons for when starting fresh is easier.

Checklist

TTL lowered in advance · files transferred including hidden ones · database exported with --single-transaction · PHP and MySQL versions match · site verified via hosts before switching · final sync completed · DNS switched · SSL issued · cron transferred · email verified · backups configured · old hosting shut down after a few days.

If this is your first migration, take a minimal-configuration server and practice on a test domain. One hour of hands-on practice removes almost all the fear.