How to Migrate From One VPS Provider to Another Safely

Pre-Migration Planning: The Blueprint for a Safe VPS Transfer

Migrating a virtual private server from one provider to another is not a task you improvise. A VPS runs multiple interdependent services—a web server (Apache, Nginx, or LiteSpeed), a database engine (MySQL, MariaDB, or PostgreSQL), an email stack (Postfix, Dovecot, or Exim), DNS caching, PHP processing, firewall rules, and often third-party integrations like monitoring agents and backup daemons. Moving this stack without a written migration plan is the leading cause of extended downtime, data loss, and configuration drift. A methodical blueprint turns what could be a multi-day outage into a controlled, low-downtime transition that your visitors barely notice.

At Hosting Captain, we have documented successful VPS-to-VPS migrations across over 20 hosting providers, encompassing both managed and unmanaged environments. The common denominator among all smooth migrations is preparation: auditing the source server, pre-provisioning the destination server, testing the transfer in a staging capacity, and only then cutting over traffic. This guide walks through each stage with sufficient detail that a systems administrator can execute it directly, while a less technical site owner can use it as a checklist when engaging a managed migration service.

Before you begin, identify whether your current VPS is managed (the provider handles operating system updates, security patches, and often application-layer support) or unmanaged (you have root access and full responsibility). Migrating from managed to unmanaged adds complexity because you must replicate the provider's proprietary tooling. Conversely, moving between two managed VPS providers often allows the new provider's support team to handle the migration for you—sometimes at no additional cost. If that option exists, take it. The rest of this guide covers the manual migration path for administrators who need full control over the process.

Audit Your Source VPS: What Needs to Move

Log into your current VPS via SSH and inventory everything that must be replicated on the destination server. The following checklist prevents the most common migration oversights:

Website Files: Document the absolute paths of all website document roots. WordPress installations typically reside under /var/www/html/ or /home/username/public_html/. Use find / -name "wp-config.php" 2>/dev/null or find / -name "public_html" -type d 2>/dev/null to locate every site. Note the filesystem permissions—PHP-FPM pools often require specific user:group ownership that must be recreated exactly on the destination server.

Databases: Use mysql -u root -p -e "SHOW DATABASES;" to list all databases. For each database, record its name, character set, and collation using SELECT default_character_set_name, default_collation_name FROM information_schema.schemata WHERE schema_name = 'yourdb';. Note any non-standard storage engines (MEMORY, ARCHIVE) and scheduled events that must be recreated.

Email Configuration: If your VPS handles email (many do, even for transactional messages from contact forms), document the mail exchanger configuration, forwarders, spam filters, and mailbox passwords. Data stored under /var/vmail/ or /home/username/mail/ must be transferred exactly. DKIM keys and SPF records must be regenerated or copied to the new server.

Cron Jobs: Run crontab -l for each user account and cat /etc/crontab plus ls /etc/cron.* to capture system-level scheduled tasks. Cron jobs often run backups, cache clearing, log rotation, and application-level maintenance—missing even one can cause silent failures that surface days or weeks after migration.

SSL Certificates: If you use Let's Encrypt via Certbot, the certificates and renewal configurations under /etc/letsencrypt/ should be backed up (though it is often easier to reissue on the new server). Paid SSL certificates must be exported with their private keys and re-imported. Any custom DH parameters or OCSP stapling configurations must be documented.

Firewall and Security Rules: Export your iptables or firewalld rules with iptables-save > iptables.rules or firewall-cmd --list-all. If you use fail2ban, backup /etc/fail2ban/jail.local and any custom filter files. These rules protect against brute-force attacks and must be operational the moment the new server goes live.

Creating a Complete Backup of Your Source VPS

A partial backup is worse than no backup at all because it creates a false sense of security. Use the following tiered backup strategy:

