cPanel Account Transfer to a New Server with DNS Cutover

When to move a cPanel account this way

A cPanel account transfer fits best when you are moving one customer site, its mailboxes, and DNS zones to a new server without rebuilding the entire stack. This guide uses Debian 12 on the destination VPS and a controlled DNS cutover, so you can test the account before traffic moves over. If you are handling a wider migration or an agency handover, the same discipline applies as in agency handover workflows and in cPanel migration procedures on RHEL 9.

For this tutorial, the source server already has a working cPanel account, and the destination is a fresh Hostperl VPS. If you are choosing based on capacity, a Hostperl VPS is usually the right fit for small and medium cPanel workloads, while higher-traffic or multi-account transfers often belong on dedicated server hosting.

1) Connect to the destination server and confirm Debian

On your local computer, open an SSH session to the new server first.

ssh root@203.0.113.10

203.0.113.10 is a documentation example. Replace it with the real public IP assigned to your Hostperl server. Keep the original root session open until the new login and service checks succeed.

On the VPS as root, confirm the operating system before you install anything else.

cat /etc/os-release

You should see Debian 12 or Debian 13 details. This guide uses Debian-family commands on purpose, because package names, AppArmor, and the firewall workflow differ from RHEL-based systems.

2) Create the non-root admin user

On the VPS as root, create a sudo user named deploy, set an initial password, and add it to the sudo group.

adduser deploy
usermod -aG sudo deploy

You will be prompted to set the password during adduser. Use the deploy account for the rest of the work.

Now prepare SSH access for that user.

install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
cp /root/.ssh/authorized_keys /home/deploy/.ssh/authorized_keys
chown deploy:deploy /home/deploy/.ssh/authorized_keys
chmod 600 /home/deploy/.ssh/authorized_keys

If your provider gave you a key for root access, copying it here lets you test the new account without opening password SSH. Open a second terminal now.

On your local computer, test the new login.

ssh deploy@203.0.113.10

After you connect, run a sudo check.

sudo -v
pwd

You should be prompted for the deploy password and land in your home directory. Do not disable root access yet.

3) Update Debian and install the migration tools

On the VPS as the non-root sudo user, update the base system and install the tools you need for account transfer, archive inspection, and firewall control.

sudo apt update
sudo apt -y full-upgrade
sudo apt -y install rsync tar curl ufw ca-certificates

This keeps the destination current before you import customer data. Reboot if the kernel or libc changed.

sudo systemctl reboot

Reconnect as deploy after the server comes back. Then confirm time sync.

timedatectl status

Healthy time sync matters for TLS, mail headers, and log matching.

4) Prepare the destination server for cPanel support

cPanel itself runs on supported AlmaLinux, Rocky Linux, or CloudLinux hosts, so the destination in this tutorial is the Linux server that receives the account data before final cutover. That is why the transfer workflow is separate from the control-panel install. You validate the hosting path first, which is safer for customer handovers and easier to roll back if DNS has not moved yet.

On the VPS as the non-root sudo user, create a clean staging directory for the imported account.

sudo mkdir -p /opt/myapp
sudo chown deploy:deploy /opt/myapp

We are using /opt/myapp as a generic example path for the imported account staging area. If you already have a standard migration workspace, use that instead.

5) Export the cPanel account from the source server

On the source server as root, create the cPanel full backup. Replace exampleuser with the real cPanel username.

/scripts/pkgacct exampleuser /home

When this finishes, you will get an archive named something like cpmove-exampleuser.tar.gz in /home. Check that the file exists and note the size.

ls -lh /home/cpmove-exampleuser.tar.gz

If the account is large, make sure the source has enough free space for the archive. A failed package build is usually caused by disk pressure or an exhausted backup partition.

6) Transfer the backup safely to the destination

On the source server as root, copy the archive to the new server. Replace the example IP with your destination server IP.

rsync -avP /home/cpmove-exampleuser.tar.gz deploy@203.0.113.10:/home/deploy/

On the destination server as the non-root sudo user, confirm the file arrived intact.

ls -lh /home/deploy/cpmove-exampleuser.tar.gz
sha256sum /home/deploy/cpmove-exampleuser.tar.gz

If your source has an old checksum, compare it now. A bad transfer is rare, but it is cheaper to catch before import than after DNS cutover.

7) Restore and validate the account data

On the destination server as root, unpack the archive into the staging path and inspect the contents before you expose the site.

mkdir -p /root/cpanel-restore-check
cd /root/cpanel-restore-check
tar -xzf /home/deploy/cpmove-exampleuser.tar.gz
find . -maxdepth 2 -type f | head

You are checking for home directory data, databases, and mail structure. If the archive is corrupted, tar will stop with an error instead of silently importing broken content.

For a live cPanel restore onto a panel server, run the standard restore command on the cPanel host itself. If your destination is a fresh cPanel system, use the backup restore interface or the command-line restore tools provided by the panel. The sequence stays the same: validate the archive, restore it on the new server, and test before DNS moves.

