Migrate WordPress from Shared Hosting to VPS — A Complete Step-by-Step Guide

Introduction

Migrating a WordPress site from shared hosting to a Virtual Private Server (VPS) is a common next step when traffic, performance, or control requirements outgrow a shared environment. A VPS offers dedicated resources, root access, and the flexibility to tune the stack for WordPress. This guide walks through the migration process with practical, technical details aimed at webmasters, agencies, and developers who need a reliable, repeatable procedure.

Why move from shared hosting to a VPS? (Principles and motivations)

Shared hosting places multiple customers on a single machine with limited per-account resources and restricted configuration options. A VPS provides an isolated environment with guaranteed CPU, RAM, and storage allocations. Key motivations include:

• Performance: Reduced noisy-neighbor effects, ability to allocate more memory and CPU to PHP and database processes.
• Control: Root or sudo access to install specific versions of PHP, Nginx/Apache, or custom modules.
• Security: Better isolation boundaries and the ability to implement firewalls, SELinux/AppArmor, and custom hardening.
• Scalability: Vertical scaling (resizing VPS) and horizontal scaling with load balancers are available.

When a VPS is the right choice (application scenarios)

Consider migrating to a VPS when:

• Your site consistently hits CPU or memory limits on shared hosting.
• You need custom server-level caching (Redis, Memcached) or object caching plugins that require server-side installation.
• You’re running multiple WordPress multisite instances or heavy e-commerce platforms (WooCommerce) with many concurrent users.
• You require compliance controls or stricter isolation than shared hosting provides.

Pre-migration planning and checklist

Thorough planning reduces downtime and rollback complexity. Before you start, prepare:

• Access credentials: FTP/SFTP, cPanel, phpMyAdmin, current DNS provider login, and SSH root for the target VPS.
• List of installed plugins and their versions. Note any server-level dependencies (ImageMagick, WP-CLI, cron schedules).
• Backup strategy: full file backup and database dump. Verify backup integrity.
• Target server stack decision: LEMP (Nginx + PHP-FPM + MariaDB/MySQL) or LAMP (Apache + mod_php or PHP-FPM).
• SSL certificate plan: Let’s Encrypt or provider-issued certs. Decide whether to reissue on the VPS or migrate keys.

Step-by-step migration

1. Provision the VPS and basic hardening

Choose a VPS with sufficient resources (CPU cores, RAM, disk I/O). For many WordPress sites, start with at least 2 vCPU and 2–4 GB RAM; increase if using caching layers or WooCommerce. After provisioning:

• Update the system:

  sudo apt update && sudo apt upgrade -y (Debian/Ubuntu)

• Create a non-root user and configure SSH key authentication:

  adduser deployer
usermod -aG sudo deployer

  Copy your public key to ~/.ssh/authorized_keys and disable root login in /etc/ssh/sshd_config.

• Set up a basic firewall:

  ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

2. Install the web stack

Example LEMP stack on Ubuntu:

• Install Nginx:

  sudo apt install nginx -y

• Install PHP and extensions:

  sudo apt install php-fpm php-mysql php-xml php-gd php-curl php-mbstring php-zip -y

• Install MariaDB (or MySQL):

  sudo apt install mariadb-server -y

  Secure DB: sudo mysql_secure_installation

• Optional: Install WP-CLI for command-line WordPress management:

  Download and make executable, then move to /usr/local/bin/wp.

3. Prepare the database on the VPS

Create a new database and user matching the values in your WordPress wp-config.php or update the config later.

Example commands:

sudo mysql -u root -p

In the MySQL shell:

CREATE DATABASE wpdb CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wpuser'@'localhost' IDENTIFIED BY 'strongpassword';
GRANT ALL PRIVILEGES ON wpdb. TO 'wpuser'@'localhost';
FLUSH PRIVILEGES;

4. Export files and database from shared hosting

• Files: Use rsync over SSH (preferred) or FTP. Example:

  rsync -avz --progress user@sharedhost:/home/user/public_html/ /home/deployer/site/

• Database: Use mysqldump or phpMyAdmin. Example with mysqldump:

  mysqldump -u dbuser -p dbname > site_backup.sql

  If remote DB access is blocked, you can run mysqldump on the shared host via SSH and pipe to the VPS:

  ssh user@sharedhost "mysqldump -u dbuser -p'dbpass' dbname" > site_backup.sql

5. Import files and database to the VPS

• Move files into the web root, e.g., /var/www/site, adjust ownership:

  sudo mkdir -p /var/www/site
sudo rsync -avz --progress /home/deployer/site/ /var/www/site/
sudo chown -R www-data:www-data /var/www/site

• Import the SQL dump:

  mysql -u wpuser -p wpdb < site_backup.sql

• Edit wp-config.php to reflect the new DB credentials and update WP_HOME and WP_SITEURL if necessary.

