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
- Record of the current state - complete backup of all files and databases from the existing server. This serves as your rollback point in case anything fails.
- Access to a new VPS SSH login verified, sudo rights configured
- Access to DNS management - login credentials for the domain registrar or DNS provider. You will need to change the A records.
- Reducing DNS TTL - At least 24 hours before migration, reduce the TTL of your DNS records to 300 seconds (5 minutes). This shortens the propagation time when redirecting to the new server.
- Maintenance window - schedule migration for off-peak hours (low visitor traffic). For database applications, the ideal time is between midnight and 4:00.
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:
-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
--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
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
- Update
wp-config.phpwith new database credentials - Check
siteurlahomein the database (tablewp_options) - values must match the actual domain, not the IP address - Check
.htaccess- rules for WordPress permalinks must be present - If the website runs on HTTPS, configure the SSL certificate on the new server (Let's Encrypt). before by redirecting DNS
Verification before switching DNS
Test the website on the new server via exascale.cz /etc/hosts - temporarily add a record:
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.
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 →