How to Migrate WordPress to VPS Hosting with CloudPanel

Prices checked Oct 31, 2026Hands-on tested Oct 31, 2026Updated Oct 31, 2026

FindNChoose is reader-supported. Some links may earn us a commission at no cost to you; it never changes our verdicts. How we make money · How we test

What we actually did

We moved FindNChoose from Hostinger shared hosting to our own VPS (Ubuntu 24.04 with CloudPanel, nginx, PHP 8.3 and MySQL) in October 2026. Because we were rebuilding the site from scratch, we did a fresh WordPress install plus a content import rather than copying the old database. The steps for copying an existing database are included below and marked clearly; they are the standard WP-CLI steps, and we did not need them for this move. We have left out our server IP addresses, usernames and passwords.

Before you migrate WordPress to VPS hosting: is it right for you?

A VPS gives you dedicated memory and CPU, root access and full control over caching, which is why we moved. It also makes you responsible for updates, backups and security. If you are not sure, read shared hosting vs VPS and managed vs unmanaged VPS. For memory, our WordPress RAM test shows that a small site uses far less than most people expect, and the VPS sizing calculator helps you pick a plan.

What you need

A VPS with Ubuntu or Debian and CloudPanel installed. Many providers, including Hostinger, offer CloudPanel as a one-click template; see our Hostinger VPS review and CloudPanel review.
SSH access with a key, not a password.
Access to your domain’s DNS.
WP-CLI on the server (CloudPanel includes it).
A full backup of the old site: files and database.

Step 1: Create the site and database in CloudPanel

In CloudPanel, add a new WordPress or PHP site for your domain. CloudPanel creates a separate Linux user, a PHP-FPM pool and an nginx virtual host for it. We used the command-line tool clpctl so every step was scripted and repeatable:

clpctl site:add:php --domainName=example.com --phpVersion=8.3 \
  --vhostTemplate='WordPress' --siteUser=example --siteUserPassword='...'
clpctl db:add --domainName=example.com --databaseName=exdb \
  --databaseUserName=exdb --databaseUserPassword='...'

Use long, random passwords and store them somewhere safe, never in your website’s files or Git repository.

Step 2: Set up a hidden staging address

Do not point your real domain at the VPS yet. Instead, create a temporary subdomain (for example, new.example.com) with its own DNS record pointing to the VPS, and build there. We set our staging site to “discourage search engines” and added a noindex header, so nothing was indexed twice.

Step 3: Move WordPress

Option A: fresh install and content import (what we did)

Because the old site was a different project, we installed a clean WordPress with WP-CLI, installed only the plugins we needed (Rank Math, Cache Enabler, Redis Object Cache and Contact Form 7), and imported our articles from version-controlled files. This leaves behind years of unused plugins, tables and settings.

wp core download
wp config create --dbname=exdb --dbuser=exdb --dbpass='...' --dbhost=127.0.0.1
wp core install --url=https://new.example.com --title="Example" \
  --admin_user=... --admin_password='...' --admin_email=...
wp option update permalink_structure "/%postname%/"

Option B: copy an existing site (the standard method)

If you want an exact copy of an existing site, these are the usual steps. We did not need them for our rebuild, so treat them as a checklist rather than a log.

On the old host, export the database: wp db export site.sql (or use phpMyAdmin or the host’s backup tool).
Download wp-content (themes, plugins and uploads). On shared hosting this is usually a zip from the file manager; with SSH, use rsync.
On the VPS, install WordPress core as in option A, then copy wp-content into the site folder and fix ownership so the site user owns the files.
Import the database: wp db import site.sql, and set the same table prefix in wp-config.php.
Replace the URL for staging: wp search-replace 'https://example.com' 'https://new.example.com' --all-tables.
Flush caches and permalinks: wp cache flush and wp rewrite flush.

Never edit URLs in a database dump with a text editor. WordPress stores some settings as serialized data, and changing lengths by hand breaks them. WP-CLI’s search-replace handles this correctly.

