# Transferring accounts between servers with the WHM Transfer Tool Source: https://srvscripts.com/guides/whm-transfer-tool/ Updated: 2026-10-03 Publisher: srvScripts (https://srvscripts.com/) The WHM Transfer Tool is the supported way to move accounts between cPanel servers. It connects from the destination to the source over SSH, packages each account, streams it across, restores it, and can proxy traffic from the old server to the new one while DNS propagates. Used carefully it moves hundreds of accounts with no customer involvement; used carelessly it produces half-restored accounts and hours of mail bounces. This guide sets out the sequence that works. In short: On the destination, open WHM → Transfers → Transfer Tool, enter the source server’s SSH details, select the accounts and enable Express Transfer with Live Transfer so the old server proxies traffic after each restore. **Short answer:** On the destination, open WHM → Transfers → Transfer Tool, enter the source server’s SSH details, select the accounts and enable Express Transfer with Live Transfer so the old server proxies traffic after each restore. Before that, confirm the destination runs an equal or newer cPanel and database version with matching PHP versions, allow the destination IP in the source firewall and lower DNS TTLs; afterwards read every restore log, test each site by hosts-file override and only then change DNS. ## Prepare both servers The destination should be on the same or a newer cPanel version than the source, on a supported OS and tier, and with the database server at an equal or higher version. Transferring from MariaDB 10.11 to 11.8 works; transferring from MariaDB to a lower version, or from MariaDB to MySQL, does not. Check both sides: ``` whmapi1 version mysql -e 'SELECT VERSION();' whmapi1 php_get_installed_versions ``` Make sure the destination has every PHP version the source accounts use, or plan to remap them, and that EasyApache modules match closely. Confirm disk space on the destination: the restore needs roughly twice the size of the largest account during unpacking. On the source, the transfer needs SSH access as root or as a user with sudo, on whatever port SSH runs. Add the destination’s IP to the source’s firewall allow list (`csf -a `) so the connection is not blocked by the login failure detector. The source should have a recent, tested backup as a precaution. Lower the TTL on the DNS records for every domain to be moved at least a day ahead; 300 seconds is a reasonable value for the cutover period. ## Start a transfer session In WHM on the destination, open Transfers → Transfer Tool. Enter the source hostname or IP, the SSH port, and root credentials or a key. Fetch the account list. The tool shows every account on the source with its size and a set of per-account and global options. The options that matter: - Express Transfer, which includes Live Transfer: after each account is restored, the source’s copy is put into a proxy mode that forwards web and mail traffic to the destination. This closes the gap where changes made on the old server after the copy are lost, and it is the right choice when you cannot control the DNS cutover closely. - Dedicated IP handling: choose whether accounts with dedicated IPs on the source get one on the destination or share the main IP. - Skip options for reseller privileges, and whether to restore the account’s cron jobs and Exim mail routing settings. - Replace existing accounts: needed only when repeating a transfer; leave it off the first time. Select the accounts, then start. Each account is packaged with `pkgacct` on the source, streamed, and restored with `restorepkg`. The session view shows progress per account and links to the restore log. Sessions can be resumed after a disconnect from the Transfer Tool’s session list. ## Run the same from the shell For large fleets or repeatable runs, the whmapi1 functions behind the tool can be scripted: ``` whmapi1 create_remote_root_transfer_session host=old.example.net user=root \ password='' port=22 transfer_threads=2 restore_threads=2 \ enable_custom_pkgacct=0 --output=json whmapi1 enqueue_transfer_item transfer_session_id= module=AccountRemoteRoot \ user=customer1 localuser=customer1 skipres=0 ip=0 whmapi1 start_transfer_session transfer_session_id= whmapi1 get_transfer_session_state transfer_session_id= ``` Enqueue one item per account, then start the session once. Keep thread counts modest so the source is not saturated; two of each suits a busy production box. ## After the restore Read the restore log for every account, not just the ones that show a warning. The log is at `/var/cpanel/logs/transfer_sessions//` on the destination and lists each stage: home directory, databases, mail, cron, SSL certificates, DNS zone. Warnings about missing PHP versions, skipped database grants or SSL certificates that could not be installed are the ones to act on. Then check the things a restore commonly changes. The account’s PHP version may have been reset to the destination default; compare with `whmapi1 php_get_vhost_versions`. Database users are recreated, but applications with a hard-coded database host that is not `localhost` need editing. Mail is copied, but the mail accounts’ passwords are restored as hashes, so if the destination is on Dovecot 2.4 with stronger password hashing (132 and later), they still work and are rehashed on the first successful login. Zones are rewritten to the destination IP by default; verify with `whmapi1 dumpzone domain=example.com | grep -E '\sA\s'`. If DNS is hosted elsewhere, the external records must be updated by hand. ## Cut over and verify Before touching DNS, test each site on the destination using a hosts file entry or the destination’s preview URL, log into cPanel as the user, and send a test mail. Then update DNS. With Live Transfer enabled, traffic that still reaches the old server is forwarded, so there is no rush; without it, coordinate the DNS change immediately after the last account completes. ``` dig +short example.com curl -sI --resolve example.com:443: https://example.com/ | head -3 whmapi1 accountsummary user=customer1 | grep -E 'ip|suspended' ``` Watch the destination’s mail log for inbound delivery for a day, then run `/usr/local/cpanel/bin/autossl_check --all` so certificates that could not be issued before DNS moved are issued now. Once everything is confirmed, suspend the accounts on the source for a week before deleting them, so a missed dependency can still be recovered. The broader planning side is covered in [Migrating cPanel accounts to a new server](/guides/migrate-cpanel-accounts-new-server/). ## Common pitfall The most damaging mistake is changing DNS before reading the restore logs, and only later discovering a database that failed to restore because of a reserved-word collision or a version mismatch. By then the old server has been modified or wiped. Read every log, fix every warning, test every site, and only then change DNS. The second is forgetting the firewall on the source: the transfer starts, the source’s login failure daemon blocks the destination after a few connections, and the session stalls with an SSH error. Allow the destination IP first. ## WHM Transfer Tool at a glance **Official documentation:** [cPanel & WHM documentation](https://docs.cpanel.net/), [Linux man pages](https://man7.org/linux/man-pages/). **Related guides:** [Google Workspace: migrate email from cPanel/IMAP with the Data Migration Service](https://srvscripts.com/guides/migrate-cpanel-email-to-google-workspace/) · [Migrating cPanel accounts to DirectAdmin and the post-migration checklist](https://srvscripts.com/guides/migrate-cpanel-to-directadmin/) · [Migrate DirectAdmin to cPanel with the WHM Transfer Tool or pkgacct-da](https://srvscripts.com/guides/migrate-directadmin-to-cpanel/). ## Frequently asked questions ### Does the WHM Transfer Tool copy email, databases and SSL certificates? Yes. Each account is packaged with `pkgacct`, which includes the home directory and mail, databases and their users, cron jobs, DNS zones and installed certificates. Certificates for domains whose DNS has not yet moved may fail to install and are reissued by AutoSSL after the cutover. ### How long does a WHM transfer take per account? Packaging, streaming and restoring a typical account of a few gigabytes takes minutes; the total is governed by the network link between servers and the thread counts. Two transfer and two restore threads keep a busy source responsive while moving hundreds of accounts overnight. ### Can I transfer accounts from a newer cPanel version to an older one? No. The destination must run the same or a newer cPanel version and an equal or higher database version than the source. Moving from MariaDB to MySQL, or to a lower MariaDB release, is not supported and the restore fails on the databases.