There comes a point where shared hosting stops being the cheap, simple win it was when you launched. The problem is usually not that shared hosting is “bad”. It is that your site, application, or team now needs more control than a shared environment is built to give you. Maybe you need custom server packages, better isolation, predictable resources, or a deployment workflow that does not depend on a one-size-fits-all control panel.

The hard part is not deciding to move. It is moving without breaking email, corrupting data, or turning a routine upgrade into a weekend outage. We see this with growing businesses all the time. They know they need a Cloud VPS, but they delay the move because the migration feels risky.

This guide walks through a practical migration plan from shared hosting to a Cloud VPS. The goal is not to impress anyone with fancy tooling. It is to help you move cleanly, verify that everything works, and keep a rollback path if something goes sideways.

What you will need before you start

For a small business website, application, or WordPress workload that has outgrown shared hosting, we recommend starting with a Canadian Web Hosting Cloud VPS sized for your real workload rather than the bare minimum. For many migrations, a practical starting point is:

  • 2 vCPU
  • 4 GB RAM
  • 80+ GB SSD storage
  • Ubuntu 24.04 LTS
  • SSH access and sudo privileges

If you are moving an active production site and do not want your team handling the cutover alone, add Managed Support. If rollback and restore confidence matter more than shaving a few minutes off setup time, pair the new VPS with CloudSafe Backup.

Before the migration window, collect these essentials:

  • Current shared hosting login and cPanel access
  • DNS provider access
  • Database credentials
  • TLS certificate details or ACME plan
  • A clear list of cron jobs, email routing, and third-party integrations

If you are still deciding whether the upgrade is justified, read WordPress Performance: Shared vs VPS — When It’s Time to Upgrade and Canadian SMB Hosting Costs: The Real Numbers Across Shared, VPS, and Dedicated first. Those posts help with the business case. This one is the execution plan.

Step 1: Audit what actually needs to move

Many migrations get messy because the team starts copying files before they understand the workload. Make an inventory first. You need to know:

  • Which site or app directories matter
  • Which databases are live
  • Which scheduled jobs are business-critical
  • Which DNS records point to the old environment
  • Which email services are tied to the current host

This sounds basic, but it is where most migration surprises come from. A forgotten webhook endpoint, a cron-driven invoice export, or an old SMTP relay can break after cutover even when the main site loads fine.

For WordPress, a fast sanity check is to capture the active plugins, themes, uploads path, and database name before you touch anything:

wp plugin list
wp theme list
wp option get siteurl
wp db export pre-migration.sql

The wp db export command is documented by WP-CLI and uses the database credentials already defined in wp-config.php. That makes it a good fit for a quick export before you begin deeper migration work.

Step 2: Lower DNS TTL before cutover

Your goal is to shorten the cache window before you flip traffic to the VPS. DNS TTL controls how long resolvers cache a record. Cloudflare documents that TTL directly affects how long updates can take to reach users, and proxied records default to an auto TTL of 300 seconds.

If your DNS provider allows it, lower the TTL on the records you plan to move well before the cutover window. That does not make propagation instant, but it reduces the chance that half your users stay pointed at the old host for hours after you switch.

# Example planning note, not a shell command
www.example.com  A  300  NEW_VPS_IP
example.com      A  300  NEW_VPS_IP

Do this early enough that the shorter TTL has time to take effect before the actual move.

Step 3: Take backups you can actually use

Do not treat “there is a backup somewhere” as a migration plan. cPanel’s backup documentation confirms that full account backups can be generated as .tar.gz archives, but it also notes that full account restores are not automatically available from cPanel itself. In practice, that means you should know exactly how you would restore the data, not just assume the backup button solves everything.

For most migrations, we recommend taking more than one type of backup:

  • A full cPanel account backup for broad recovery coverage
  • A direct database export for fast, selective restore
  • A file-level copy of the web root for easy spot checks
# WordPress / MySQL export via WP-CLI
wp db export pre-migration.sql

# File-level sync to a safe location on the VPS
rsync -avz user@oldhost:/home/account/public_html/ /srv/www/example.com/

Rsync is especially useful because it works well for repeat transfers over SSH. That matters during migration: you can run one sync in advance, then a smaller final sync just before cutover instead of copying everything from scratch at the last minute.

If your business cannot tolerate a messy recovery, treat backup validation as mandatory. Open the SQL export. Confirm that the web root copy includes uploads and configuration files. Make sure someone on your team knows where the backups live.

Step 4: Build the VPS before you move traffic

The VPS should be fully prepared before public traffic touches it. That means the operating system is updated, packages are installed, your web stack is running, and the application is loading under a temporary host entry or test domain.

A simple preparation flow on Ubuntu looks like this:

sudo apt update && sudo apt upgrade -y
sudo apt install -y nginx php-fpm php-mysql mariadb-server rsync unzip
sudo systemctl enable --now nginx mariadb
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw enable

