How to migrate a website to a VPS: A guide with zero downtime

VPS migration rsync MySQL DNS WordPress

Migrating a website to a new VPS server is one of the riskiest operational tasks, if done incorrectly, it results in downtime, data loss or an out-of-sync database. If done correctly, users will not notice the server has been moved at all. This guide walks you through the complete process step by step.

Phase 1: Preparation before migration

Rushed migration is poor migration. Prepare everything before touching production:

Checklist before commissioning

Critical step: Lower the DNS TTL at least 24 hours in advance. If you do this immediately before migration, some users will still be directed to the old server with a different database for several hours, and those databases will diverge.

Phase 2: File transfer using rsync

rsync is the standard tool for efficient file transfer. It copies only changed files, supports delta transfers and preserves permissions. For website migration it is always better than SCP or FTP.

Basic command for transferring web files from the old server to the new one:

rsync -avz --progress \
-e "ssh -p 22" \
/var/www/html/vas-web/
user@NOVA_IP:/var/www/html/your-web/

Switch -a (archive) preserves permissions, symbolic links and file timestamps. Switch -z compresses data over the network. For large websites (hundreds of MB), we recommend adding --bwlimit=10000 to limit transfer speed: prevents overloading of the production server.

Incremental rsync just before switching

Run rsync for the first time hours or days before migration to transfer the bulk of data. Run rsync again immediately before switching DNS. The second rsync is significantly faster (copying only files changed since the first run) and ensures the new server has the latest file state.

Phase 3: Database export and import

The database is the most critical part of migration. Database loss or inconsistency is the most common cause of post-migration problems.

Export MySQL/MariaDB using mysqldump

mysqldump -u root -p \
--single-transaction \
--routines \
--triggers
--hex-blob
nazev_databaze > backup_$(date +%Y%m%d_%H%M).sql

Switch --single-transaction is key for InnoDB tables. It performs an export without locking the tables, so the website can continue to function during the export. For MyISAM tables this does not work and you must use --lock-tables.

Import on the new server

# Creating a database and user
mysql -u root -p -e "CREATE DATABASE nazev_databaze CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
mysql -u root -p -e "CREATE USER 'db_user'@'localhost' IDENTIFIED BY 'silne_heslo';
mysql -u root -p -e "GRANT ALL ON nazev_databaze.* TO 'db_user'@'localhost';

# Data import
mysql -u root -p nazev_databaze < backup_20260118_0200.sql

Phase 4: Configuration of the new server

Files and databases have been moved. You must now configure the new server identically to the old one.

PHP version and extensions

Check the PHP version on the old server (php --version) and install the same one on the new server. The PHP version difference is the most common cause of "works on the old one, doesn't work on the new one". Also check the PHP extensions (php -m): in particular mbstring, curl, gd, intl a zip.

WordPress specifics

Verification before switching DNS

Test the website on the new server via exascale.cz /etc/hosts - temporarily add a record:

NOVA_IP vas-web.cz www.vas-web.cz

This will allow your computer to access the new server even if DNS still points to the old one. Test the entire website, login, forms, payment gateway, admin panel. If everything works, you are ready to switch DNS.

Phase 5: Blue-Green strategy for critical websites

For websites with high traffic or e-shops, we recommend blue-green deployment. The principle is simple: both servers (old = blue, new = green) run in parallel. Switching over is just a DNS change, if anything fails, simply revert the DNS.

Key detail: when switching the DNS, you must stop writes to the old database (switch the website to maintenance mode) and perform a final export-import. Without this, the databases will diverge.

Blue-green switchover procedure: 1) Enable maintenance mode on the old server. 2) Run the final mysqldump. 3) Import into the new database. 4) Run the final rsync. 5) Verify the new server via /etc/hosts. 6) Change the DNS A records. 7) Wait for TTL propagation. 8) Verify via public DNS. 9) Disable maintenance mode.

Phase 6: Rollback plan

Always have a rollback plan ready: a procedure to revert to the original server if the migration fails. Keep the old server running for at least 48 hours after the migration. If you find an issue on the new server, simply revert the DNS to the old IP address, this gives you time to fix the problem calmly.

Only after a successful 48-hour verification on the new server is the old VPS cancelled.

Exascale.cz: Support with migration

Website migration is technically demanding and an incorrectly executed migration can result in downtime lasting hours. The Exascale.cz team provides assistance with migration: from technical consultation to active help with data transfer. If you are unsure about any step, contact us beforehand, not when the outage occurs.

VPS with migration assistance

Exascale.cz will assist with migrating your website to a new VPS, technical support in Czech, NVMe storage and KVM virtualisation in a Czech data centre.

Select VPS →