cPanel to cPanel migration: how to move accounts to a new server (2026)

This guide covers moving cPanel accounts from one cPanel server to another, either with the WHM Transfer Tool or with the pkgacct and restorepkg scripts when you want more control. The copying is the easy part; cutover order, DNS, mail and database version drift are where cPanel to cPanel migrations go wrong, so plan those first. And one rule above all: don’t cancel the old server until mail and DNS have settled on the new one.

Inventory before you move

Build a spreadsheet with one row per account. It’s what you’ll work from on cutover night, and it’s how you’ll know nothing got left behind.

• Disk use, split into files, mail and databases
• PHP version, and whether the site pins one
• MySQL or MariaDB version the databases were built on
• Mailbox count and total mail size
• Addon and parked domains
• Dedicated IPs
• SSL: AutoSSL, or a purchased certificate you’ll need to reinstall
• Cron jobs
• Reseller ownership and ACLs
• Anything that depends on a custom EasyApache 4 profile

Then do the server itself: hostname, nameservers, whether you’re in a DNS cluster, firewall rules, custom Apache includes, and any cron jobs that run as root. Those live outside the accounts, so no account-level tool will carry them.

While you’re in there, delete what you don’t need. Accounts for former clients, dead projects, a 40 GB folder of old backups inside someone’s home directory: every gigabyte you don’t move is time you don’t spend moving it.

Two version rules. Make the target’s MySQL or MariaDB version the same as the source’s or newer, never older. And run the same cPanel & WHM version on the target, or a newer one. cPanel’s own docs warn against moving calendar and contacts data from version 120 or later to 118 or earlier, which tells you which direction is safe.

Build the target first

Get the new server fully set up before a single account moves.

1. Pick the OS. On our servers cPanel runs on AlmaLinux 8, 9 or 10, CloudLinux 8, 9 or 10, or Ubuntu 22.04 or 24.04.
2. Activate the license. The new server needs its own. What that costs, and why it’s per server, is in what a cPanel license costs.
3. Set the hostname and reverse DNS before mail starts flowing, or your first outbound messages land in spam folders.
4. Match the EasyApache 4 profile. Export it from the old server and import it on the new one so every PHP version and extension your sites need is already there. We wrote up how to move EasyApache 4 profiles between servers. Still on EasyApache 3? Upgrade on the old server first and deal with that change separately; here’s why EasyApache 4 is worth it.
5. Install CloudLinux before restoring accounts, if you’re using it, so every account lands with its limits already in place.

If you’re still choosing hardware, our cPanel dedicated servers come with the license on the order form.

Pick your method

Method 1: the WHM Transfer Tool (use this one)

The Transfer Tool copies cPanel accounts, packages and configuration from a source server to the destination. You run it in WHM on the new server, as root, and point it at the old server’s address and root login.

Live Transfer is on by default. Once an account is copied, it points that account’s A, NS and MX records at the new server and suspends the account on the old one. That’s handy when DNS is hosted on the old server and you’re happy to cut over account by account. If you’d rather test everything before any DNS changes, turn it off and cut over yourself.

Without root on the old server, use WHM’s Transfer or Restore a cPanel Account interface instead. It can pull one account from a remote cPanel server using that account’s username and password, or restore an uploaded cpmove archive. Resellers can use it unless the host has switched it off.

What doesn’t come across. cPanel’s docs list two-factor authentication settings and DNS zone templates as things the transfer leaves behind, so users will need to set up 2FA again. Treat server-wide settings as your job too: the tool is built around accounts, so check its options on your cPanel version for which service settings it can copy, and rebuild the rest by hand from your inventory.

Start with one small, boring account. Check it end to end on the new server, then move the rest in batches you can check in one sitting.

Method 2: pkgacct and restorepkg

The scripts behind the Transfer Tool are available on their own. pkgacct packages one account into an archive named cpmove-USERNAME.tar.gz; restorepkg restores it.

# old server, as root: package one account into /home/migrate
mkdir -p /home/migrate
/usr/local/cpanel/scripts/pkgacct username /home/migrate