Database Dump (All Databases): Execute a consistent logical backup using mysqldump with the --single-transaction flag (for InnoDB tables) to avoid locking during the dump. The command mysqldump -u root -p --all-databases --single-transaction --routines --triggers --events > all_databases.sql produces a single SQL file containing every database, stored procedure, trigger, and event. For large databases—over 1 GB—compress during the dump with mysqldump ... | gzip > all_databases.sql.gz to reduce transfer time. Verify the dump by checking the file size and scanning the last few lines for "Dump completed" messages.

Full Filesystem Backup: Use tar to create an archive of critical directories, excluding transient content that does not need migration: tar -czpf vps_backup.tar.gz /etc /var/www /home /var/vmail /var/spool/cron /usr/local --exclude=/var/www/html/wp-content/cache --exclude=/var/log. Adjust paths based on your audit. The -p flag preserves permissions, ownership, and ACLs. For very large filesystems, consider rsync as an alternative backup mechanism that can be resumed if interrupted.

Transfer to Destination: Use scp or rsync over SSH to move the backup files to the new VPS. If the database dump exceeds a few gigabytes, rsync -avz --progress all_databases.sql.gz user@NEW_IP:/home/user/ is preferable because it supports resumption. Do not delete the source backup until the new server is fully operational and verified.

Snapshot Verification: If your current provider offers volume snapshots, take one before you begin the migration. Snapshots are point-in-time captures of the entire virtual disk and serve as your ultimate rollback mechanism. They take seconds to create and can be restored to a new VPS if the migration encounters a fatal issue.

Provisioning and Configuring the Destination VPS

The destination VPS should mirror the source server's stack as closely as possible to minimize compatibility issues. Choose the same operating system distribution and version whenever feasible—moving from Ubuntu 22.04 to AlmaLinux 9, for example, introduces unnecessary friction with package names, configuration file locations, and PHP module paths.

Install the Core Stack: Based on your source server, install the web server, database engine, PHP (with identical version and extensions), and any other services identified during the audit. Run php -m on the source server and compare the output against php -m on the destination to ensure every required PHP extension is present. A missing php-imagick, php-mbstring, or php-zip extension is a frequent cause of post-migration errors.

Replicate User Accounts and Permissions: Create the same system users with the same UIDs and GIDs as the source server. Use id username on the source to retrieve the numeric IDs, then use groupadd -g GID groupname and useradd -u UID -g GID username on the destination. Mismatched UIDs cause "permission denied" errors when the backup archive is extracted.

Restore Website Files: Extract the backup archive to the same absolute paths on the destination: tar -xzpf vps_backup.tar.gz -C /. If you changed the operating system, do not extract /etc files—they contain OS-specific configurations that may break the new server. Extract only the content directories.

Restore Databases: Create the databases on the destination using identical names, character sets, and collations. Then import the SQL dump: mysql -u root -p < all_databases.sql. For compressed dumps, use gunzip -c all_databases.sql.gz | mysql -u root -p. After import, verify row counts on critical tables to confirm the import was complete.

