DevOps & Hosting

How to move a WordPress site from shared hosting to a VPS (step by step)

A practical, low-risk plan for migrating WordPress from shared hosting to your own VPS — choosing a server, installing Nginx, PHP and MariaDB, securing it, moving files and database, switching DNS and verifying everything.

WordPress VPS – How to move a WordPress site from shared hosting to a VPS (step by step)

A WordPress VPS migration from shared hosting takes seven stages: choose and secure the server, install the web stack (Nginx, PHP-FPM, MariaDB), copy the files and database, update the configuration, test on the new server before switching, change DNS, then add SSL and backups. Done carefully, visitors notice nothing except a faster site.

I recently did exactly this for my own site and several client sites: a fresh Ubuntu VPS, Nginx, PHP 8.5, MariaDB, a firewall, key-only SSH, free SSL and automatic deploys from GitHub. This guide follows the same steps, in plain language, with the decisions that matter.

Key takeaways

  • A VPS gives you dedicated resources, full control and usually a faster site than crowded shared hosting — but you are responsible for security and updates.
  • For a typical business site, 2 vCPU and 4–8 GB RAM is plenty.
  • Secure the server before moving anything: SSH keys only, firewall on, root password login off.
  • Lower your DNS TTL a day before the move, so the switch takes minutes, not hours.
  • Test on the new server first (hosts file or a temporary subdomain), then switch DNS.
  • Keep the old hosting for one to two weeks as a fallback.
WordPress VPS guide overview: what this article covers
What this guide covers

Why move from shared hosting to a WordPress VPS?

Shared hosting puts hundreds of websites on one server. When a neighbour gets a traffic spike or a malware infection, your site feels it. You also cannot change most server settings.

Shared hostingVPS
ResourcesShared with many sitesReserved for you
Speed (TTFB)Often inconsistentConsistent, usually faster
ControlLimited panelFull root access
SecurityManaged by host, shared riskYour responsibility, isolated
Multiple sites and subdomainsPlan limitsAs many as the server handles
PriceCheapSimilar to good shared plans; more for managed
Who maintains itThe hostYou or your developer

The last row is the important one. A VPS is not “set and forget”. Someone must apply updates, watch the disk and keep backups. If that is your developer, include it in the plan.

What size VPS does a WordPress site need?

For one to five business sites with normal traffic:

  • CPU: 2 vCPU
  • RAM: 4 GB (8 GB if you run WooCommerce or several busy sites)
  • Disk: 50–100 GB NVMe SSD
  • OS: a current Ubuntu LTS release

Pick a data centre close to most of your visitors. You can always upgrade the plan later; most providers resize in minutes.

Step 1: How do you secure a new VPS before installing WordPress?

Bots start trying to log in to a new server within minutes of it going online. Lock it down first.

  1. Log in once and update everything (apt update && apt upgrade).
  2. Create an SSH key on your own computer and add the public key to the server.
  3. Confirm key login works, then turn off password login for SSH and set root to key-only.
  4. Turn on the firewall (UFW on Ubuntu) and allow only SSH, HTTP and HTTPS.
  5. Enable automatic security updates.
  6. Check your provider’s firewall in their control panel. Some providers have a second firewall in front of the server; it must allow the same ports.

Always test the new SSH key in a second window before you turn off password login. If the key does not work and you close your only session, you will need the provider’s web console to get back in.

WordPress VPS at a glance: comparison table
At a glance

Step 2: What software does WordPress need on a VPS?

The classic, reliable stack is:

ComponentJobNotes
NginxWeb serverFast, low memory, easy to configure per site
PHP-FPMRuns WordPressUse a current PHP version with OPcache
MariaDB or MySQLDatabaseOne database and one user per site
CertbotFree SSL certificatesRenews automatically
WP-CLIWordPress from the command lineMakes installs, migrations and search-replace easy

Install the PHP extensions WordPress needs: mysqli, curl, gd or imagick, intl, mbstring, xml and zip.

Step 3: How do you create the database and site folder?

For each site:

  1. Create a database and a dedicated database user with a long random password. Give that user rights to that one database only.
  2. Create a folder such as /var/www/example.
  3. Create an Nginx server block for the domain, pointing to that folder and passing .php files to PHP-FPM.
  4. Block access to hidden files (like .git) and to xmlrpc.php unless you need it.
  5. Raise client_max_body_size and PHP’s upload_max_filesize if you upload large media.

Step 4: How do you copy the files and database from shared hosting?

There are two common methods.

Method A: a migration plugin

Plugins like All-in-One WP Migration or Duplicator package the files and database into one archive. You install a fresh WordPress on the VPS, install the same plugin, and import. It is easy, but large sites may hit size limits.

Method B: files and database directly (my preferred method)

  1. Export the database from the old host (phpMyAdmin or mysqldump).
  2. Download wp-content — themes, plugins and uploads. You do not need WordPress core; install a fresh copy on the VPS.
  3. Upload both to the VPS with rsync or scp.
  4. Import the database into the new database with WP-CLI.
  5. Create wp-config.php with the new database name, user and password, and fresh security keys.
  6. Set ownership and permissions: files owned by the web server user, folders 755, files 644, wp-config.php stricter.

This method handles large sites well and leaves no extra plugin behind.

Step 5: How do you test the new server before switching DNS?

Never switch DNS and hope. Test first:

  • Hosts file: on your computer, point the domain at the new server’s IP in your hosts file. Your browser now loads the VPS while everyone else still sees the old host.
  • Or a temporary subdomain: for example new.example.com, then search-replace the URL after the switch.

