WHM Migrations on RHEL 9 for Managed Hosting

Move the account before the cutover, not after it

If you manage client sites on a Hostperl VPS or dedicated server, the safest approach to WHM migrations on RHEL 9 is simple: stage the destination first, keep the source online, and switch DNS only after the copy checks out. That keeps downtime low and avoids confusion during handover. For agency and regional workloads, a prepared destination on dedicated server hosting or a Hostperl VPS gives you room to verify the move before clients see any change.

This guide uses RHEL 9 and WHM on purpose. The same process works on AlmaLinux and Rocky Linux on the server side, but the commands below assume a RHEL-compatible destination with cPanel/WHM already licensed and reachable. If you are moving from an older managed environment, keep both servers online until the final sync passes verification.

What you need before you start

Gather these items before you touch DNS or disable the old account:

• A working WHM login on the destination server.
• Root SSH access to both source and destination.
• The account username, main domain, and current document root paths.
• Enough disk space for the copied home directory, mail, and databases.
• Access to the DNS provider for the final cutover.

If the source account handles a lot of mail, review DNS records for email deliverability in 2026 and SPF, DKIM, and DMARC for better email deliverability before the move. A clean migration can still lose mail if MX, SPF, DKIM, or DMARC are not preserved.

1) Connect to the destination server and confirm the OS

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

ssh root@203.0.113.10

Replace 203.0.113.10 with the public IP assigned to your server. This example address is reserved for documentation only.

On the VPS as root, confirm that you are on a RHEL-family system before you continue.

cat /etc/os-release

You should see ID="rhel", ID="almalinux", or ID="rocky"-style output. If you do not, stop here and use the matching guide for your platform.

2) Check WHM health and make a migration directory

On the VPS as root, create a clean working area for migration logs and artifacts.

mkdir -p /root/migrations/whm-account-2026

Then confirm WHM is reachable from the server itself. That helps you separate a panel issue from a network problem.

curl -kI https://127.0.0.1:2087

Successful output should return an HTTP status line, usually HTTP/1.1 200 OK or a redirect from the WHM login endpoint. If you get a connection refusal, cPanel services are not ready yet.

If you need a refresher on destination-server hardening before migration, see 2026 hosting buyer checklist for managed servers. It is not a migration guide, but it helps you spot missing baseline controls before clients arrive.

3) Verify the source account and list what must move

On the VPS as root, run a quick inventory on the source server so you know what needs to be copied.

ssh root@203.0.113.10 "whmapi1 accountsummary user=deploy"

Replace the username deploy with the actual cPanel account user on the source. Confirm the primary domain, package, and account state before you start the transfer.

Then capture the account’s main paths, databases, and mail domains.

ssh root@203.0.113.10 "ls -la /home/deploy && mysql --version && /usr/local/cpanel/bin/dcpumonview deploy"

Expect the home directory to exist, MySQL or MariaDB to respond, and the account to be active. If the account already shows corruption or missing files, fix that first. A migration copies problems too.

4) Run the cPanel transfer over SSH

For a managed-hosting move, the simplest safe path is WHM’s transfer tool. It keeps permissions, mail, databases, and most account metadata together.

On the VPS as root, open WHM in a browser and use Transfers > Transfer Tool. If you need to validate access from the shell first, use:

ssh root@203.0.113.10 "whmapi1 start_background_process command='ls /root'"

That command only proves background execution is working on the destination. The real transfer still happens in WHM.

Inside WHM, enter the source server IP, root credentials, and choose the accounts you want to copy. Keep the source live. Do not delete the original account yet. A clean managed migration usually ends with both systems online long enough for DNS and mail verification.

5) Confirm web, mail, and database services after the copy

On the VPS as root, check the destination services once the transfer completes.

systemctl status httpd cpanel exim dovecot mariadb --no-pager

On RHEL 9-based cPanel systems, you should see active services or clear evidence of what failed. If one service is down, do not cut over DNS yet.

Test the new site locally before any public switch. Replace deploy with the migrated account username.

curl -I --resolve example.com:443:203.0.113.10 https://example.com

This forces your client machine to hit the new server IP while still requesting the real hostname. A good result is an HTTPS response from the migrated account without certificate warnings.

