Moving a WordPress site is easy enough — export the database, copy wp-content, update the URLs, done. Moving a whole cPanel account is a different job. You've got email accounts with years of mail in them, multiple databases, cron jobs, SSL certificates, FTP users, and a DNS zone that everything else depends on. Miss one piece and you find out about it three days later when someone says their invoices stopped arriving. Here's how to move the entire account cleanly using WHM's Transfer Tool, plus what to do when you don't have root on both ends.
When You Need a Full Account Transfer (Not Just a Site Migration)
You need this when you're moving a cPanel account between two servers you (or SkyServer, on your behalf) control at the root or WHM reseller level — for example, moving from an older shared box to a new VPS, consolidating accounts onto fewer servers, or migrating away from a provider that's shutting down. It's overkill if all you're doing is copying one WordPress install; use a plugin-based migration for that instead.
The Transfer Tool is built for exactly this: it copies the cPanel account as a unit — home directory, databases, email, DNS zone, SSL, cron jobs, FTP accounts — from a remote server into WHM on the destination.
Before You Start: Four Things That Save You a Bad Night
- Lower your DNS TTL 24-48 hours ahead. If you're also switching nameservers or IPs, drop the TTL on the A record to 300 seconds now, not the day of the move. This is the single biggest lever for how fast the cutover actually feels to visitors.
- Confirm disk space and account quota on the destination. WHM will happily start a transfer and fail halfway through if the target doesn't have room for the full backup plus the extracted account. Check
df -hon the destination before you queue anything. - Match or exceed PHP/MySQL versions on the target. Restoring an account built on PHP 8.1 onto a server that only has PHP 7.4 available will restore fine but break the site immediately after. Check the account's current PHP version in WHM > Account Information first.
- Get SSH access sorted between the two servers. The Transfer Tool pulls over SSH (port 22 by default, or whatever you've set). If the source server firewalls WHM's IP or only allows key-based root login, add an authorized key or a temporary WHM API token before you start.
Doing the Transfer: WHM's Transfer Tool
On the destination server:
- Go to WHM > Transfers > Transfer Tool.
- Under "Setup Remote Access," enter the source server's hostname/IP and root credentials (or an SSH key). Test the connection before moving on — WHM will tell you immediately if it can't authenticate.
- Once connected, WHM lists every account on the source server. Select the one(s) you're moving. For a single account, this is faster than it sounds — usually a couple of minutes to queue.
- Under transfer options, decide whether to restore to the same username (recommended unless there's a conflict) and whether to bring over the account's IP address mapping or let it use the destination's shared IP.
- Leave "Perform a full account transfer" checked unless you specifically want to exclude something like a large mail directory — you almost never want to exclude email.
- Queue the transfer and watch the log. WHM shows each stage: generating the backup on the source, transferring it, then restoring it on the destination.
For accounts under a few GB this typically finishes in 10-20 minutes. Large mail-heavy accounts (multiple mailboxes with years of stored mail) can take considerably longer — the backup generation step is usually the slow part, not the transfer itself.
No Root on the Source Server? Use pkgacct/restorepkg Manually
If you're moving away from a host where you only have cPanel-level access (no WHM, no root), the Transfer Tool can't reach in and pull the account for you. Instead:
- In the source cPanel, go to Backup Wizard or Backup and generate a full account backup. Download the resulting
.tar.gzto your machine, or better, straight to the destination server viascpor an FTP client if the file is large. - On the destination, upload the backup into
/home(or wherever you have room) via WHM's File Manager, SFTP, orscp. - In WHM, go to Transfers > Restore a Full Backup/cpmove File and point it at the uploaded archive.
- WHM restores it as a new account, provisioning the home directory, databases, email accounts, and DNS zone from what's inside the archive.
This is functionally what the Transfer Tool does under the hood — it's just manual instead of scripted over SSH.
Symptom → Cause → Fix: What Actually Goes Wrong
| Symptom | Likely Cause | Fix |
|---|---|---|
| Transfer fails partway with a disk space error | Destination doesn't have room for backup + extracted account (roughly 2x the account size, briefly) | Free up space or move to a server with more headroom, then re-queue — WHM resumes cleanly on a fresh attempt |
| Email accounts exist but users can't log in with old passwords | Rare, but happens when the source used a different password hashing scheme, or the mail restore only captured the mailbox structure, not the auth database | Reset the affected mailbox passwords in cPanel > Email Accounts post-restore; don't assume they carried over without testing one |
| Site shows the old server's content right after cutover | DNS hasn't propagated yet, or your own browser/ISP resolver is caching the old A record | Check with dig +short yourdomain.com from a few different networks; flush local DNS cache; be patient if you skipped the TTL step above |
| SSL certificate breaks or shows a mismatch warning after the move | AutoSSL certs are tied to the server that issued them and don't transfer as valid certs — they need reissuing on the destination | Let AutoSSL run on the destination (usually automatic within a few hours) or force it via WHM > SSL/TLS Status > Run AutoSSL. Custom/paid SSL certs need their key and cert files re-uploaded manually — the Transfer Tool does bring these over as files, but double-check "SSL/TLS Manager" after restore. |
| Cron jobs run twice during the transition | Both the old and new server are active with the same cron schedule at once | Disable cron jobs on the old server as soon as the new one goes live, don't run both in parallel longer than necessary |
| Some mail from the last few hours before cutover is missing | New mail arrived on the source server after the account backup was generated but before DNS/MX fully switched | Keep the old server reachable (don't delete the account) for 48-72 hours post-cutover and manually check for late-arriving mail in the old mailbox before decommissioning |
After the Transfer: What to Actually Check
- Log into cPanel on the new account and confirm every database exists and has data — a row count check on your main tables takes thirty seconds and catches a lot.
- Send a test email to and from each mailbox that matters. Don't just check that the account exists in the list.
- Verify the DNS zone came over correctly, especially any custom MX, TXT (SPF/DKIM), or CNAME records you'd added manually — these sometimes get missed if they were added outside of cPanel's Zone Editor.
- Check cron jobs under Cron Jobs in the new account — they transfer, but it's worth confirming the schedule and command paths still make sense on the new server (PHP binary paths in particular can differ between hosts).
- Watch the new server's error logs for the first 24-48 hours. A lot of small path or permission issues only surface once real traffic hits.
Prevention: Make the Next Migration Boring
The accounts that migrate cleanly are the ones where someone lowered the TTL early, tested the backup/restore on a non-production account first, and kept the old server alive for a few days as a safety net instead of tearing it down the moment DNS switched. None of that is exciting work, but it's the difference between a migration nobody notices and one that generates support tickets for a week.
Frequently Asked Questions
Does the Transfer Tool move the account's IP address too?
Only if you tell it to and the destination server has a free dedicated IP available. Most transfers land on the destination's shared IP by default, which is fine for HTTP/HTTPS since SNI handles the certificate matching — it only matters if something on the account (like an old mail client config) hardcodes the IP directly.
Will my SSL certificates transfer automatically?
AutoSSL (Let's Encrypt) certificates don't transfer as valid certs — they're reissued fresh on the destination, usually within a few hours of the account existing there with correct DNS. Custom purchased certificates do come over as files during a full transfer, but always verify them in SSL/TLS Manager afterward rather than assuming.
How long should I keep the old server running after cutover?
At minimum 48-72 hours, longer if your domain's DNS TTL was high before you started lowering it. This covers stragglers still resolving the old IP and gives you a place to check for late-arriving email.
Can I transfer just one email account instead of the whole cPanel account?
Not with the Transfer Tool — it moves the entire account as a unit. For a single mailbox, use an IMAP sync tool like imapsync between the old and new mail servers instead, which lets you migrate mail without touching anything else on the account.
What if the destination server has a different cPanel version?
Restoring onto an equal or newer cPanel version is fine and is the normal case. Restoring onto an older version than the source can cause partial restores or missing features — always check the destination is up to date before queuing a transfer from a newer source.
