How to Migrate a WordPress Site to a VPS Without Downtime (Step-by-Step)

9 Mins ReadBy

From my own work: I’m Saizul Amin, a digital growth and web systems professional. I have worked on websites and SEO since 2017, and the examples below come from sites I run and maintain myself, not from theory. Last reviewed: October 2026.

Moving a WordPress site from shared hosting to a VPS is one of the best upgrades you can make for speed and control, and it is also where people lose email, rankings or a weekend. I recently moved four sites (three WordPress sites and one containerised web app) from shared cPanel hosting to a single VPS with a server control panel. Visitors never saw an error page. This is the process I followed, including what went wrong, so you can skip those mistakes.

Should you move to a VPS at all?

A VPS gives you dedicated resources, newer software and full control, which usually means faster sites and fewer “resource limit” errors. It also means you are now responsible for security, updates, backups and uptime. If you do not want that job, a good managed WordPress host is a better choice. If you do, read on.

The eight stages I follow. The old host stays untouched until the very end.

Step 1: Back up everything first (and keep it off the server)

  • Take a full backup from your current host (for cPanel, a full account backup; otherwise files plus a database export) and download it to your own computer. Do not rely on a backup stored only on the host you are leaving.
  • Write down every DNS record: A and CNAME records, but especially MX, SPF, DKIM, DMARC and any verification TXT records. Email is the thing most often broken by a migration, and in my case mail stayed with a separate provider, so those records had to remain untouched.
  • Decide your canonical address now: example.com or www.example.com. Pick one and use it everywhere. (I will show you why in the mistakes section.)
  • Note any scheduled tasks, custom .htaccess rules and redirects, because Nginx does not read .htaccess.

Step 2: Choose and harden the server before it holds anything

I used a VPS in Europe with a free server panel that provides Nginx, MariaDB and a separate PHP-FPM pool per site. The same ideas apply to any stack. Before copying a single file, lock the server down:

  • SSH keys only. Disable password login and direct root login.
  • Firewall: allow only the ports you need (web, SSH, and the panel, ideally restricted) and block the rest.
  • Brute-force protection such as fail2ban, and two-factor authentication on the panel.
  • Automatic security updates for the operating system.

Step 3: Create the site, database and user on the new server

Create the site in your panel with the same PHP version as the old host (or newer, after checking plugin compatibility), then a fresh database and user with a strong password. Use a separate system user per site so one compromised site cannot read another.

Step 4: Copy files and the database

  • Upload files with rsync or scp (much faster and more reliable than a browser file manager) into the new site’s web root.
  • Import the database dump (for example with mysql or wp db import).
  • Edit wp-config.php with the new database name, user and password, and check the table prefix matches what is in the database.
  • Fix file ownership and permissions so the site user owns its files.

Step 5: Test on the new server before touching DNS

This is what makes “no downtime” possible. Edit the hosts file on your own computer so your browser resolves your domain to the new server’s IP while everyone else still sees the old site. Then click through the home page, an article, forms, login, search, checkout (if any) and check for mixed-content or broken-image warnings. Fix problems now, while nobody is affected.

