Moving From Shared cPanel Hosting to a VPS: A Practical Guide

Your shared hosting account keeps throttling you at peak traffic, or WHM support keeps mentioning "resource limits" whenever the site slows down. The usual next step is a VPS — but a VPS isn't just a bigger shared account. There's no cPanel automation waiting for you on the other side unless you set it up yourself, and that trips up a lot of people mid-move. Here's how to do it without losing mail or taking the site down.

Why This Move Is Different From a Normal Migration

If you've ever moved a WordPress site between two shared hosting accounts, you know the drill: zip the files, export the database, import both, update the domain, done. Moving off shared cPanel hosting onto a VPS breaks that pattern in three ways:

• No source-side root access. You can't SSH into your old shared account and run a clean pkgacct export the way WHM's Transfer Tool would between two cPanel servers — you're stuck with cPanel's own backup and File Manager tools.
• No destination-side automation. A bare VPS has no web server, no PHP, no mail server, and no control panel installed unless you put one there. You're either installing a panel (like our managed cPanel VPS images) or hand-rolling a LEMP/LAMP stack.
• Email doesn't come along for free. On shared hosting, cPanel quietly runs Exim and Dovecot for you. On a fresh VPS, there's nothing listening on port 25 until you build it — or decide not to and route mail elsewhere.

Step 1: Get a Clean Export From cPanel

In your current cPanel account, go to Files > Backup (or Backup Wizard) and generate a full account backup. If cPanel lets you, download it in pieces — homedir.tar.gz, the MySQL dumps, and the email accounts separately — rather than one giant archive. It's easier to work with on the other end and easier to retry if one piece fails partway through a slow download.

If your host caps backup size or disables full backups on shared plans, fall back to:

• File Manager → select public_html → Compress → download the zip.
• phpMyAdmin → Export → SQL format, one file per database.
• Email Accounts → note down every mailbox and its size; large mailboxes need a proper IMAP-to-IMAP sync later, not a file copy.

Step 2: Build the VPS Environment First

Don't restore anything until the server can actually run your site. At minimum you need a web server, PHP with the right extensions, and a database engine matching the version your site was built against — an old WordPress install exported from PHP 7.4 will throw fatal errors on a VPS running PHP 8.3 with strict defaults.

If you'd rather not manage any of that by hand, a cPanel-licensed VPS gets you the same interface you're used to, just with dedicated resources behind it — the migration steps below are the same either way.

Step 3: Move the Database and Files

Upload the archive to the VPS with scp or rsync, then extract:

scp public_html.tar.gz user@your-vps-ip:/home/user/
ssh user@your-vps-ip
tar -xzf public_html.tar.gz -C /var/www/yoursite/

Create the database and import the dump:

mysql -u root -p -e "CREATE DATABASE sitedb; CREATE USER 'siteuser'@'localhost' IDENTIFIED BY 'strong-password'; GRANT ALL ON sitedb.* TO 'siteuser'@'localhost';"
mysql -u root -p sitedb < sitedb.sql

Update wp-config.php (or your app's config file) with the new database name, user, and password. If the old host used a table prefix other than wp_, double-check it matches — a mismatched prefix is the single most common cause of a blank homepage after this kind of move.

Fix file ownership before testing anything, or PHP will throw permission errors on uploads and cache writes:

chown -R www-data:www-data /var/www/yoursite/
find /var/www/yoursite/ -type d -exec chmod 755 {} \;
find /var/www/yoursite/ -type f -exec chmod 644 {} \;

Step 4: Decide Where Email Lives Now

This is the step people skip and regret. On shared cPanel hosting, mailboxes and the website share one server. On a VPS you have three real options:

1. Self-host mail on the VPS (Postfix + Dovecot) — full control, but you own spam filtering, blacklist monitoring, and PTR records. Only worth it if you already run other mail infrastructure.
2. Move mail to Google Workspace or Zoho Mail — the most common choice. Decouples mail from your web server entirely, so a future server migration never touches email again.
3. Keep mail on the old shared account temporarily by pointing only the A record to the VPS and leaving MX records untouched — buys you time to migrate mailboxes properly later.

Whichever you pick, do it before the DNS cutover in Step 5, not after — changing MX records is what actually controls where new mail lands, and doing it in a rush after the website is already live is how messages get lost mid-transition.

Step 5: Cut Over DNS Without Downtime

A few days before the move, lower the TTL on your A record (and MX, if it's changing) to 300 seconds so the eventual switch propagates fast instead of sitting cached for 24+ hours.

Test the site on the new VPS before touching DNS at all, by editing your local hosts file:

# /etc/hosts (Mac/Linux) or C:\Windows\System32\drivers\etc\hosts (Windows)
203.0.113.10   yourdomain.com www.yourdomain.com

Browse the site with that override in place — check forms, logins, and the checkout flow if it's a store. Once it's clean, update the A record at your DNS provider (or in Getwebup's DNS Zone Editor) and remove the hosts file entry. Keep the old shared hosting account active for 24-48 hours after the switch as a safety net; don't cancel it the same day.

Common Pitfalls That Break Sites Mid-Move

• Hardcoded URLs in the database. If the old site used http:// or a subdomain path, run a search-replace on the database before going live: wp search-replace 'http://olddomain.com' 'https://yourdomain.com' --all-tables for WordPress, or the equivalent for your CMS.
• .htaccess rules that don't translate. If you're moving to Nginx, Apache's .htaccess rewrite rules do nothing — they need to be rewritten as Nginx location blocks, or you keep Apache on the VPS to avoid the conversion entirely.
• Missing PHP extensions. A blank white screen after import is almost always a missing extension, not a code bug. Check php -m against what the plugin/theme docs require.
• Forgotten cron jobs. WP-Cron workarounds, report generators, and backup scripts that ran quietly under cPanel's Cron UI need to be re-added by hand — they don't come across in a files-and-database backup.

Prevention: Make the Next Move Easier

Once you're settled on the VPS, a few habits pay off the next time you need to move (new server, disaster recovery, or scaling to a second box):

• Keep infrastructure-as-code notes — even a plain text file listing installed PHP extensions, cron entries, and vhost configs saves hours later.
• Automate off-site backups with mysqldump and rclone on a schedule, rather than relying on manual exports.
• If you self-host mail, monitor your IP's blacklist status regularly — a fresh VPS IP can occasionally start out flagged.
• Document your DNS records somewhere outside the DNS provider itself, so a future migration doesn't start with "what MX records did we have again?"