WHM Account Transfer on AlmaLinux with Zero Downtime

When to use a WHM account transfer

A WHM account transfer is the simplest way to move a cPanel account between servers when you want to keep downtime short and avoid copying files by hand. On AlmaLinux and Rocky Linux, it works well for production migrations because WHM packages the account, restores it on the destination server, and preserves ownership, permissions, and service settings.

This guide walks you through a full cutover, from the first SSH login to final verification. It assumes the destination server runs AlmaLinux or Rocky Linux with WHM/cPanel installed, and that you have root access on both servers. If you are planning a live client migration, Hostperl VPS hosting and dedicated server hosting both give you the control you need for this kind of work.

You will use the example server IP 203.0.113.10 in the commands below. Replace it with the real public IP assigned to your server before you run anything.

Confirm the server OS and prepare access

On your local computer, start with the SSH connection to the destination server.

ssh root@203.0.113.10

This reserved documentation IP is only an example. Replace 203.0.113.10 with the public IP of your AlmaLinux or Rocky Linux server. If your provider uses a non-root SSH account, connect with that account first and then elevate with sudo.

On the VPS as root, confirm the operating system before you touch any package or firewall settings.

cat /etc/os-release

You should see AlmaLinux or Rocky Linux in the output. If you are not on a RHEL-compatible system, stop here and use the matching procedure for your platform.

Update the server and install the tools you will need for verification.

dnf update -y

dnf install -y curl rsync policycoreutils-python-utils

This refreshes packages and adds a few utilities that help with diagnostics and SELinux checks. The install should complete without errors.

Set up a non-root admin account before the cutover

If you are working on a fresh server, create a separate admin account and keep your root session open until the new login is confirmed. That lowers the risk of locking yourself out during the migration.

useradd -m -G wheel deploy
passwd deploy

The deploy account is the example non-root administrator used throughout this tutorial. Replace it only if your team uses a different convention. After setting the password, open a second terminal and test SSH.

ssh deploy@203.0.113.10

Now verify sudo access from the second session.

sudo -v
sudo whoami

If sudo works, you can proceed. Keep the original root session open until the migration is finished and the account has been tested end to end.

Check WHM transfer requirements on both servers

Before you start the migration, make sure the source server allows SSH access from the destination and that the cPanel account size fits your maintenance window. For larger sites, schedule the transfer outside peak traffic hours and lower DNS TTL in advance.

If you want a clearer migration checklist around content and cutover timing, this WordPress migration checklist is useful even when the source site is not WordPress. If you are also cleaning up site logs after the move, the log-based crawlability guide helps with post-migration checks.

From the destination server, test basic connectivity to the source server over SSH, replacing the example source address with the real one.

ssh root@203.0.113.10 hostname

This command should return the hostname of the remote server. If it fails, fix network reachability, firewall rules, or SSH key access before continuing.

Run the WHM account transfer

Use WHM on the destination server to copy the account from the source. If you prefer the command-line equivalent in a support workflow, the WHM transfer tool still does the same job with far fewer manual steps than archive handling.

On the destination server as root, open the WHM transfer interface in the browser, or use WHM from your support desk workflow. The exact URL is usually https://203.0.113.10:2087 for the destination server, but replace the IP with your own.

Inside WHM, choose the account, start the transfer, and let the system package the home directory, databases, DNS data, and email accounts. If the transfer reports missing permissions or a package problem, pause and inspect the log before retrying.

From SSH, you can monitor activity while the transfer runs.

tail -f /var/cpanel/transfers/session.log

You should see progress messages as the account is copied and restored. If the transfer stops, this log usually shows the exact failing step.

Secure the destination server after restore

AlmaLinux and Rocky Linux commonly use firewalld and SELinux. Keep both in place unless you have a documented reason to change them. After the account lands, confirm that web, mail, and WHM-related services are listening as expected.

systemctl status httpd
systemctl status mariadb
systemctl status cpanel

