Moving a cPanel site to a VPS

To move a cPanel site onto your own VPS, restore the old cPanel account on your new server in WHM. If you have root on both servers, use WHM’s Transfer Tool. If you do not, generate a Full Backup in cPanel on the old host, then restore that archive in WHM on the VPS. Test the restored site with a hosts file override, then switch DNS with a lowered TTL and set Email Routing correctly so mail flows to the right place.

This picks up from a server you can already reach over SSH. If you need to boot, reboot or open a console on your Hostworld VPS, do that first in Virtualizor from your Hostworld client area.

Before you start

• Operating system choice: cPanel & WHM supports AlmaLinux and Ubuntu. It does not support Debian. Check the current support matrix before you begin. See cPanel’s supported OS articles. Installing on an unsupported OS will not work.
• Clean install: use the official cPanel installer on a clean, supported OS. Installing conflicting services during installation will fail the process. See the cPanel installation guide.
• Root access on the source: if you have root or sudo on the source cPanel server, you can use WHM’s Transfer Tool. If the source is shared hosting and you only have a cPanel login, you will take a Full Backup in cPanel and restore it in WHM on the VPS.
• Only WHM can restore a Full Backup: cPanel’s Backup Wizard can generate a Full Backup, but it cannot restore one. The restore happens in WHM on the destination.
• Plan database versions: cPanel does not support downgrading MySQL or MariaDB. If your app needs an older database, you will need to upgrade the app or choose a supported DB version. Check the supported versions and plan upgrades, not downgrades.
• Schedule and DNS TTL: to cut over quickly, lower your DNS TTL in advance where your zone is currently hosted. You can do this in WHM’s “Set Zone Time to Live (TTL)” or per record in cPanel’s Zone Editor. Raise TTL again after the move.
• Email during the move: know where your MX records will point after migration. In cPanel, Email Routing should normally be “Automatically Detect Configuration”. A mismatch between Email Routing and MX records can stop inbound mail.
• SSL timing: AutoSSL needs domain control validation. Certificates will issue after the domain resolves to the new server or DNS DCV is satisfied. Expect warnings until then.
• Transfer Tool cautions: do not stop or restart services on either server during a transfer. Do not run it during a cPanel update or start an update while a transfer runs. Ensure TCP 2087 can connect from destination to source.
• Calendars and contacts: avoid transferring calendars/contacts from a server running v120+ to one running v118 or earlier.
• Backups matter: take off‑server backups before you change anything. Rebuilding a VPS will wipe the disk.

Step 1: Install cPanel & WHM on your VPS

Do this once on a clean, supported OS. The installer downloads the latest build and runs it. It configures the services WHM needs.

AlmaLinux and Ubuntu:

# As root. This downloads the 'latest' installer and runs it.
cd /home
curl -o latest -L https://securedownloads.cpanel.net/latest
sh latest

What the command does:

• cd /home switches to a safe working directory.
• curl -o latest -L … downloads the current installer to a file called “latest”, following redirects.
• sh latest executes the installer.

Let the installer finish. If it fails with messages about existing services, rebuild the VPS to a clean supported OS, then run it again.

Undo step: if you installed on the wrong OS or the install broke, rebuild the VPS in Virtualizor to a supported OS (AlmaLinux or Ubuntu), then repeat the install. Do not try to run cPanel on Debian.

Step 2: Plan DNS and email cutover

Lower TTL first so DNS switches quickly. If your DNS is on a cPanel server, in WHM use “Set Zone Time to Live (TTL)” or in cPanel use Zone Editor to reduce TTL for your domain’s records. Lowering TTL reduces how long resolvers cache the old IP. Plan to raise it again after you switch.

On the destination server, check cPanel’s Email Routing for your domain. Set it to “Automatically Detect Configuration” unless you have a specific requirement. This prevents inbound mail being misrouted when you switch MX records or A records.

Undo step: after the move and once traffic is stable, raise TTL back to your normal value in the same place you lowered it.

Step 3: Choose your migration method

• Transfer Tool (root on both): best when you have root or sudo on the source cPanel server. It copies accounts directly server‑to‑server, can recopy mailbox data, and can update DNS for you if you choose. Use this from WHM on the destination.
• Full Backup / cpmove archive (no root on source): best when the source is shared hosting and you only have a cPanel login. Generate a Full Backup in cPanel on the source, move the archive to the destination, restore it in WHM.

Step 4: If you have root on the source, use WHM’s Transfer Tool

1. On the destination WHM, open Transfer Tool. Provide the source server’s details. Ensure TCP port 2087 is reachable from destination to source. Do not run during a system update, and do not restart services while it runs.
2. Choose the account(s) to transfer. Decide whether to update DNS during the transfer. You can:
   • Enable Live Transfer to reduce downtime. This updates the account’s A record to the destination, may change nameserver entries to the destination, updates MX/mail routing when appropriate, proxies services during the move, re‑copies mailbox data, then suspends the source account. Only use Live Transfer when you are ready to move production traffic.
   • Or disable DNS updates to keep control of cutover. If you disable “Update DNS Zone” and then power off the source before creating zones on the destination, you may lose custom DNS records that only existed on the source. Create or export zones before you decommission anything.
3. Run the transfer. Watch for notices about MultiPHP: PHP‑FPM settings do not transfer. You will need to reconfigure PHP‑FPM and any required PHP settings on the destination after the move.

Undo step: if you triggered Live Transfer by mistake, reverse the DNS changes you just made so the domain resolves to the original IP again. Then unsuspend the source account in WHM on the source server. Only attempt a new transfer when you have a planned window.

Step 5: If you do not have root on the source, create a Full Backup in cPanel