8) Open the right firewall rules before exposing the site

On the destination server as the non-root sudo user, enable UFW only after the account is ready. Add the new rules before you close any old access path.

sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable
sudo ufw status numbered

This allows SSH, HTTP, and HTTPS. If the account uses mail on the same server, you will also need the mail ports used by your setup, but only open what the account actually needs.

For a live cPanel host, firewall policy is usually managed by the panel and its security tools. If you are hardening a destination Linux host before final provisioning, keep the rules minimal and auditable.

9) Test the site before changing DNS

On your local computer, point a browser or curl test at the new server IP using the site hostname in the Host header. Replace example.com with the real domain.

curl -I http://203.0.113.10 -H 'Host: example.com'

Success means the new server answers with a valid HTTP status such as 200, 301, or 302 depending on the site’s redirect rules. If you get the wrong page, check the document root and virtual host mapping on the destination.

On the destination server as root, check the most relevant logs if the site does not respond as expected.

journalctl -xe --no-pager | tail -n 50
ss -ltnp

The first command shows service errors. The second confirms whether the web server is listening on ports 80 and 443.

10) Move DNS with a low-risk cutover

Lower the DNS TTL on the source DNS zone before you switch the A record. A common safe value is 300 seconds the day before migration. Then update the record to the new server IP.

On the DNS provider or cPanel DNS zone editor, change the site’s A record from the old server to 203.0.113.10. After that, wait for propagation and keep both servers online until traffic clearly lands on the new host.

Use a public resolver check from your local computer.

dig example.com A +short
curl -I https://example.com

When the A record resolves to the new server and HTTPS answers normally, the cutover is complete.

11) Confirm mail, permissions, and account ownership

One of the most common post-transfer mistakes is broken ownership. Fix that immediately if the site or mail storage behaves strangely.

sudo find /home/exampleuser -not -user exampleuser -o -not -group exampleuser | head
sudo chown -R exampleuser:exampleuser /home/exampleuser

Replace exampleuser with the actual cPanel account username. If mail is part of the account, also check that mail directories and forwarders belong to the correct user and group.

For mail authentication, verify DNS records separately. The migration may be correct while email still fails because SPF, DKIM, or DMARC were not copied or published properly. Hostperl’s email deliverability guide shows the record-level checks that matter after a move.

12) Roll back safely if the cutover fails

If the site breaks after DNS moves, revert the A record to the old server immediately. That is the safest rollback because the original host is still intact.

dig example.com A +short
curl -I http://example.com

If DNS has already been updated elsewhere, lower the TTL further only if you still have the old server serving traffic. Do not delete the source account until you have at least one clean day of traffic, log review, and a final backup.

For a customer handover, keep a dated copy of the backup archive on both systems until the migration closes. That gives you a clean support path if someone reports a missing mailbox, broken image, or stale cache after launch.

Verification checklist

• ssh deploy@203.0.113.10 works from a second terminal.
• sudo -v succeeds for the new admin user.
• ufw status numbered shows SSH, HTTP, and HTTPS allowed.
• curl -I http://203.0.113.10 -H 'Host: example.com' returns a valid response.
• dig example.com A +short resolves to the new server IP.
• The site loads over HTTPS after DNS propagation.

Common failures and what to check

Backup archive will not restore: run ls -lh /home/deploy/cpmove-exampleuser.tar.gz and tar -tzf /home/deploy/cpmove-exampleuser.tar.gz | head. If either command errors, resend the archive from the source server.

SSH works but sudo fails: run id deploy. If the sudo group is missing, repeat usermod -aG sudo deploy and log in again.

Site resolves to the new host but returns the wrong page: check the document root and vhost mapping on the destination, then inspect journalctl -xe --no-pager for web server errors.

Mail stopped after migration: check SPF, DKIM, and DMARC on the new DNS zone, then confirm that the mail service is running and listening with ss -ltnp.

Final notes for production moves

A clean cPanel account transfer is mostly about sequencing: prepare access, verify the archive, restore on the new server, test before cutover, then move DNS with a rollback path. That is the same operational mindset Hostperl uses for customer migrations, whether the destination is a managed VPS hosting plan or a larger dedicated server hosting environment. If you are migrating multiple accounts for a client handover, the support pattern in managed hosting for agencies is a useful reference for communication and sign-off.

FAQ

Can I move a cPanel account without downtime?

You can usually keep downtime very low by restoring the account on the new server first, testing it, and then switching DNS only after the new host is ready.

Should I disable the old server before DNS changes?

No. Keep the source server online until DNS propagation is finished and you have confirmed the new server is serving the site correctly.

What should I check first if the restored site breaks?

Check file ownership, the document root, web server logs, and DNS. Those four items explain most migration issues.

Is Debian a good destination for this workflow?

Yes, for the Linux staging and validation steps in this tutorial. If you are running cPanel itself, the final control-panel host should use a supported cPanel OS.