Configure Firewall, SSL, and Monitoring: Apply the saved firewall rules, install and configure Certbot (or reissue SSL certificates), and set up any monitoring agents (Datadog, New Relic, or the provider's built-in monitoring). Test the web server configuration with nginx -t or apachectl configtest before starting services.

Testing the Destination VPS Before DNS Cutover

Never change DNS records until you have verified that the destination server is serving content correctly. The curl command with the --resolve flag lets you test a specific domain against the new server's IP address without affecting live traffic: curl -I --resolve example.com:443:NEW_IP https://example.com. This sends the request to the new server while the DNS still points to the old server.

Alternatively, add a temporary entry to your local /etc/hosts file (or C:\Windows\System32\drivers\etc\hosts on Windows): NEW_IP example.com www.example.com. Browse the site, test forms, log into the CMS, and verify that dynamic functionality—search, cart operations, user login—works correctly. Check PHP error logs (/var/log/php*-fpm.log or the web server error log) for warnings that indicate missing modules or configuration issues.

For e-commerce or membership sites, perform a complete transaction flow: add a product to cart, proceed to checkout, confirm that the order appears in the database on the new server. For any site using email, send a test message through the contact form and verify delivery. These functional tests catch database connection errors, PHP module gaps, and SMTP misconfigurations that a simple HTTP 200 check would miss.

DNS Update, Propagation, and Minimizing Downtime

Once the destination server passes all tests, you are ready to cut over traffic. The most effective strategy for minimizing downtime is to lower the TTL (Time to Live) on your DNS records at least 24 hours before the migration. A standard TTL of 3600 seconds (1 hour) or 300 seconds (5 minutes) means that when you update the A record to the new IP address, cached entries expire quickly, and most visitors reach the new server within minutes.

Step 1: Lower the TTL at your DNS provider to 300 seconds. Wait for the previous TTL duration to elapse to ensure all recursive resolvers have picked up the new TTL.

Step 2: Stop write-heavy services on the source server. Disable cron jobs that modify the database, put the CMS into maintenance mode if it supports it, or place a read-only lock on the database: FLUSH TABLES WITH READ LOCK;. Perform a final, quick database dump to capture any transactions that occurred since the initial backup.

Step 3: Update the A record (and AAAA record if using IPv6) to point to the new VPS IP address. If your mail is hosted on the same server, update the MX record as well. Use a DNS checker like dig to verify the change has propagated: dig +short example.com @8.8.8.8.

Step 4: Import the final incremental database dump on the destination. Unlock the source database, disable maintenance mode, and confirm the site is loading from the new server across multiple geographic locations using a tool like Geopeeker or a simple curl from an external VPS.

Step 5: Keep the source VPS running for 48–72 hours post-migration. Some recursive resolvers ignore low TTLs, and a small percentage of visitors may continue to hit the old IP. Monitor logs on both servers. Only decommission the source VPS after traffic to the old IP drops to zero for at least 24 consecutive hours.

Post-Migration Verification Checklist

After DNS has propagated globally, systematically verify every component of your stack. At Hosting Captain, we use the following checklist on every migration review:

• SSL certificates: Confirm HTTPS loads without browser warnings. Check the certificate issuer and expiration date. Verify OCSP stapling and HSTS headers if previously configured.
• Database connectivity: Log into phpMyAdmin or Adminer on the new server and confirm all databases are accessible. Run a sample query on each to verify table integrity.
• Email delivery: Send test emails to addresses at different providers (Gmail, Outlook, Yahoo). Check SPF, DKIM, and DMARC alignment. Verify that the new server's IP is not on any email blocklists.
• Cron jobs: Trigger each cron manually and confirm expected outcomes. Check that backup jobs are writing to the correct destination path on the new server.
• Third-party integrations: Test API connections, webhooks, payment gateway callbacks, and CDN origin pulls against the new server IP.
• Performance benchmarking: Run ab (ApacheBench) or wrk against the new server and compare response times and throughput with the previous server. Confirm CPU and memory usage under load are within expected ranges.
• Logs and monitoring: Verify that error logs are populating and that monitoring dashboards show the new server as healthy. Set up alert thresholds if not inherited from the source server.

Common Migration Pitfalls and How to Avoid Them

Mismatched PHP Versions: Moving from PHP 7.4 to 8.2 without testing can break plugins, themes, and custom code. Always match the PHP major version on the destination, test the site, and only then plan a separate PHP upgrade after the migration is confirmed stable.

Forgotten Domain Pointers and Aliases: If your VPS hosts parked domains, addon domains, or subdomains, every one of them needs its DNS updated. Audit /etc/nginx/sites-enabled/ or /etc/httpd/conf.d/ to find every ServerName and ServerAlias directive.

Hardcoded IP Addresses in Application Code: Some legacy applications and custom scripts reference the old server's IP directly rather than using a hostname. Search your codebase with grep -r "OLD_IP" /var/www/ and update any hardcoded references before going live on the new server.

MySQL Socket vs. TCP Configuration: On the old server, applications might connect to MySQL via a Unix socket (localhost), while the new server's PHP configuration might expect a TCP connection (127.0.0.1). Check wp-config.php and application configuration files to ensure the database host setting matches the new server's MySQL configuration.

Frequently Asked Questions