Moving from Shared Hosting to a Budget VPS? Follow This 5-Phase Runbook

Shared hosting runs fine right up until it doesn’t. A neighbor’s traffic spike eats your CPU share, a plugin hits the memory ceiling, and support tells you to “upgrade to a dedicated plan.” Moving to a budget VPS fixes the resource problem, but the migration itself is where most site owners lose a weekend, or worse, break a live site.

This runbook is the exact five-phase process we use for small WordPress and custom sites: size, prepare, provision, transfer, and cut over. Budget 2–4 hours of hands-on time. Your site stays fully online the entire time; the only moment anything changes is the final DNS switch, which takes minutes.

Phase 1: Size the VPS from Your Current Usage

Don’t guess specs. Log into your shared host’s resource dashboard and look at real numbers: CPU usage, memory, entry processes, and inode count over the last 30 days. If your current plan is capped at 1 GB of memory and you’re sitting at 85% average, a 1 GB VPS will feel worse, not better.

Workload	Starter plan (budget tier)	Notes
WordPress blog or brochure site	1 vCPU / 1 GB RAM	Fine up to roughly 5,000 visits/month with a caching plugin
WordPress + WooCommerce (small store)	2 vCPU / 2 GB RAM	Object caching plus page caching required
Static site or single-page app	1 vCPU / 512 MB–1 GB	Runs comfortably on the cheapest plan
Custom app (Node.js, Python)	2 vCPU / 2 GB RAM	1 GB works for dev, not production with a database

When in doubt, take the next size up from your current shared usage. A 2 GB plan is the sweet spot for most small WordPress sites, and it costs only a few dollars more per month than 1 GB.

Phase 2: Prepare Everything Before You Order

• Export the database with mysqldump --single-transaction (or phpMyAdmin) and keep the file somewhere off the old host.
• Inventory your files: run rsync --dry-run first so you know exactly what will move and how big it is.
• Note your PHP version and enabled extensions (php -v, php -m); install the same versions on the new box to avoid plugin breakage.
• Collect every cron job (crontab -l or the cPanel cron list). Backups, certificate renewals, and queue workers all live here, and this is the #1 thing people forget.
• If you run email on the shared host, copy your DNS records (SPF, DKIM, MX) before you move.

Also note your .htaccess rules. If you switch to Nginx, rewrite rules don’t transfer automatically; either port them to the server block or stay on Apache.

Phase 3: Provision and Secure the New Box (30 Minutes)

• Create a non-root user and set up SSH key authentication; disable password logins.
• Configure the firewall (UFW is fine): allow only 22, 80, and 443.
• Install the web stack: Nginx + PHP-FPM + MariaDB is the standard low-memory combo; add 1–2 GB of swap as a safety net.
• Match memory_limit and max_execution_time in php.ini to the values your site currently runs with.

Phase 4: Move the Data (60–90 Minutes)

Keep the old host live during the transfer so nothing goes stale. First, copy the files:

rsync -avz --progress --partial user@old-host:/home/site/ /var/www/site/

Then move the database. Piping the dump straight into the new server is faster than exporting and re-importing in two steps:

mysqldump --single-transaction -u olduser -p olddb | ssh root@new-vps "mysql -u newuser -p newdb"

Verify before you celebrate: check row counts on your largest tables (SELECT COUNT(*) FROM wp_posts;), compare the size of wp_options, and spot-check a few uploads. Large wp-content/uploads folders should use rsync --partial --inplace so an interrupted copy resumes instead of restarting.

Phase 5: Cut Over Without Downtime

• Lower your DNS TTL to 300 seconds at least 24–48 hours before cutover; this is what makes the final switch near-instant.
• Run one final rsync and one final database sync, then point the A record at the new IP.
• Verify from multiple locations (curl -I, an online DNS checker) and confirm the SSL certificate is reissued for the new server.
• Keep the shared account active for 30 days as a rollback path, and take a full backup of the new box on day one.

When to Call It and Roll Back

Keep the rollback trigger explicit: if the new box fails its health checks (500 errors, database connection failures, broken uploads) for more than 30 minutes after cutover, point DNS back at the old host and fix the issue on the new box before trying again. Because you kept the shared account live, rollback is a DNS change, not a restore job.

One tip from real migrations: run the full sequence on a staging copy first. If you can move a test site end to end without breaking it, the production move is mostly routine, and you’ll have a checklist you’ve already executed once.

The 10-Minute Post-Move Checklist

• Cron jobs recreated and tested (run each one manually once).
• Email sending still works (SPF/DKIM records updated if you moved mail).
• Nightly backups scheduled: one local and one offsite destination.
• Monitoring enabled: an uptime check plus a disk-space alert.

Once the new box is stable for a week, cancel the shared plan and pocket the difference; most budget VPS plans cost less than a mid-tier shared account while giving you far more headroom. If you’re still comparing entry-level plans before you start, you can compare budget providers on our VPS comparison table.