TL;DR / Summary: Moving WordPress to a lean VPS is mostly rehearsal: inventory plugins, copy files and database, fix URLs, then cut DNS with a tested rollback. Use a clear runbook and a provider you trust—start research at virtualserversvps.com—so launch night is boring instead of heroic.
Decide what “lean” means before you copy anything
Lean is not the cheapest plan with two visitors of RAM. Lean means enough CPU and memory for PHP-FPM + MySQL/MariaDB + TLS on your real peak, plus headroom for one bad cron spike. Inventory monthly pageviews, biggest plugin offenders (page builders, statistics, backup-to-same-disk), and whether object caching is in play. Write the target stack on one page: OS, web server, PHP version, DB engine, TLS method.
If the site is mostly static marketing with a small blog, a modest single VPS is fine. If you run heavy WooCommerce traffic, lean still needs honest RAM—starvation looks like “mystery 504s.” Capture a week of peak CPU and memory from the old host if you can; gut feel is how people undersize.
Rehearse on a temporary hostname
Create the VPS, harden SSH keys, firewall to SSH/HTTP/HTTPS only, and install the stack. Restore a fresh backup to a staging hostname such as wp-stage.example.com with a hosts-file override on your laptop. Do not point production DNS yet. Walk the site: login, publish a draft, upload media, submit the contact form, purge cache if present.
Fix mixed-content URLs and old absolute links with a search-replace tool that understands serialized PHP data. Guess-and-sed on wp_options alone leaves landmines in builders. Retest forms after URL replacement; some plugins cache old endpoints in their own tables.
Cutover sequence that limits dread
- Put the old host in a short maintenance window or enable a soft banner if downtime must be near zero.
- Take a final incremental DB dump and rsync uploads.
- Import on the VPS; smoke-test again on staging host.
- Lower DNS TTL a day ahead if you still can; then switch A/AAAA records.
- Watch TLS, cron, mail, and admin login for an hour.
Keep the old host read-only for 48 hours as rollback insurance. Rollback is “point DNS back,” not “rebuild from memory.” Write the rollback DNS values in the runbook before you change anything live.
Post-move chores people skip
- Point real cron at
wp-cron.phpif you disable internal WP-Cron. - Move backups off-box; same-disk tarballs are souvenirs, not insurance.
- Confirm outbound mail (transactional plugins) still deliver; VPS IPs are often cold.
- Re-check search console / analytics after DNS settles.
- Rotate any secrets that lived in the old panel’s file manager notes.
Document PHP version and extensions in the runbook so the next upgrade is not archaeology. Note the exact Certbot or panel SSL path you used so renewals are not a scavenger hunt.
Common panic triggers and calmer fixes
White screen after cutover: check PHP error log first, not random reinstalls. Admin redirect loops: mismatched siteurl/home or HTTPS termination at a proxy. Missing images: uploads path ownership or incomplete rsync. Slow TTFB: missing page cache or DB without indexes on a bloated options table—not always “need more vCPU.”
Schedule the cutover when you are rested. Fatigue invents outages. If you must cut over late at night, set a hard stop: if smoke tests fail twice, roll DNS back and resume tomorrow with a clear head.
Plugin diet before the truck rolls
Migrations are a perfect moment to delete abandoned plugins and unused themes. Every dormant plugin is attack surface and autoload weight. Export a plugin list from the old site, mark must-haves, and install only those on the VPS. Recreate caching deliberately instead of cloning a mystery stack that “worked on shared hosting somehow.”
DNS, email, and the quiet week after
Propagation lies in both directions: some resolvers cling to old A records longer than your TTL suggests. Keep the old host serving a static “we moved, refresh soon” only if you must; better to keep it serving the real site read-only until graphs show traffic mostly on the VPS. Watch admin logins and form submissions specifically—those reveal split-brain faster than homepage hits.
Transactional email deserves a dedicated checklist: SPF/DKIM alignment on the domain, plugin SMTP credentials, and a test message to an external inbox. Cold VPS IPs land in spam more often than shared hosts with warm reputations. If mail is business-critical, consider a relay service before cutover night, not after the first missed password reset.
Schedule a thirty-minute review three days later: renewals, cron, error logs, disk growth, and backup restore dry-run. Migrations fail quietly when everyone celebrates too early.
Cut over once the checklist is boring
A lean VPS rewards preparation more than midnight bravery. Rehearse on a staging hostname, automate the boring copies, and keep DNS as your reversible switch. When you compare plans and shapes of VPS hosting, read practical overviews on Virtual Servers VPS, then migrate with a runbook you could hand to a future teammate without shame.