Check:

  1. Home page, inner pages and blog posts load.
  2. Images and media load (no 404s).
  3. Forms send email.
  4. Logging in to wp-admin works.
  5. Permalinks work (if not, the Nginx try_files rule is missing).
  6. WooCommerce checkout works in test mode.
  7. No PHP errors in the server log.

Step 6: How do you switch DNS with minimal downtime?

  1. A day before: lower the TTL of your domain’s A record to 300 seconds (5 minutes).
  2. Freeze content on the old site — no new posts or orders during the switch. For stores, choose a quiet hour.
  3. Re-sync the database and new uploads if anything changed since the copy.
  4. Change the A record (and www) to the VPS IP.
  5. Watch the logs on the new server; traffic should arrive within minutes.

Keep email records (MX, SPF, DKIM, DMARC) exactly as they are. Moving the website does not mean moving email, and deleting those records stops your email.

Step 7: How do you add SSL, backups and monitoring?

Once DNS points to the VPS:

  • Issue free SSL with Certbot for the domain and www, with an automatic HTTP to HTTPS redirect. Renewal runs automatically.
  • Redirect www to the main domain (or the other way round) so there is one canonical address.
  • Set up backups: a daily database dump and file backup, stored off the server.
  • Add security headers in Nginx (X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Strict-Transport-Security).
  • Turn on compression for CSS, JS and SVG.
  • Monitor uptime with a free service, so you hear about problems before your clients do.

What about SEO during a hosting migration?

A hosting move does not change your URLs, so rankings are safe if:

  • The site is down for minutes, not days.
  • Every URL returns the same content (check your sitemap URLs).
  • If the site must be offline briefly, it returns 503 “Service Unavailable” with a Retry-After header, not a blank page or a 404. Google treats 503 as temporary.

Common mistakes to avoid

  • Turning off SSH passwords before confirming the key works.
  • Forgetting the provider-level firewall.
  • Deleting email DNS records while editing the A record.
  • Leaving the old hosting active and sending forms from both servers.
  • No backups on the new server “because it’s new”.
  • Running everything as root, including deploys. Use a separate, restricted user.

How do you plan a migration with zero surprises?

The technical steps are only half of a smooth move. The other half is planning:

WhenTask
One week beforeList every site, subdomain, email account and cron job on the old hosting
One week beforeNote PHP version, PHP settings and any server-level redirects or rules
Three days beforeSet up and secure the VPS; install the stack
One day beforeLower DNS TTL to 300 seconds; take full backups
Move dayCopy files and database, test via hosts file, final sync, switch DNS
Move day + 1Issue SSL, check forms, check search console for errors
Next 2 weeksKeep the old hosting as a fallback; monitor logs and uptime

The inventory step is where most migrations fail. A forgotten subdomain, a cron job that sent invoices, or an email account on the same hosting can break quietly after the move.

What about email when you move the website?

Many shared hosting plans include email for your domain. Moving the website to a VPS does not have to move email.

  • If your email stays with the old host (or Google Workspace, Microsoft 365), keep the MX, SPF, DKIM and DMARC records exactly as they are and only change the website records (A records for the domain and www).
  • If you cancel the old hosting, move email to a dedicated email service first.
  • Do not run a mail server on the VPS just for contact forms. Use SMTP with your email provider or a transactional email service, so form emails are delivered and do not land in spam.

How do you keep a VPS healthy after the move?

A short monthly routine keeps a WordPress VPS secure and fast:

  1. Apply system updates (security updates can be automatic).
  2. Update WordPress core, plugins and themes — on staging first for big updates.
  3. Check that backups ran, and test restoring one every few months.
  4. Check disk space and the size of log files.
  5. Review the firewall and the list of SSH keys; remove keys of people who no longer need access.
  6. Renewals: domain, SSL (automatic), premium plugin licences.
  7. Look at the error log for repeated PHP warnings.
WordPress VPS summary: key takeaways
Summary of the key points

FAQ

Frequently asked questions

Is a VPS faster than shared hosting for WordPress?

Usually yes, because resources are not shared and you can tune PHP, caching and the database for your site. A badly configured VPS can still be slow; configuration matters.

Will moving to a VPS cause downtime?

With the steps above — lower TTL, test before switching, sync, then change DNS — downtime is usually zero or a few minutes.

Do I need a control panel like cPanel on a VPS?

No. Many developers manage WordPress on a VPS with Nginx, WP-CLI and SSH, which uses fewer resources. Panels are convenient if non-technical people need access.

Who maintains the VPS after the move?

You or your developer. Plan for monthly updates, backup checks and occasional PHP upgrades, or choose a managed VPS.

Can I host several WordPress sites on one VPS?

Yes. Each site gets its own folder, database, database user and Nginx server block. A wildcard DNS record makes new subdomains easy.

If you want your WordPress site moved to a secure, fast VPS — or a new server set up with automatic deploys — see my VPS and DevOps service or hire me on Upwork.

Planning a project?

Invite me to your job or hire me on Upwork, and we can talk it through there. I usually reply within a few hours.

Hire me on Upwork
Shah Kamal

Written by

Shah Kamal

WordPress developer with 12+ years and 112 Upwork jobs. I build fast, secure WordPress sites and run them on well-tuned servers.

Insights

Keep reading

All insights

Have a WordPress project in mind?

Tell me what you need — I usually reply within a few hours.