6. Configure the web server

Create a server block (virtual host) for the site. Example Nginx server block:

sudo nano /etc/nginx/sites-available/site

Basic configuration:

server {
listen 80;
server_name example.com www.example.com;
root /var/www/site;
index index.php index.html;

location / { try_files $uri $uri/ /index.php?$args; }

location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php7.4-fpm.sock; }

location ~ .(css|js|jpg|jpeg|png|gif|ico|svg)$ { expires max; log_not_found off; }
}

Enable and test:

sudo ln -s /etc/nginx/sites-available/site /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx

7. Configure PHP-FPM and performance tuning

Adjust PHP-FPM pool settings in /etc/php/7.4/fpm/pool.d/www.conf (path varies by PHP version). Key parameters:

• pm = dynamic or ondemand (ondemand conserves memory for low-traffic sites)
• pm.max_children based on available RAM (estimate ~30–50MB per PHP-FPM child + script memory)
• pm.start_servers, pm.min_spare_servers, pm.max_spare_servers for dynamic mode

Example calculation: on a 2GB VPS, reserve ~512MB for OS and DB; allocate ~1GB for PHP-FPM. If each child consumes ~60MB, set pm.max_children ~16.

8. Implement caching and object cache

Install server-side caches to reduce PHP and DB load:

• Varnish or Nginx caching for full-page caching (ensure correct handling of dynamic pages like cart/checkout).
• Redis or Memcached for object cache with a plugin such as Redis Object Cache or W3 Total Cache.
• PHP opcode cache (OPcache) should be enabled in PHP config (opcache.memory_consumption, opcache.max_accelerated_files).

9. SSL certificate and final testing

Issue a certificate with Let’s Encrypt:

sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

Test the site on the VPS before switching DNS by editing your local hosts file to point the domain to the VPS IP. Verify:

• Front-end pages load quickly and correctly.
• Admin dashboard is functional and plugins work.
• Forms, login, search, and any integrations (payment gateways, APIs) function.
• Error logs (/var/log/nginx/error.log, PHP-FPM logs, and wp-content/debug.log if enabled) show no critical errors.

10. DNS switchover and post-migration tasks

Lower TTL on the existing DNS records 24–48 hours before migration to reduce propagation delay. When ready, update the A record to the VPS IP. Monitor traffic, errors, and resource utilization closely for the next 24–72 hours.

Post-migration checklist:

• Re-enable higher TTLs after propagation.
• Set up automated backups (server snapshots + daily DB dumps + offsite file sync).
• Configure log rotation and monitoring tools (Prometheus, Grafana, or simpler solutions like UptimeRobot + server resource alerts).
• Harden WordPress: disable file editing, enforce strong salts in wp-config.php, and install a security plugin or WAF.

Advantages comparison: VPS vs Shared Hosting

Below are concise contrasts to clarify trade-offs:

• Performance: VPS typically outperforms shared hosting due to guaranteed resources and better I/O performance.
• Cost: Shared hosting is cheaper for basic sites; VPS costs more but delivers scalability and control.
• Management: Shared hosting often comes with managed services and one-click tools; VPS may require sysadmin skills unless a managed VPS plan is chosen.
• Security: VPS allows more robust server-level security controls; shared hosting security depends on the provider’s isolation mechanisms.
• Flexibility: VPS supports custom stacks, background workers, and server-side caching which shared hosting usually restricts.

Choosing the right VPS: practical advice

When selecting a VPS provider and plan, consider these factors:

• Resource needs: Estimate CPU, memory, disk throughput, and IOPS. Use hosting analytics (traffic, average response time, WP queries) to guide sizing.
• Managed vs unmanaged: If you lack server administration experience, a managed VPS reduces operational burden.
• Backup and snapshot policies: Ensure regular automated snapshots and easy restoration.
• Network and datacenter location: Choose a data center near your user base for lower latency. For U.S. audiences, consider a provider with U.S. VPS locations.
• Support & SLAs: Check support hours, response times, and uptime guarantees.

For more information about VPS options and a U.S. data center presence, see the provider information page: VPS.DO and specific U.S. plans here: USA VPS.

Conclusion

Migrating WordPress from shared hosting to a VPS delivers measurable gains in performance, security, and configurability, but requires planning and some system administration work. Follow the steps above—provision and harden the VPS, migrate files and database safely, configure the stack, tune PHP-FPM and caching, and execute a careful DNS cutover—to minimize downtime and ensure a smooth transition.

Finally, align your VPS selection with traffic patterns and administrative capability. If you prefer minimal operational overhead, consider managed VPS options. If you want full control and optimization room, an unmanaged VPS is ideal. For U.S.-based deployments, you can review available plans and locations at USA VPS and general offering details at VPS.DO.