These checks help you catch a failed service early. If one of them is inactive, review the service journal.

journalctl -u httpd -n 50 --no-pager
journalctl -u mariadb -n 50 --no-pager

If your migration includes a custom application or proxy on the same host, Hostperl’s Docker Compose health checks guide and rollback planning guide are useful references for the application layer around the panel-managed account.

Confirm firewall and SELinux state

For AlmaLinux and Rocky Linux, open only the ports you need. WHM/cPanel usually handles many service rules itself, but you still need to verify the host firewall.

firewall-cmd --list-all
getenforce

You should see public or your custom zone with the required services, and SELinux should usually report Enforcing. If a restore fails because of SELinux contexts, relabel the affected path rather than disabling SELinux.

restorecon -Rv /home

Use that command carefully. It is safe for standard cPanel home directories and often fixes post-restore access issues.

Switch DNS with a safe timing plan

Once the restored account works on the destination server, prepare the DNS cutover. Lower the authoritative TTL on the source zone before the move, then update the A record to the new server IP after the destination is verified.

Check the DNS record from your local machine or a monitoring host.

dig +short example.com A

You should see the new server IP after propagation begins. During the transition, keep the source server live so cached clients can still reach the old site until DNS settles.

If your account includes mail, verify SPF, DKIM, and DMARC after the transfer. For broader DNS and TLS repair work, this hosting visibility guide gives useful context on how DNS and server response shape search access.

Test the account from the browser and from the server

Do both a server-side and a client-side check. From the destination server, confirm that the site responds locally.

curl -I http://example.com

You should get an HTTP status line such as 200 OK or a redirect that matches your setup. Then check the site from your local computer in a browser and make sure the page loads without mixed-content or certificate warnings.

Review the account’s web and mail logs if something looks wrong.

tail -n 50 /usr/local/apache/logs/error_log
 tail -n 50 /var/log/maillog

These logs often reveal permission problems, missing PHP modules, or mail delivery issues that were not obvious during transfer.

Rollback plan if the cutover fails

Do not delete the source account until the destination is stable. If the new server fails after DNS changes, point the zone back to the source IP and restore the previous TTL if you lowered it.

Keep the source account frozen in its pre-cutover state for at least one full propagation window. That makes rollback fast and predictable. If you need to copy only changes made after the transfer, use a targeted rsync pass from the source to the destination for the changed content, then re-test the account before another cutover.

rsync -aHAX --delete root@203.0.113.10:/home/exampleuser/ /home/exampleuser/

Replace the example source IP and account path with your real values. Run this only when you are certain the destination should be brought back in sync.

Final verification checklist

Finish with a short but complete set of checks so you know the migration is truly done:

• WHM shows the account restored without warnings.
• The website responds with the expected HTTP status.
• PHP pages load and database-driven pages render normally.
• Email authentication records match the new server.
• Firewall, SELinux, and core services remain healthy after a reboot.

Test reboot persistence on the destination server before you close the change.

reboot

After the server comes back, reconnect with SSH and check service state again.

ssh root@203.0.113.10
systemctl status cpanel httpd mariadb

If the services return cleanly and the site still answers, the WHM account transfer is complete.

FAQ

Does WHM account transfer copy SSL certificates?

Usually yes, along with the account’s cPanel data and most service settings. Still verify the certificate chain and renewal status after the move.

Can I transfer while the site is live?

Yes, but reduce DNS TTL first and keep the source server online until propagation finishes. That reduces missed traffic during the switch.

What if the account uses a large database?

Schedule extra time for the restore and test database-driven pages after the transfer. Large imports can finish successfully while still exposing permission or timeout issues later.

Should I disable the old server right after the move?

No. Leave it available until you confirm the destination is stable, DNS has propagated, and mail delivery is working. Then decommission the source in a controlled way.

For teams that want a migration-ready home for cPanel workloads, Hostperl’s dedicated server hosting and VPS hosting provide a practical place to stage the next cutover with fewer surprises.