If the domain or the folder path changed, run a database search-replace for the old values. Page builders such as Elementor store URLs inside JSON, where slashes are escaped (https://example.com), so search for that form too, or some links will keep pointing to the wrong address.

Step 6: Lower the DNS TTL, then switch

  1. A day before the switch, lower the TTL on your A records (for example to 300 seconds) so the change spreads quickly.
  2. Do a final sync of files and database right before switching, especially for busy sites, shops and comment-heavy blogs, so no recent orders or comments are lost.
  3. Change the A records (and AAAA if used) to the new server. Leave MX and other mail records exactly as they were.
  4. SSL: a standard Let’s Encrypt certificate needs the domain to point at the server, so request it right after the switch (a few minutes) or use the DNS challenge to issue it beforehand.

Step 7: Verify, then verify again

  • Check that the site loads over HTTPS on both the bare and www addresses and that one redirects cleanly to the other.
  • Test your contact forms and that email still works in both directions.
  • Switch WP-Cron to a real system cron job so scheduled posts and tasks run on time without depending on visitors.
  • In Google Search Console, confirm the sitemap still loads and watch the coverage and crawl reports for new errors. If your URLs have not changed, your rankings should not either.

Step 8: Set up backups and monitoring (and test a restore)

A server without tested backups is a risk, not an upgrade. I use an encrypted, deduplicated backup tool (restic) that runs nightly and copies to cloud storage, and then I actually restored a site from it to prove the backup works. Add an uptime monitor with alerts, and keep the old hosting account for a few days as a fallback. Take a last backup of it before you cancel.

Mistakes I made (so you do not have to)

1. A redirect loop between www and non-www

The server redirected one version to the other, but WordPress was configured with the opposite address in its Home and Site URL settings, so each tried to send the visitor back. The fix is to set WordPress to your canonical address, search-replace the database (including the JSON-escaped form), and clear caches.

2. A cache exclusion rule that silently did not match

A path exclusion without regular-expression delimiters did nothing, and a logged-in admin toolbar ended up inside a cached page. Always view the source of a cached page as a logged-out visitor after configuring caching.

3. Removing “old” PHP versions on a server with a control panel

While tidying up, I ran a package purge for old PHP versions. The panel itself depended on those packages, so the purge started removing the panel and stopped the web server and database. The sites were down for about six minutes until I restarted the services and cancelled the removal. The lesson: control panels often depend on several PHP versions, so never bulk-remove them, and read the package manager’s “these will be removed” list before you confirm.

4. Forgetting that the new server cannot send mail the way the old one did

Many VPS providers restrict outgoing mail, and mail sent from an unauthenticated server is rejected by providers like Gmail. Set up SPF (and ideally DKIM and DMARC) for the domain, or send through an authenticated SMTP service.

Quick checklist

Stage Done when
Backup Full backup on your computer; DNS records written down
Harden SSH keys, firewall, fail2ban, panel 2FA
Copy Files, database and wp-config working on the new server
Test Whole site checked via hosts file
Switch TTL lowered, final sync done, A records changed, SSL issued
Verify HTTPS, redirects, forms, email, cron, Search Console OK
Protect Nightly encrypted backups, restore tested, uptime alerts

Need help with this on your own site?

I work with businesses and creators on WordPress performance, technical SEO, hosting migrations and monetisation. If you would rather have an experienced person do it (or review what you have done), send me a message with your website address and what you want to achieve, and I will tell you honestly what I would change first.

Frequently asked questions

Will migrating to a VPS hurt my SEO?

Not if your URLs, redirects and content stay the same and the site is not down for long. A faster server often helps. Keep an eye on Search Console for a couple of weeks.

How long does DNS propagation take?

If you lowered the TTL ahead of time, most visitors see the new server within minutes to a few hours. Some resolvers cache longer, which is why you keep the old host running for a few days.

Can I use a migration plugin instead?

Yes, plugins can move small sites, but large sites often time out. The manual method above is more reliable and teaches you what is where.

Do I need a server panel?

No, but a panel makes sites, databases, SSL and backups much easier to manage if you are not a full-time system administrator.

How long does a migration take?

For a small site, a few hours of work plus a waiting period for DNS. Hardening and setting up backups add time, but they are what make the server safe to keep.

Sources and further reading

How this article was written

I wrote this from hands-on experience with my own websites. Technical details were checked against the official documentation linked above in October 2026. Tools, policies and prices change, so if you notice something out of date, email info@saizul.com and I will correct it. Results mentioned are from my own sites and will vary on yours.

NEW BLOGS. REAL STRATEGIES. REAL RESULTS.

Join our community and receive powerful SEO tips, web optimization guides, and growth strategies as soon as they’re published.

Don’t just read blogs — stay ahead of the competition.

We don’t spam! Read our privacy policy for more info.

Check your inbox or spam folder to confirm your subscription.

Share.

Related Articles

Leave A Reply

Exit mobile version