If you are moving a WordPress workload, install the PHP extensions your application actually needs instead of copying a random package list from an old tutorial. If you are moving a custom app, document the runtime versions up front so you do not discover a compatibility problem during cutover.

This is also where CWH’s flexibility starts to matter. On shared hosting, your environment is shaped around the platform. On a VPS, you shape the environment around the workload.

Step 5: Move files and database in two passes

The cleanest migrations separate preparation from cutover.

First pass: pre-stage the workload

Copy most of the site before the final maintenance window. That reduces pressure later.

rsync -avz --delete user@oldhost:/home/account/public_html/ /srv/www/example.com/
scp user@oldhost:/home/account/pre-migration.sql /srv/backups/

Import the database, update configuration files, and make sure the site loads locally on the VPS.

mysql -u root -p -e "CREATE DATABASE example_prod CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u root -p example_prod < /srv/backups/pre-migration.sql

Second pass: final delta sync

Right before cutover, place the old site into maintenance mode if possible, then run one last sync so you only move the remaining changes.

wp maintenance-mode activate
rsync -avz --delete user@oldhost:/home/account/public_html/ /srv/www/example.com/
wp maintenance-mode deactivate

If the application is not WordPress, use the equivalent read-only or maintenance workflow your platform supports.

Step 6: Verify before you flip DNS

Do not point the domain at the VPS just because the services started. Verification should cover at least:

  • Homepage and key landing pages
  • Application login
  • Forms, checkout, or ticket submission
  • Media uploads and file permissions
  • Cron jobs and outbound email
  • Redirects, SSL, and canonical URLs

A practical check sequence:

curl -I http://127.0.0.1
curl -I https://your-test-domain.example
sudo nginx -t
sudo systemctl status nginx php8.3-fpm mariadb --no-pager

If this is a WordPress migration, search for hard-coded URLs or file path assumptions before you go live. This is also a good time to review our guide on preventing SSL expiry outages so the move does not trade one operational problem for another.

Step 7: Cut over DNS and monitor closely

Once the site is verified, update the A or AAAA records to the new VPS. Then monitor the environment closely for the first few hours. Watch logs, not just uptime checks. A site can return 200 OK while still failing on login, media writes, or scheduled jobs.

sudo tail -f /var/log/nginx/access.log /var/log/nginx/error.log
sudo journalctl -u nginx -u php8.3-fpm -u mariadb -f

If your business depends on internal documentation and recovery runbooks, tie this migration into a broader continuity process. Our draft on Business Continuity Planning for SMBs: Start with Hosting is the natural next read. If you are rethinking architecture because users are spread across Canada, the draft Edge Computing for Canadian Businesses connects that next-stage discussion.

Production hardening after the move

Migration is only half the job. Once the VPS is live, harden it before the move fades into background noise.

Firewall and SSH

sudo ufw status
sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'

Restrict anything you do not need publicly reachable. If this workload is business-critical, consider pairing the server with CWH’s Firewall & VPN or Managed Security services.

HTTPS and certificates

Confirm that certificates are installed correctly and renewal is documented. Shared hosting often hides this operational work. VPS hosting puts it back in your hands, which is good for control but bad if you forget it.

Backups and rollback

Keep the old environment intact until you have passed a defined verification window. Do not cancel the shared account the same day you cut over. A short overlap gives you a rollback option if a forgotten dependency shows up after traffic is live.

Logs and monitoring

Turn on monitoring early. You want alerting for disk growth, service failures, and certificate issues before the first quiet failure becomes a customer problem.

Troubleshooting common migration problems

The site loads, but uploads fail

Usually this is a permissions or ownership mismatch after the file copy. Check the upload directory and your PHP-FPM user.

sudo chown -R www-data:www-data /srv/www/example.com
find /srv/www/example.com -type d -exec chmod 755 {} \;
find /srv/www/example.com -type f -exec chmod 644 {} \;

Pages load, but database errors appear

Confirm the VPS configuration matches the imported database credentials and that the target database actually exists.

grep DB_ /srv/www/example.com/wp-config.php
mysql -u root -p -e 'SHOW DATABASES;'

Traffic splits between old and new servers

That is often just DNS cache timing. Keep both environments stable during the TTL window. Do not make content changes in both places after cutover unless you have a controlled sync plan.

Conclusion: move with a plan, not a panic response

Moving from shared hosting to a Cloud VPS is not just a performance upgrade. It is an operations upgrade. You gain control, isolation, and room to grow, but only if the migration itself is structured. Audit first, lower DNS TTL, take backups you can actually restore, pre-stage the workload, verify before cutover, and keep a short rollback window after the switch.

If you want the flexibility of a VPS without owning every operational detail yourself, CWH Cloud VPS paired with Managed Support is the practical middle ground. You get the control that shared hosting cannot give you, with a support path when the migration or the next change window needs extra hands.