1. Log in to cPanel on the old host and open Backup Wizard. Generate a Full Backup. This produces a .tar.gz archive. You can also use the main Backup interface to download the full archive.
2. Download the archive to your workstation or move it directly to the destination server. WHM can restore accepted filenames such as:
   • cpmove-{USER}.tar.gz
   • backup-{MM.DD.YYYY}_{HH-MM-SS}_{USER}.tar.gz
3. Place the archive on the destination server in one of the accepted directories, for example /home or /root.

Important: cPanel cannot restore a Full Backup. Only WHM on the destination can restore it.

Undo step: if you generated the wrong account’s backup or a corrupted file, discard it and create a new Full Backup in cPanel, then try again.

Step 6: Restore the archive in WHM

1. On the destination server’s WHM, open “Transfer or Restore a cPanel Account”. Choose “Restore from an archive”. Point it at the Full Backup you placed in /home or /root. WHM recognises archive names like cpmove-{USER}.tar.gz and the time‑stamped backup-… format.
2. In the restore options, decide how DNS A records should be handled. You can:
   • “Replace All Matching A Records” so all A records in the zone update to the new server’s IP.
   • Or replace only “cPanel‑provided A Records”. Choose the stricter option if you manually manage non‑web A records elsewhere.
3. Restricted Restore is enabled by default for security. It can cause parts of the account not to restore, for example parked or addon domains, and can leave the account in a broken state. If that happens, remove the partially restored account, then restore again with Restricted Restore disabled.
4. Complete the restore. When it finishes, log in to cPanel on the new server to verify files, databases and email accounts are present.

Command‑line alternative: WHM provides the restorepkg script.

# Restore by cpmove filename placed in /home or /root
/usr/local/cpanel/scripts/restorepkg cpmove-USERNAME.tar.gz

# Restore by username (requires the archive in an accepted directory)
/usr/local/cpanel/scripts/restorepkg USERNAME

# Restore to a specified IP if needed
/usr/local/cpanel/scripts/restorepkg --ip <NEW_IP> USERNAME

What these commands do:

• restorepkg unpacks a cPanel account archive and recreates the account on this server.
• You can pass the exact archive name, or a username. You can also set the target IP.

If you have shell access and root on the source and prefer to create a cpmove archive directly, use pkgacct there, then copy the archive and restore it on the destination:

# On the source server, create a cpmove archive for USERNAME
/usr/local/cpanel/scripts/pkgacct USERNAME

Undo step: if the restore produces errors or misconfigures DNS, remove the restored account in WHM, adjust the options, and restore again. Do not leave a half‑restored account in place.

Step 7: Preview the site on the new server before DNS switch

Edit your local hosts file to point the domain at the new server’s IP. This overrides DNS only for your computer so you can verify the restored site in place. Follow cPanel’s hosts file guidance for your operating system.

Add a temporary line in the format:

203.0.113.10   yourdomain.example   www.yourdomain.example

Then browse the site, including logins and forms. Check PHP pages, images, and any subdomains you restored.

Undo step: remove the line from your hosts file when you finish testing, then flush your browser cache.

Step 8: Cut over DNS and handle email

1. When you are satisfied, update DNS so the domain resolves to the new VPS. If you control the zone in cPanel or WHM, update the A and AAAA records for your domain and any subdomains to the VPS IP. Update MX and related mail records if you are moving mail to the new server. If you used Live Transfer earlier, DNS may already point at the destination.
2. In cPanel on the destination, open Email Routing and choose “Automatically Detect Configuration” unless you intentionally use Remote or Backup. A mismatch here can interrupt inbound mail delivery.
3. Monitor delivery. If messages bounce or SPF/DKIM fail, use Email Deliverability in cPanel or WHM to identify and correct DNS problems, including SPF and DKIM.

Undo step: if the switch causes an outage, revert the A and MX records to their previous values while you investigate. Keep the TTL low until you are ready to switch again, then raise it back to normal after success.

Step 9: Recheck SSL, PHP and application settings

• AutoSSL: after DNS resolves to the new server, AutoSSL will attempt DCV and issue certificates. If it fails you will see notices about domains failing DCV. Wait for DNS to resolve to the new server or satisfy DNS DCV, then retry. Do not force HTTPS until certificates are valid.
• PHP: MultiPHP users’ PHP‑FPM settings do not transfer. Re‑enable PHP‑FPM and reapply any needed settings or version selections for your domain.
• Database: if the application fails due to database version differences, do not attempt a downgrade. Review the supported MySQL/MariaDB versions and upgrade the application or database appropriately. Always back up first.

Undo step: if an application breaks after a PHP setting change, return the PHP version or FPM setting to its previous value in MultiPHP. For SSL, if you enabled HTTPS but AutoSSL has not issued yet, disable forced HTTPS temporarily until DCV passes.

Step 10: Decommission the old hosting safely

• If you used Live Transfer, the source account is suspended. Leave both environments in place for a short period to catch stragglers during DNS propagation, then remove the old account and cancel the old service when you are confident.
• If you disabled “Update DNS Zone” earlier, ensure the DNS zone exists on the destination before you power off the source so you do not lose custom records.
• Keep an off‑server backup of the new VPS before you make final changes.

Undo step: if you need to roll back, point DNS A and MX records back to the old server’s IP and unsuspend the old account if it was suspended. Re‑lower TTL, then plan a new cutover window.

What next

If you want a deeper dive on server tasks, browse our VPS guides. If you are still deciding on capacity or location for a new build, see our Linux VPS page.

If you get stuck at any point, open a support ticket so we can help from the Hostworld side.