Server Migration: VPS to VPS Walkthrough

Moving a WordPress site from one VPS to another — whether you’re switching hosts, upgrading plans, or consolidating servers — is one of those tasks that’s simple in theory and full of small landmines in practice. Get the sequence right and visitors never notice. Get it wrong and you’re staring at a broken database connection during a DNS propagation window you can’t rush.

When You Actually Need a Full VPS-to-VPS Migration

This walkthrough is for a genuine server move: new provider, new IP, new stack setup — not a simple plan upgrade within the same host where support can usually resize in place. If you’re moving providers (say, from a budget VPS to something like a managed LiteSpeed stack), you’re rebuilding the environment, not just the files.

Pre-Migration Checklist

• Inventory everything running on the old server — not just WordPress. Cron jobs, mail routing, custom scripts, SSL certs, firewall rules.
• Lower your DNS TTL 24-48 hours in advance (down to around 300 seconds) so the eventual cutover propagates fast instead of leaving stragglers on the old IP for a day.
• Take a full backup on the old server regardless of what migration method you use — this is your rollback path if anything goes sideways.
• Match PHP versions and extensions on the new server before you migrate, not after — a mismatch is the single most common cause of a white-screen-of-death post-migration.

Method 1: Full Server Image / Snapshot Migration

If your old and new providers both support server images (many VPS providers do), this is the cleanest path: snapshot the running server, transfer the image, and boot it on the new provider’s infrastructure. It preserves the exact OS state, installed packages, and config files without manual reconstruction. The catch is portability — not every provider accepts another provider’s image format directly, and IP-dependent configs (firewall rules referencing the old IP, hardcoded server names) still need manual review after boot.

Method 2: Manual Stack Migration (More Common)

When a direct image import isn’t available, rebuild the stack manually:

1. Provision the new server with matching OS, web server (Nginx/LiteSpeed/Apache), PHP version, and MySQL/MariaDB version.
2. Export the database with wp db export (or mysqldump if you’re not using WP-CLI) and transfer it via rsync or scp — avoid email or browser-based transfer for anything beyond a trivial size.
3. Sync the files with rsync -avz --progress pointed at the WordPress root, including wp-content/uploads, active theme, and plugins — this preserves permissions and lets you resume an interrupted transfer without starting over.
4. Import the database on the new server and update wp-config.php with the new DB credentials.
5. Run a search-replace if the domain or protocol (http→https) is changing: wp search-replace 'oldsite.com' 'newsite.com' --all-tables — always dry-run first with --dry-run.

DNS Cutover Without Downtime

The trick to a zero-downtime cutover is testing the new server before DNS points to it. Edit your local machine’s hosts file to point your domain at the new server’s IP, load the site, and verify everything — login, checkout flows, forms — while the old server is still live and serving real traffic. Only flip the actual DNS A record once you’ve confirmed the new server works end-to-end. Because you lowered TTL beforehand, propagation should complete within minutes to a couple hours for most resolvers, rather than the up-to-48-hour worst case of an un-lowered TTL.

Post-Migration Verification Checklist

Check	How
Site loads over HTTPS	Visit directly, confirm valid SSL cert (reissue via Let’s Encrypt/host tool if needed)
Database connects cleanly	No “Error establishing a database connection” on any page
Uploads/media render	Spot-check recent posts and product images
Cron jobs fire	Confirm WP-Cron or system cron entries transferred and are running
Email deliverability	Send a test form submission / password reset, confirm it arrives
Old server decommission	Wait at least 5-7 days post-cutover before shutting down the old VPS, in case of slow-resolving DNS caches

Common Pitfalls

The most frequent failure isn’t the migration itself — it’s forgetting something that lived outside WordPress: a custom cron script, an SMTP relay configuration, a firewall allowlist for a payment gateway’s IP range, or an SSL certificate that was issued specifically for the old server’s hostname. Keep a running inventory as you go, not just a mental list.

Verdict

A VPS-to-VPS migration is very manageable when you sequence it correctly: provision and match the stack first, transfer and verify on the new server while the old one keeps serving live traffic, then cut DNS over only once you’ve proven the new environment works. The single highest-leverage habit is testing via a local hosts-file override before touching DNS — it turns “hope this works” into “already confirmed this works,” which is the difference between a non-event and a stressful evening.

FAQ

How long should I keep the old server running?
At least 5-7 days after cutover to catch stragglers on cached DNS, longer if you have a large or geographically spread audience.

Do I need to migrate email separately?
Yes, if email is hosted on the same server — mail migration follows its own process (MX records, mailbox export/import) and isn’t covered by a WordPress files/database migration.

What if the new server uses a different web server software?
Rewrite rules (.htaccess for Apache, server blocks for Nginx, rules for LiteSpeed) don’t transfer directly — you’ll need to translate them manually or use your host’s conversion tooling.