VPS Migration Checklist: Moving Off Shared Hosting Without Breaking Your Site

By Alon M. Infrastructure Analyst · OpsForge Labs Spent a decade-plus moving up the IT stack from end-user support and server builds through large enterprise environments and on into cloud and AI operations. Evaluates hosting and infrastructure decisions from an operator's perspective, not a reviewer's.
Published: May 8, 2026 7 min read
Disclosure: OpsForge Labs participates in affiliate programs. If you purchase through our links, we may earn a commission at no additional cost to you. Recommendations are based on technical evaluation and operator experience, not affiliate fees.

BLUF -- Bottom Line Up Front

A VPS migration has four phases that must happen in sequence: pre-migration audit and backup, server provisioning and stack setup, file and database transfer with local testing, and DNS cutover with a 48-hour retention window on the old host. The most common failure point is cutting over DNS before the new environment is verified. Test against the new server IP using a hosts file override before touching a single DNS record.

Moving from shared hosting to a VPS transfers operational responsibility. On shared hosting, the provider manages the stack. On a VPS, you do. This checklist covers the sequence and the specific checkpoints that prevent the failure modes most migrations produce.

Provision an InterServer VPS to start

Phase 1: Pre-Migration Audit

Document the source state before provisioning anything. The destination environment needs to match what the application actually requires, not what you assume it requires.

Stack inventory. Document your current PHP version, MySQL or MariaDB version, and any PHP extensions the application depends on -- imagick, memcached, zip, and similar. These are not installed by default on a clean VPS and missing extensions produce errors that are annoying to diagnose after the fact.

Full local backup. Generate a manual backup of all files plus a database export. Download both to local storage and verify the files are not corrupted before proceeding. Do not rely solely on host-side automated backups as your recovery point for this migration.

DNS TTL reduction. 24-48 hours before the migration, lower the TTL on your domain's A records to 300 seconds (5 minutes). This reduces propagation wait time during cutover from hours to minutes. Do this early -- TTL changes take effect on the current TTL cycle, not immediately.

Phase 2: VPS Provisioning and Initial Hardening

Provision the server and harden it before installing any application stack.

OS selection. Ubuntu 24.04 LTS is the current recommendation for new WordPress deployments -- long support window, wide package availability, and well-documented Nginx/PHP-FPM configuration.

SSH key authentication. Disable password-based SSH authentication. Provision an Ed25519 key pair for administrative access. Password auth on a public IP is a liability from the first minute the server is live.

Non-root user. Create a non-root user with sudo privileges. Application deployments, cron jobs, and web server processes should not run as root.

Firewall baseline. UFW is sufficient for most deployments. Allow ports 22 (SSH), 80 (HTTP), and 443 (HTTPS). Drop everything else by default.

Phase 3: Stack Configuration

Two paths -- choose based on your management preference and time investment.

Option A: Stack manager (recommended for most operators). RunCloud, ServerPilot, or SpinupWP install on top of the VPS and provide a managed interface for Nginx, PHP-FPM, MySQL, and SSL provisioning. They handle the configuration tuning that takes hours to do manually and keep the stack updated. Combined cost: $6-12/mo VPS + $5-15/mo manager. This is the correct approach for operators who want a managed-WordPress-style experience on self-owned infrastructure.

Option B: Manual LEMP stack. If you prefer direct control, install Nginx, PHP-FPM, and MySQL manually. Key php.ini values for a WordPress production environment:

memory_limit = 512M
upload_max_filesize = 128M
max_execution_time = 300
post_max_size = 128M

For WooCommerce, 512M is the practical minimum. A page-builder theme with 50+ plugins may need 768M to avoid out-of-memory errors during admin operations.

SSL certificate. Certbot with Let's Encrypt provisions a free certificate and handles automated renewal: certbot --nginx -d yourdomain.com -d www.yourdomain.com

Phase 4: File and Database Transfer

Do not use WordPress's built-in Export tool for this migration. It does not preserve file structure, configuration files, or database-level media metadata. Use one of the following approaches.

