Most migrations fail for boring reasons. A port is blocked, a resolver is stale, a DNS zone template is broken, or a restore runs out of space mid-stream. This cPanel account transfer troubleshooting tutorial gives you a repeatable checklist. Use it to diagnose WHM Transfer Tool failures, fix restore errors, and avoid post-cutover surprises (wrong server, SSL warnings, mail still landing on the old box).
The steps below assume you’re moving accounts between two cPanel/WHM servers (source → destination) on a VPS or dedicated server.
If you want fewer variables, start with a clean destination build on a HostMyCode VPS. If you’d rather offload baseline hardening and monitoring, choose managed VPS hosting.
What you’ll troubleshoot in this cPanel account transfer troubleshooting tutorial
- WHM Transfer Tool can’t connect (SSH/auth/firewall/name resolution)
- Transfers stall or time out (network, CPU steal, IO wait, rsync behavior)
- Restores fail (disk space, corrupted packages, RPM/EA4 mismatches)
- Sites resolve to the wrong server after cutover (DNS zones, glue, caching)
- SSL and AutoSSL issues after restore (DCV failures, wrong vhost, IPv6)
- Email routing surprises (local vs remote delivery, MX, rDNS/PTR)
Pre-flight: collect facts before you “fix” anything
Write down the basics first. You’ll move faster when you can correlate logs, SSH output, and DNS results.
- Source hostname, destination hostname, and their main IPs
- cPanel & WHM versions (both sides):
/usr/local/cpanel/cpanel -V - OS and kernel:
cat /etc/os-release,uname -r - Whether NAT is involved (common on some VPS networks)
- Which accounts fail and their approximate sizes (
/homeusage, mail usage)
On both servers, confirm hostname resolution is consistent:
getent hosts source.example.com
getent hosts dest.example.com
hostname -f
If resolution differs between servers, fix that first. Many “SSH connect” errors are resolver problems in disguise.
cPanel account transfer troubleshooting tutorial: fix “Unable to connect” and auth errors
WHM Transfer Tool runs over SSH. Before you touch WHM settings, prove SSH works from destination to source.
The connection should work cleanly, repeatedly, and without unexpected prompts.
1) Test SSH from destination to source
ssh -vvv root@source.example.comCommon failures and what they usually indicate:
- Timeout: a firewall/security group is blocking TCP/22, or source SSH is down.
- “No route to host”: wrong IP, routing issue, or provider-level filtering.
- “Host key verification failed”: known_hosts mismatch (common after a rebuild).
- “Permission denied”: wrong credentials, key not accepted, or root login disabled.
2) Validate SSH service and firewall rules on the source
ss -lntp | grep ':22'
systemctl status sshd
If you’re using CSF, confirm SSH isn’t being restricted by policy. Also confirm it’s allowed in your port lists:
csf -l | head
grep -E '^TCP_IN|^TCP_OUT' /etc/csf/csf.confIf the underlying OS uses UFW, allow SSH explicitly:
ufw status verbose
ufw allow 22/tcpFor a safe baseline that keeps SSH, DNS, and web traffic working, keep this open while you adjust rules: UFW firewall setup tutorial (2026).
3) Fix known_hosts conflicts (the clean way)
On the destination server (the one initiating SSH), remove the stale host key entry. Then reconnect and accept the new key:
ssh-keygen -R source.example.com
ssh-keygen -R 203.0.113.104) Root login disabled? Use a transfer key or a privileged user
Many servers block root SSH on purpose. Transfers still need root-level access to package and restore accounts.
Plan for that requirement early.
- Temporarily allow root SSH login during the transfer window (and revert immediately after).
- Use WHM’s recommended transfer method with keys and ensure the user can escalate as required (varies by policy).
If you’re hardening SSH as part of the move, use keys and keep a rollback path. This guide walks through the safe setup: SSH key setup guide tutorial (2026).
Transfers stall, crawl, or time out: diagnose network and IO bottlenecks
A “stuck” transfer often means the server is busy, not broken. Don’t restart the job until you’ve checked the basics.
1) Watch CPU, IO wait, and disk pressure
top
vmstat 1
iostat -xz 1- High %wa (IO wait) points to slow storage, a RAID rebuild, or a saturated disk.
- High load with low CPU can still be disk pressure.
- Swap thrash will drag out compression/extraction and trigger timeouts.
2) Check disk space on destination (this is the silent killer)
df -h
sudo du -sh /home /var /usr/local/cpanel 2>/dev/nullTransfers often run for hours and then fail during mail restore or home directory extraction.
The cause is frequently a full destination filesystem.
If you’re close to the limit, clean up first instead of “trying again.” This walkthrough helps: server storage cleanup tutorial (2026).
3) Confirm basic network quality between servers
ping -c 20 source.example.com
mtr -rwzbc 50 source.example.comWatch for packet loss and jitter spikes.
If loss is consistent, migrate in a quieter window. You can also ask your provider to check the route.
4) Avoid “one big transfer” when one account is the problem
One oversized account can make the whole batch look unreliable. Move it separately so you can tune and observe.
Start by checking file counts and likely hotspots:
sudo find /home/username -xdev -type f | wc -l
sudo du -sh /home/username/mail /home/username/public_html 2>/dev/nullRestore failures: find the real error and fix the cause
WHM’s “Restore failed” message is only a headline. The details live in the restore output and the cPanel logs.
1) Identify the restore log for the account
Start with restore-related logs on the destination:
ls -lt /usr/local/cpanel/logs | head
ls -lt /usr/local/cpanel/logs/restore* 2>/dev/null | head
Then check the main error log for the same time window:
tail -n 200 /usr/local/cpanel/logs/error_log2) Common restore errors and targeted fixes
- “No space left on device”: expand the filesystem, or clean space, then re-run restore.
- Permission/ownership issues: verify the destination doesn’t have hardened mount options or unexpected ACL behavior. Check:
mount | grep ' /home '. - Corrupt or incomplete package: re-create the package on source, or re-transfer that account.
- EasyApache 4 module mismatch: align PHP versions/extensions before restoring multiple PHP-heavy accounts.
3) Validate cPanel is healthy on the destination before retry
/usr/local/cpanel/scripts/upcp --check
/usr/local/cpanel/bin/whmapi1 system_load_averageIf cPanel itself is unhealthy, restores can fail in inconsistent ways.
Put the destination into a controlled change window. Fix the core issue, then retry the restore.
For a safe workflow, use: cPanel maintenance mode tutorial (2026).
Post-transfer validation: catch wrong-site and mixed-content issues fast
After restore, the biggest risk is false confidence. Your browser may hit the new server while customers still hit the old one.
Validate with tests that don’t depend on caching luck.
1) Test the destination site before DNS cutover (hosts file method)
From your workstation, map the domain to the destination IP temporarily:
# Linux/macOS: /etc/hosts
203.0.113.20 example.com www.example.comThen verify headers and basic rendering:
curl -I https://example.com
curl -s https://example.com | head2) Check vhost mapping and document root quickly
On the destination server, confirm the domain maps to the expected user and path (EA4/Apache layouts vary):
grep -R "ServerName example.com" -n /etc/apache2/conf.d/userdata 2>/dev/null | head
grep -R "example.com" -n /etc/apache2/conf/httpd.conf 2>/dev/null | head3) Run AutoSSL only after DNS is correct
AutoSSL validation fails if the domain still points at the source. It can also fail if a proxy/CDN serves unexpected content.
When you see DCV errors, treat them as DNS/routing problems first. Don’t assume it’s a certificate issue.
If you want a step-by-step checklist for certificate failures, keep this handy: cPanel AutoSSL troubleshooting tutorial (2026).
DNS misroutes after cutover: fix zones, glue, and caching
If a site points to the wrong server after you “updated DNS,” stop guessing.
First, prove what the authoritative DNS says. Then work outward.
1) Verify authoritative nameservers and A records
dig +short NS example.com
# Query the authoritative nameserver directly
ns1=$(dig +short NS example.com | head -n1)
dig @$ns1 +short A example.com
dig @$ns1 +short A www.example.com2) Check for stale glue records (nameserver IP mismatches)
If you run your own nameservers (ns1/ns2 under the same domain), glue mismatches can make migrations look random.
They also create inconsistent results across resolvers.
Use a known-good process for delegation and glue: cPanel nameserver setup guide tutorial (2026).
3) Reduce confusion during moves with low TTL (but do it early)
TTL changes don’t take effect instantly.
For the next cutover, lower TTL at least a day ahead for key records (A/AAAA, www, mail, autodiscover).
Keep a documented rollback set so you can revert quickly.
Email pitfalls after a cPanel transfer: routing, PTR, and “local vs remote”
Email failures rarely announce themselves. Websites throw errors; mail usually queues, retries, or quietly lands somewhere else.
Check mail flow on purpose.
1) Confirm MX and mail A records point where you think they point
dig +short MX example.com
dig +short A mail.example.com2) Fix “Local Mail Exchanger” surprises in cPanel
If the destination believes it should accept mail for a domain but you’re using external mail (or the reverse), you’ll see bounces and delays.
You may also see messages landing on the wrong server.
Use this exact fix path: cPanel email routing tutorial (2026).
3) Verify reverse DNS (PTR) for outbound mail reputation
New server IPs without PTR can tank deliverability fast.
If your outbound mail IP changed during the move, set PTR immediately:
Reverse DNS setup tutorial (2026)
4) Check mail logs for immediate failures
tail -n 200 /var/log/exim_mainlog
exim -bp | headQuick “fix-forward” playbook: re-transfer only what’s broken
When a transfer fails halfway through, restarting everything wastes time. It also increases drift risk.
Treat the failure like a targeted repair.
- Stop and document: note the account name, timestamp, and current DNS state.
- Fix the root cause: disk space, firewall, resolver, EA4 modules, etc.
- Re-transfer only the failed account: confirm it restores cleanly before touching others.
- Re-validate: hosts-file test for web, log test for mail, then proceed.
If you need safe access while you test WHM/cPanel and webmail without opening extra ports, use SSH tunnels: SSH port forwarding tutorial (2026).
Hardening and stability after the move (so you don’t migrate twice)
Once the destination is live, stabilize and lock it down while the change is fresh.
Do it now, not during the next traffic spike.
- Enable 2FA for WHM admins and resellers: cPanel 2FA setup guide (2026).
- Set up incremental backups with retention rules and fast restores: cPanel incremental backups tutorial (2026).
- Ship backups off-server so a disk failure doesn’t wipe out both server and backups: cPanel remote storage setup tutorial (2026).
Conclusion: a calmer way to handle transfer failures
When WHM transfers fail, treat it like a normal incident. Confirm connectivity, measure resource pressure, read the restore logs, and apply a specific fix.
Most issues trace back to SSH access, disk space, resolver/DNS inconsistencies, or mail routing assumptions.
If you’re rebuilding your hosting stack to reduce transfer drama, start with predictable infrastructure and enough headroom.
A HostMyCode VPS is a solid base for cPanel. If you want help with the operational guardrails (updates, monitoring, and baseline security), managed VPS hosting fits.
If you’re planning a cPanel move or cleaning up a failed transfer, run it on infrastructure you can rely on. HostMyCode offers VPS hosting sized for cPanel workloads and managed VPS hosting if you want expert help keeping WHM stable during changes.
FAQ
Why does WHM Transfer Tool connect in WHM but fail over SSH?
WHM can store credentials, but the underlying SSH session may still fail due to firewall rules, resolver differences, host key conflicts, or root login restrictions. Always confirm with ssh -vvv from destination to source.
What’s the fastest way to prove DNS is still pointing at the old server?
Query the authoritative nameserver directly with dig @$ns1 A example.com, then compare it to what you get from a public resolver like 1.1.1.1. Caching and stale glue are common during cutovers.
AutoSSL fails after migration. Should I reinstall certificates manually?
Not first. Fix DNS and DCV pathing so the CA can validate the domain. Once validation works, AutoSSL usually completes without manual installs.
After the transfer, email works for some users but not others. Where should I look?
Check MX records, cPanel’s Email Routing (local vs remote), and Exim logs on the destination. Also set PTR (reverse DNS) for the outbound IP if it changed.
Should I re-run the entire transfer if one account fails?
No. Fix the root cause (space, permissions, package corruption), then re-transfer only the failed account and validate it. Full restarts waste time and can introduce new inconsistencies.