To do a batch, put the usernames in users.txt, one per line:

while read -r u; do
  /usr/local/cpanel/scripts/pkgacct "$u" /home/migrate
done < users.txt
cd /home/migrate && sha256sum cpmove-*.tar.gz > SHA256SUMS

Copy the folder to the new server with rsync or scp, check the checksums, then restore. restorepkg takes the full path to an archive:

# new server, as root
cd /home/migrate && sha256sum -c SHA256SUMS
for f in /home/migrate/cpmove-*.tar.gz; do
  /usr/local/cpanel/scripts/restorepkg "$f"
done

Very large accounts. Package them with --skiphomedir so the archive holds the account without its files, restore that, then copy the home directory across with rsync. Run the rsync again right before cutover to pick up whatever changed. Leave out --numeric-ids: the restored user may not get the same UID on the new server, and rsync maps ownership by name by default. pkgacct also has --skipmysql for accounts whose databases you’d rather dump and load yourself.

If a transfer in the Transfer Tool fails for one account, this is also how you find out why: run pkgacct by hand and read what it says.

Cutover order

This is the part to get right.

1. Lower the TTLs a day ahead, or one full old TTL ahead if that’s longer, on every record you’ll change. If a domain’s DNS lives somewhere else (Cloudflare, a registrar, a client’s own DNS), find out now who can log in to it.
2. Put busy dynamic sites in maintenance mode while they move. Orders, comments and forum posts written to the old server after its copy was taken are lost.
3. Move the accounts.
4. Test before you switch. Edit your local hosts file to point a domain at the new IP and click through the site.
5. Final sync of home directories and mail for anything that changed.
6. Switch DNS, or let Live Transfer do it.
7. Catch late mail. Stop Exim on the old server so senders get a temporary failure and retry against the new MX, or sync mailboxes afterwards with an IMAP sync tool such as imapsync. Either beats mail quietly landing in a mailbox nobody reads again.
8. Keep the old server running for 48 to 72 hours.

IP addresses. Plan on new IPs for the new server. Every site on a dedicated IP needs its records updated, and if your own nameservers change IP, update their glue records at the registrar too.

After the move

• Run AutoSSL on the new server and reinstall any purchased certificates.
• Check that backups are configured and actually run on the new box. Restore one file to prove it.
• Point monitoring at the new server.
• Revoke SSH keys and API tokens that only the old server needed.
• Power the old server off before you cancel it. If something breaks, turning it back on is your rollback. Cancel only once a few days have gone by without surprises.

Coming from Plesk or DirectAdmin

cPanel’s Transfer Tool documentation covers transfers from Plesk, with known limits: email addresses containing a plus sign and FTP accounts with an underscore in the name don’t come across. Rename those first. For DirectAdmin and other panels, plan on moving site by site: files, a database dump per database, and the mailboxes over IMAP. It’s slower, so test one site end to end before you commit a date.

Where GigeNET fits

If you’re moving from another host, we migrate your cPanel accounts to the new server free. For anything else, like sites coming from another panel or a move between two of your own servers: We help with the move. On larger deployments it’s often included; smaller jobs are quoted up front.

The move that goes wrong most often looks like this. Nobody lowered the TTLs, so the A and MX records still say 86400 seconds, a full day. The accounts move cleanly, DNS is switched, and the old server gets cancelled that evening. For up to 24 hours, any resolver that cached the old records keeps sending mail to an IP that no longer answers, and senders queue, retry and eventually bounce. The fix is boring: drop the TTLs to 300 at least one old-TTL period before cutover (so a full day ahead when they’re at 86400), and keep the old server up with Exim stopped or a mailbox sync running until the old TTL has run out.

The other classic is database drift. The source runs a newer MariaDB than the target, and restores fail on dumps that use collations or syntax the older server doesn’t know. That’s why the target’s database version goes on the inventory before you build anything.

Our cPanel dedicated servers come with the license on the order form, and the quote form is the fastest way to price a bigger estate.

FAQ

Landing on a new server? cPanel comes on the order form, and we help with the move: start with cPanel dedicated servers or send us the details through the quote form.