When to Move WordPress from Shared Hosting to a VPS
In this article7 sections
If your WordPress site is slow on shared hosting and you have already done the basics, the problem is often the plan, not the site. A shared server gives every account a slice of CPU, memory and PHP workers, and when your neighbours use theirs, your pages wait. Moving to a VPS running Nginx on Ubuntu removes that wait, because the resources are yours. It also means you run the server, so this is not the right move for every site. This guide shows how to tell whether you have hit the shared limit, what changes on a VPS, and how to move safely.
Signs the shared plan is the bottleneck
Slow pages alone do not prove the plan is at fault. Plugins, a heavy theme and a missing cache all make WordPress slow on any server. The plan is the likely cause when these patterns repeat:
- Slowness comes and goes with no change on your side. The same page can take a fraction of a second in the morning and several seconds in the evening, when other accounts on the server are busy.
- Errors under load. Pages return 503 or “resource limit reached” messages during traffic peaks, or the admin area times out when a visitor spike hits.
- Caching is set up but the site is still slow. Cached pages are fast, but the first visit after an update or a cache expiry is slow, and it stays slow for logged-in users and checkout pages.
- You keep raising limits without improvement. You have already removed unused plugins, set up a cache and optimised images, and the site is still slow when traffic grows.
- The site works until you add a feature. A new plugin, a larger store catalogue or a scheduled import pushes the site over the line the plan allows.
If you see only one of these once, watch it for a week before changing anything.
Measure before you move
Use the measurements to decide, not the feeling. Two checks take about an hour:
- Time to first byte at different hours. Run this from your own computer, once in the morning and once in the evening, for the same uncached URL:
curl -o /dev/null -s -w "TTFB %{time_starttransfer}s total %{time_total}s\n" https://example.com/some-page/Replace the address with a real page. A large gap between the two times points to shared contention. Consistent slowness points to the site itself, and the guide why is my WordPress site slow explains how to find the cause.
- Your hosting panel’s resource graphs. Look for CPU, entry process or memory limits that are regularly reached at peak times. Your host can confirm the exact limits in writing. Ask for them, because “unlimited” plans still have hidden caps.
If the evening times are much worse and your panel shows limits reached, the plan is the bottleneck. If the times are similar and slow, fix the site first.
How we measured (16 October 2026). We timed the SiteHarbour blog from one test location, five requests per page. Cached pages, served from the Cloudflare edge, took about 0.2 to 0.3 seconds to first byte. Uncached requests, which travel all the way to the origin server, took about 0.3 to 0.5 seconds. Those figures show the cache working. They are not a shared-versus-VPS comparison, which needs the same test run on both plans. The command above works for that.
What a VPS changes
A VPS (virtual private server) is a slice of a physical machine that is reserved for you. The differences that matter for WordPress are these:
- Reserved memory and CPU. Your PHP workers, database and cache are not competing with other accounts. This is what removes the evening slowdown.
- Your own web server. Nginx serves static files directly and passes only PHP requests to PHP-FPM. Its FastCGI cache can answer most anonymous visitors without running PHP at all. The setup is in caching WordPress with Nginx FastCGI.
- Tuned PHP workers. You set how many PHP workers run, based on the memory you have, instead of accepting the host’s limit. The method is in sizing PHP-FPM workers for limited RAM.
- A database you control. MariaDB can be sized for your site and backed up on your schedule. See optimising MariaDB on a low-RAM WordPress server.
- Your own security and backups. You decide the firewall, SSH access, updates and backup schedule. This is a benefit and a responsibility at the same time.
The honest trade-offs
A VPS is not automatically better. Before moving, be sure you will do these things, or pay someone who will:
- Updates. The operating system, Nginx, PHP, MariaDB and WordPress all need regular updates. An unpatched server is less secure than a managed shared account.
- Backups. Shared hosts often include backups. On a VPS you must set them up, store them off the server and test a restore.
- Monitoring. Nobody is watching the disk, memory or certificates for you. A certificate that expires or a full disk causes an outage.
- Time. The first setup and the migration take hours, and the ongoing care takes some time each month.
If you do not want to run a server, a managed WordPress plan is a better fit than a self-managed VPS, even though it costs more than shared hosting.
Do not move if these are true
- The site is a brochure site with a few visits a day and fast pages. Shared hosting is cheaper and enough.
- The slowness is caused by a heavy plugin or an unoptimised database. A VPS will run the same mistake on dedicated resources, and the bill goes up without the fix. Find the cause first.
- You have no one to maintain the server and do not want to learn. A managed plan will serve you better.
A safe migration, step by step
A move is safe when the old site stays running until the new one is proven. Use this order:
- Size the VPS for your traffic. A 2 GB RAM server handles many small sites. A busy store or a site with heavy plugins needs more. Start with the size you measured, not the smallest one, and resize later if the graphs say so.
- Lower the DNS TTL a day before. A short TTL lets you switch back quickly if something goes wrong. The steps are in pointing your domain to hosting DNS.
- Copy the files and the database. Take a fresh backup of both on the old host, copy the files to the VPS and import the database. Keep the old copy untouched.
- Test on the new server before switching. Point your computer’s hosts file at the VPS address and check the site, the admin area, forms, checkout and email. The method is in moving a WordPress site to a new host with no downtime.
- Switch DNS and watch. Change the record, then watch the error log and the TTFB check from earlier for a few days.
- Keep the old account for two weeks. Only close it when the new server has run through a normal week without problems.
Test restoring a backup on the VPS before you rely on it. A backup you have never restored is not yet a backup.
Once the site runs on a VPS, the proxy settings matter as much as the move. For the traffic side, see how to tune Nginx for a high-traffic website and how to fix 504 Gateway Timeout on Nginx. Harden the new server with how to audit a new Ubuntu VPS for security.
Frequently asked questions
How much RAM does a WordPress VPS need?
For one small to medium WordPress site, 2 GB is a practical start. A store, a membership site or several busy sites need more. Measure the memory used at peak time after the move and resize based on that.
Is Nginx better than Apache for WordPress?
Nginx serves static files efficiently and handles many connections with little memory, which suits a small VPS. Apache works well too. The main gain comes from the cache and tuned PHP workers, which you can set up with either. Nginx is the choice in this guide because its configuration is explicit and easy to test.
Can I keep shared hosting for email and move only the website?
Yes. Many people keep email on a separate service and move only the website. Point the mail records to the email provider and leave them there, so a website move does not change mail delivery.
Will moving make my site faster immediately?
Only if the shared plan was the bottleneck. If the site is slow because of plugins or queries, the VPS will be slow too until those are fixed. Measure before and after to see the difference.
Do I need to know Linux?
You need basic command-line skills to run a VPS yourself. If you do not have them, choose a managed plan or ask a provider for managed support.
Moving from shared hosting to an Nginx VPS is the right step when the plan is the proven limit, and the wrong step when the site is the problem. Measure at different hours, confirm the limits in writing, fix the obvious site problems, and then move in the safe order above with the old site kept running.