Step 4: Harden and tune before launch

These are the settings we applied on the VPS before switching traffic:

Limit revisions (WP_POST_REVISIONS set to 10) to keep the database small.
Disable the file editor in wp-admin (DISALLOW_FILE_EDIT).
Automatic minor core updates only.
Redis object cache with its own database number and key prefix, so it never collides with other sites on the same server.
Page caching with Cache Enabler. We measured the difference in WordPress caching on a VPS.
Closed comments and pingbacks, because our site does not use them.

Step 5: Test on staging

Before launch, we checked every page, the sitemap, structured data, forms and mobile layout on the staging address. Things to test:

All important pages load with a 200 status and no PHP errors.
Forms send email.
Images and downloads load from the new server, not the old one.
wp-admin login works and plugins are active.

Step 6: Launch: DNS, SSL and the real URL

Back up the database on the VPS: wp db export.
Save a snapshot of the DNS zone, then change the A and AAAA records for the root domain and www to the VPS. Leave the MX, SPF, DKIM and DMARC records as they are. Details in how to point a domain to your hosting.
Issue the certificate once DNS resolves to the VPS. With CloudPanel: clpctl lets-encrypt:install:certificate --domainName=example.com --subjectAlternativeName=www.example.com.
Switch WordPress to the real URL: wp search-replace 'https://new.example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=user_email.
Allow indexing (wp option update blog_public 1), then flush the object and page caches.
Turn the staging host into a 301 redirect to the live domain, so any stray links still work.

Step 7: Keep a rollback

We left the old shared-hosting site in place and kept the DNS snapshot. If anything had gone wrong, restoring the snapshot would have sent visitors back to the old site within the TTL. Once the new site has run cleanly for a while, you can cancel the old hosting.

Mistakes we avoided (and you should too)

Building on the live domain. A half-finished site on your real domain can be crawled and indexed. Build on a hidden staging host instead.
Letting sites share one Redis cache. On a server with several sites, give each WordPress install its own Redis database number and key prefix, as we did.
Running search-replace without a backup. We exported the database right before switching the URL, so any mistake could be undone in seconds.
Issuing SSL before DNS points to the server. Let’s Encrypt cannot validate a domain that still resolves to the old host.
Cancelling the old hosting on launch day. Keep it until you are sure the new site is working.

After the move: what changes for you

Task	On shared hosting	On your VPS
Operating system updates	Done by the host	Your job (or enable unattended security updates)
Backups	Host’s backups	Your job: database dumps plus provider snapshots
SSL renewals	Automatic	Automatic with CloudPanel’s Let’s Encrypt
Caching	Host’s cache	Your choice: Redis and a page cache
Monitoring	Basic	Your job: uptime checks and log review

Frequently asked questions

How long does it take to migrate WordPress to a VPS?

For a small site, a few hours of work, plus waiting for DNS. Setting up the server and testing on staging take most of the time; the DNS switch itself takes minutes when TTLs are low.

Will I lose SEO rankings when I move to a VPS?

Not if the domain and URLs stay the same, the site returns the same content, and you avoid downtime. Search engines see the same pages at the same addresses, just served from a different server.

Do I need a migration plugin?

No. With SSH and WP-CLI, exporting and importing the database and copying wp-content is reliable and free. Migration plugins are handy on hosts without SSH access, but they can fail on large sites.

What happens to my email when I move WordPress to a VPS?

Nothing, as long as you only change the website records (A, AAAA and www) and keep the MX, SPF, DKIM and DMARC records. Email is usually hosted separately from the website.

Is CloudPanel free?

Yes, CloudPanel itself is free to use. You pay only for the VPS. See our CloudPanel review for what it does and does not cover.

Sources

FindNChoose Editorial Team

We run our own WordPress sites on shared hosting and on a VPS, and use AI coding tools every day. We publish what we measured, list every price with the date we checked it and label anything we have not tested ourselves. About us · Editorial policy