Migration plugin method (simplest). Duplicator, All-in-One WP Migration, or Migrate Guru create a packaged archive that includes files and database and handles the import on the destination server. For most standard WordPress sites under 2 GB, this is the lowest-friction path.

rsync + mysqldump (direct). For larger sites or non-standard setups: use rsync to transfer the wp-content directory and root WordPress files -- rsync preserves file permissions and resumes interrupted transfers. For the database, run mysqldump on the source host and import via CLI on the VPS to bypass the timeout limits that phpMyAdmin imposes on large databases.

After transfer, update wp-config.php on the VPS to reflect the new database name, user credentials, and host. If the application URL is changing, run a search-replace via WP-CLI: wp search-replace 'old-domain.com' 'new-domain.com' --all-tables

Phase 5: Testing Before DNS Cutover

This step is not optional. Do not change a DNS record until the new environment is verified.

Hosts file override. Map your domain to the new VPS IP in your local hosts file. This routes your browser to the VPS while everyone else still hits the old host.

Add: YOUR_VPS_IP yourdomain.com www.yourdomain.com

What to test while the override is active:

Remove the hosts file entry after testing is complete.

Phase 6: DNS Cutover and the 48-Hour Retention Rule

Update your A record (and www CNAME) to the new VPS IP. With a 5-minute TTL set in Phase 1, propagation completes within minutes for most resolvers.

Keep the old hosting account live and files intact for 48 hours after cutover. DNS propagation is not instantaneous globally -- some ISPs, search crawlers, and enterprise DNS resolvers cache records on longer cycles regardless of TTL. Premature decommissioning of the old host is the primary cause of post-migration 404 errors and data loss. Do not cancel the old account until 48 hours of clean operation on the VPS is confirmed.

Phase 7: Post-Migration Verification

Run this after propagation is confirmed globally (use whatsmydns.net or similar to verify):

Common Migration Problems and Fixes

Database connection failure. wp-config.php credentials do not match the VPS MySQL configuration. Verify DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. If the database is listening on a socket rather than localhost, the DB_HOST value needs to reflect the socket path.

404 errors on all pages except the homepage. Nginx permalink routing is not configured. The Nginx server block needs the correct try_files directive for WordPress: try_files $uri $uri/ /index.php?$args;

White screen of death (WSOD) after migration. Usually a PHP version mismatch between the old host and the new VPS. Enable WP_DEBUG temporarily in wp-config.php to log the specific error. A missing PHP extension (commonly imagick or zip) is often the cause.

File permission errors on media uploads. The web server user does not own the uploads directory. Fix: chown -R www-data:www-data /path/to/wordpress/wp-content/uploads

FAQ

Is it safe to migrate a live WooCommerce store? With the hosts file testing method, yes -- the old store stays live throughout. For the final cutover window, put WooCommerce in maintenance mode before the DNS change to prevent orders being split across old and new servers during the brief propagation period.

Do I need cPanel on the VPS? For one to five sites, a control panel adds resource overhead and complexity without meaningful benefit. A stack manager (RunCloud, ServerPilot) provides the common management tasks at lower cost and with less attack surface than a full cPanel license.

Should I host email on the VPS? No. Managing an email server's IP reputation, SPF/DKIM/DMARC configuration, and deliverability is a specialized operational task that belongs on a dedicated email provider. Keep the VPS for the application layer and use SendGrid, Mailgun, or similar for transactional email.

How should I handle backups after migration? Automated, encrypted backups to an off-server S3-compatible location -- Backblaze B2, Wasabi, or AWS S3. Automate via cron or your stack manager's built-in backup tooling. Test restores periodically. A backup you have never restored is a backup you cannot trust.

Related:

About the Author

Alon M. spent a summer pulling Cat6e through drop ceilings before WiFi made that job obsolete -- a fitting start to a career in IT infrastructure. He worked his way up from end-user support (if the fax machine died, you called Alon) through server builds, progressively larger enterprise environments, and on into cloud and AI operations. He built OpsForge Labs because most hosting and infrastructure advice is written by people who've never had to manage something at scale, fix something broken at 2am, or justify a budget decision to someone who doesn't know what a VPS is.