cPanel Account Migration on RHEL 9 Without Downtime
Before you start: what this tutorial covers
This guide walks you through a cPanel account migration to a RHEL 9 server with a controlled cutover, verification, and rollback plan. It is written for Hostperl customers moving a client site, an agency account, or a production mailbox set, not a sample lab setup.
Use this when you are moving one cPanel account to a new host, preparing a server handover, or consolidating accounts after a platform change. If your new server is a Hostperl VPS, the same method also fits launch work where uptime and support response matter. See Hostperl VPS for suitable server sizes when you are staging a migration.
You will build the destination, secure SSH access, move the account with WHM tooling, validate files and services, then switch DNS only after checks pass. For support teams and agencies, that order avoids the usual mistake of changing DNS before mail, PHP, or permissions are ready.
Scenario and cPanel account migration design
In this tutorial, the source server is an existing cPanel host and the destination is a fresh RHEL 9 server running WHM/cPanel. The goal is to move one production account with web, mail, and DNS data intact.
- Source: Existing cPanel server with the live account.
- Destination: RHEL 9 server with cPanel/WHM already licensed and installed.
- Cutover method: Copy the account first, test on a temporary hostname, then update DNS.
- Rollback method: Keep the source account active until DNS is confirmed and mail queues are clean.
This is not a panel comparison guide. It is a practical account move that fits real hosting operations, especially where a customer expects a short maintenance window and quick support if something odd appears after cutover.
1) Connect to the RHEL 9 destination and confirm the OS
On your local computer:
ssh root@203.0.113.10203.0.113.10 is a documentation example. Replace it with the real public IP assigned to your server.
Keep your source server session open in another terminal if you already have one. You will need both systems available during the transfer and verification.
On the VPS as root:
cat /etc/os-releaseConfirm that the destination is RHEL 9 or another RHEL-compatible release supported by your cPanel build. You should see the distribution name, version, and codename in the output.
2) Update the destination and make SSH safer
Before any migration, patch the destination so you are not copying an account onto an outdated system. This also lowers the chance that cPanel services fail mid-transfer because of pending package updates.
On the VPS as root:
dnf -y update
rebootRun the update, then reboot once the kernel and core libraries are current. After the reboot, reconnect with the same SSH command and continue.
If you prefer to work with a named admin user instead of root, create it now and keep the root session open until the new login works.
On the VPS as root:
useradd -m -G wheel deploy
passwd deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh
cat > /home/deploy/.ssh/authorized_keys <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyReplaceThisWithYourRealPublicKey deploy@laptop
EOF
chmod 600 /home/deploy/.ssh/authorized_keys
chown -R deploy:deploy /home/deploy/.sshReplace the sample key with your real public key. Then open a second terminal on your local computer and test the new account before changing any root login rules.
On your local computer:
ssh deploy@203.0.113.10After login, test sudo access.
On the VPS as the non-root sudo user:
sudo -lYou should see that deploy can run sudo commands. Only after this succeeds should you consider disabling password SSH or root login.
If firewalld is not yet configured, open SSH first and keep it that way until the migration is complete.
On the VPS as root:
systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --reload
firewall-cmd --list-servicesThis enables the firewall safely, allows SSH, reloads the rule set, and shows the active services. Do not close your current session until SSH from a second terminal still works.
3) Check cPanel/WHM readiness on the destination
The destination must already have cPanel/WHM installed and licensed. If your Hostperl setup is still plain RHEL 9, install cPanel first through your licensing workflow before you proceed. For agencies that handle recurring server changes, the checklist in 2026 Hosting Buyer Checklist for Managed Servers is useful for validating the base server before account work begins.
Confirm that WHM is reachable on the expected port and that the core services are up.
On the VPS as root:
systemctl status cpanel
ss -tulpn | grep -E ':(2087|2083)\b'Successful output should show cPanel services running and WHM listening on port 2087. If WHM is not up, fix that before attempting any transfer.
4) Prepare the source server for a clean copy
Before copying the account, check disk space, the account name, and whether mail queues or backup jobs are running. That helps you avoid mid-transfer surprises.
On the source server as root:
df -h
whmapi1 listaccts search=username searchtype=user | grep -A4 -B2 'username:'
doveadm who | head
/usr/sbin/exim -bpcReplace username with the actual cPanel account username. Confirm there is enough free space to pack and transfer the account. If the mail queue is unusually large, let it settle before migration.
If the site sends mail, review deliverability settings after the move. The DNS and mail-auth article DNS Records for Email Deliverability in 2026 is the right companion reference for SPF, DKIM, and DMARC after cutover.
5) Copy the account with WHM transfer tools
Use the WHM transfer function rather than copying files by hand. That keeps ownership, virtual host data, DNS zones, mailboxes, and permissions aligned. It also reduces the chance of a broken cPanel metadata tree.
From WHM, choose Transfer Tool and copy the source server account to the destination host. If you prefer the API path, use the transfer feature built into WHM. The exact route depends on your access model, but the rule is the same: move the account as a cPanel account, not as a raw tar archive.
After the transfer completes, inspect the account on the destination.
On the VPS as root:
whmapi1 listaccts search=username searchtype=user
ls -lah /home/username
cat /var/cpanel/users/usernameConfirm the account exists, the home directory is present, and the cPanel user file was created. If the destination name differs, adjust the username in every later command.
6) Validate web, mail, and DNS before cutover
Do not change DNS yet. First test the site using the destination server directly. The simplest method is to point your workstation at the new IP with a temporary hosts-file entry or a temporary test hostname.
If you already published a staging name, use that. If not, use a temporary hosts entry on your local computer and browse the site through the destination IP. Then confirm HTTP, HTTPS, and key mail services from the server itself.
On the VPS as root:
curl -I http://127.0.0.1
curl -Ik https://127.0.0.1
exim -bpc
dovecot -n | head -n 20You should see a valid web response, TLS output for HTTPS if the certificate was copied or reissued, and clean mail daemon settings. If HTTPS fails because the certificate is still tied to the old hostname, that is expected during pre-cutover testing; fix it after DNS points to the new host.
For sites where search visibility matters after migration, review the existing Hostperl guidance on technical SEO crawlability checks and answer engine SEO for hosting sites so the move does not accidentally break canonical URLs, robots rules, or schema.
7) Reissue or repair SSL on the new server
If the certificate did not move cleanly, issue a fresh Let’s Encrypt certificate from cPanel/WHM after the destination answers for the real domain. This is usually the cleanest approach after DNS propagation begins.
In WHM or the cPanel user interface, run AutoSSL for the account, then check certificate status again.
On the VPS as root:
openssl s_client -connect 127.0.0.1:443 -servername example.com You should see a certificate chain and no handshake error. Replace example.com with the real domain owned by the cPanel account.
If AutoSSL fails, check the domain points to the new IP and that ports 80 and 443 are open in firewalld.
On the VPS as root:
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-services8) Switch DNS only after server checks pass
When the account works on the destination, update the domain’s A and AAAA records at your DNS provider. If the domain uses the destination server as its authoritative nameserver, update the zone in WHM instead. Keep the old server online until you confirm the new records are live and cached mail has drained.
If your DNS and email work is handled through a separate control plane, keep the TTL low before the cutover. The smoother way to handle delivery after the switch is covered in SPF, DKIM, and DMARC for Better Email Deliverability.
After you update DNS, wait for propagation and test from a second network, not only from your own server.
On your local computer:
dig +short example.com A
dig +short example.com AAAA
curl -I https://example.comYou want to see the new server IP in the DNS answers and a valid HTTPS response from the browser-facing site.
9) Verify mail, databases, and application behavior
Once DNS points to the new host, test the user-facing features that customers actually notice: login, checkout, contact forms, and email sending. A migration is not finished until those work.
On the VPS as root:
mysqladmin ping
systemctl status mariadb
systemctl status httpd
systemctl status exim
dovecot statusThese checks confirm that the core services are active. If the site uses a PHP application, confirm the page loads and the admin login works. If it is WordPress or WooCommerce, clear any cache plugin or server cache before testing checkout.
For customers running stores, the operational side of this is similar to the advice in WooCommerce Checkout Reliability on Hostperl VPS, especially if you are moving the store during a quiet window and need payment and email to behave the same after the switch.
10) Set up rollback and post-migration monitoring
Do not delete or modify the source account immediately. Leave it intact until you are satisfied that traffic, mail, and cron jobs are all healthy on the destination.
If anything breaks, point DNS back to the old server, then compare logs and service settings. That is the clean rollback path.
On the source server as root:
tail -n 50 /var/log/exim_mainlog
tail -n 50 /usr/local/apache/logs/error_log
tail -n 50 /usr/local/cpanel/logs/error_logOn the destination server as root:
journalctl -u cpanel -n 50 --no-pager
journalctl -u firewalld -n 50 --no-pager
ss -tulpn | grep -E ':(80|443|25|587|143|993)\b'These commands show whether the panel, firewall, and listening ports are behaving as expected. If one service fails, the logs usually point straight to the cause.
Troubleshooting the most common failures
1. The site loads on IP but not on the domain.
dig +short example.com A
curl -I http://example.comIf the domain still resolves to the old server, the DNS record has not propagated or was changed in the wrong zone. Update the live authoritative zone and wait for TTL expiry.
2. HTTPS shows the wrong certificate.
openssl s_client -connect example.com:443 -servername example.comIf the certificate chain names the old host, run AutoSSL again in WHM after confirming the domain points to the new server and ports 80/443 are open.
3. Mail is delayed or rejected.
exim -bpc
mailq
tail -n 100 /var/log/exim_mainlogIf the queue is growing, inspect SPF, DKIM, and DMARC, then confirm the new server IP has the correct DNS records. The email deliverability article linked earlier covers the exact record set you should compare.
4. The account transfer finished but the site returns permission errors.
ls -ld /home/username /home/username/public_html
find /home/username -maxdepth 2 -type d -exec stat -c '%U:%G %a %n' {} \; | headReset ownership if needed. In cPanel migrations, the owner should match the account user, and the home path should not be root-owned.
Final checks before you close the old server
Run these checks from the destination and from a client connection. If they pass, you can schedule the old server for decommissioning or keep it as a fallback until the next maintenance cycle.
On the VPS as root:
systemctl is-enabled cpanel
systemctl is-active cpanel
firewall-cmd --state
crontab -u username -lOn your local computer:
curl -I https://example.com
curl -s https://example.com | head
nslookup example.comIf the checks are clean, keep monitoring logs for at least one more DNS cycle. Then archive the source system or repurpose it after you have a verified backup.
If you want a migration path that feels controlled rather than rushed, Hostperl can stage the destination server, handle WHM account movement, and help you keep the old host available until validation is complete. For hosting teams and agencies, a Hostperl VPS or a dedicated server hosting plan gives you room for clean cutovers and support-led recovery if anything needs attention.
Hostperl is a practical fit when the migration involves live customers, mail, and a deadline.
FAQ
Can I migrate a cPanel account while the site stays live?
Yes. Copy the account first, test it on the destination, then switch DNS only after the new server passes web, mail, and SSL checks. That keeps downtime small.
Should I keep the source server after the migration?
Keep it until DNS has propagated and you have confirmed the site, mail, and cron jobs are stable on the new server. It is your easiest rollback option.
Do I need to move the SSL certificate manually?
Not always. If AutoSSL can issue a fresh certificate after the DNS cutover, that is usually cleaner than trying to reuse the old one.
What if the destination is RHEL 9 but my source is not?
That is fine. cPanel migrations regularly move between different Linux distributions as long as the destination supports the cPanel version and services you need.