If the site uses WordPress or another CMS, verify the application itself. For WordPress migrations, compare the post-move checks in WordPress migration on RHEL 9 without downtime to make sure URLs, uploads, and permalinks still work.

6) Validate DNS, SSL, and mail before cutover

On your local computer, inspect the live records before changing them. That keeps TTLs low enough for a controlled switchover.

dig example.com A +short

Then check mail records.

dig example.com MX +short

And confirm SPF.

dig example.com TXT +short

You are looking for the current production answers, not the new server yet. Lower the TTL first at the DNS provider if it is still high. Then switch the A record, and keep MX pointed where mail is actually being accepted.

If the destination needs a fresh certificate after the transfer, run a WHM SSL check from the panel, then validate from the shell:

curl -Iv https://example.com

Expect the certificate chain to match the domain and the new server. If you see a hostname mismatch, reissue or install the certificate before you promote the server.

7) Lock down the destination without locking yourself out

On the VPS as root, only make restrictive changes after the new account has been tested from a second terminal. Keep the original root session open.

First, check that the migrated site responds from the local host.

curl -I http://127.0.0.1

Then confirm your remote login path still works in a second SSH window.

ssh root@203.0.113.10

Only after that should you change any SSH or firewall policy. On RHEL 9 systems, cPanel often manages firewall behavior through its own stack, so review host access rules in WHM rather than dropping in generic Linux firewall edits that can interfere with the panel.

8) Clean up the source server after the final sync

On the VPS as root, use the source server for one more pass: compare recent changes since the transfer. Check uploads, mail queues, and database writes that happened during the migration window.

ssh root@203.0.113.10 "ls -lt /home/deploy/public_html | head && exim -bp | head && mysql -e 'SHOW DATABASES;'"

If you see recent content changes, do a final sync or schedule a brief maintenance window. When everything matches, archive the old account rather than deleting it immediately. That gives you a recovery point if the client reports a missed file or email later in the day.

For agencies handing accounts between teams, the workflow in agency handover on managed hosting covers ownership changes, access control, and the kind of documentation that prevents repeated support tickets after migration.

Verification checklist

Run these checks after DNS has propagated and before you close the ticket:

• WHM login: sign in to the new server and open the account in cPanel.
• HTTP and HTTPS: load the site from a browser and with curl -Iv https://example.com.
• Mail: send one inbound and one outbound test message.
• Databases: confirm the application can connect and read/write.
• Logs: review Apache, Exim, and cPanel logs for fresh errors.
• Reboot check: restart the server during a maintenance window and confirm WHM, mail, and the site return automatically.

Troubleshooting the most common migration failures

1. The transfer finishes, but the site is blank.
Run:

tail -n 50 /usr/local/apache/logs/error_log

If the clue is a PHP handler or permission error, fix ownership under /home/deploy and retest the virtual host.

2. Mail stops after cutover.
Run:

exim -bp && tail -n 50 /var/log/exim_mainlog

If the queue grows or you see rejected recipients, confirm MX records and local delivery settings before retrying.

3. SSL works in WHM but not in the browser.
Run:

openssl s_client -connect example.com:443 -servername example.com 

If the certificate chain or SNI name is wrong, reinstall the certificate for the exact hostname.

4. DNS still shows the old server.
Run:

dig example.com A +trace

If the trace ends at stale nameserver data, update the registrar and wait for propagation. Do not keep changing the record every few minutes.

FAQ

Should I migrate WHM accounts during business hours?

Only if the account is low traffic and the client has agreed to a controlled window. For busy stores or ticket-driven businesses, stage the copy first and cut over during the quietest local time.

Can I change DNS before the account copy is complete?

No. Keep the source live until the destination has passed web, mail, and database checks. Early DNS changes are the fastest way to create split-brain support tickets.

What should I keep from the old server after the move?

Keep the old account and logs long enough to catch delayed mail or a missed upload. Remove it only after the client confirms the new site is stable.

Is WHM migration enough for every account?

Usually, but custom cron jobs, external mail routing, and application-level caches still need manual review. A transfer tool copies the account; it does not replace validation.

For teams that want a cleaner long-term setup after the move, Hostperl also supports regional hosting workflows and service-led handover on the right platform size. That matters more than a quick copy when your clients expect uptime, clear ownership, and fast support.