cPanel Transfer Tool Tutorial (2026): Migrate Accounts Between WHM Servers With Minimal Downtime

A cPanel move that “mostly works” still triggers the worst support tickets. You’ll see missing mail, broken SSL, and DNS answers that vary by resolver. This cPanel Transfer Tool tutorial shows a clean WHM-to-WHM migration path for 2026. It also includes checks that catch common failure points before your customers do.

The workflow assumes you’re moving accounts from an older cPanel/WHM server to a new VPS or dedicated server.

The goal is boring, repeatable outcomes. You want consistent DNS, intact email, valid SSL, and a rollback plan you can run quickly.

What you’ll migrate (and what you should decide first)

WHM’s Transfer Tool can copy most key components. That includes cPanel accounts, home directories, MySQL users (via account backup), mailboxes, and many account settings.

What it won’t fix is a policy mismatch between servers. Decide the basics first, then transfer.

• New server hostname (FQDN) and reverse DNS (PTR) for the main IP.
• Nameserver plan: keep existing nameservers, or switch to new ones.
• IP strategy: shared IP vs dedicated IPs for select accounts; NAT if applicable.
• Control panel parity: OS family, cPanel version channel, EasyApache 4 profile, and PHP versions.

If you’re building a fresh destination, start from a stable hosting baseline.

Use sane firewall rules, SSH keys (not shared passwords), current updates, and working time sync.

If you need a safe way to validate services privately, see this SSH port forwarding tutorial.

Prerequisites checklist (source and destination)

Do these checks before you pick a migration window.

They prevent the classic “transfer finished, but half the stack is broken” outcome.

• Destination resources: CPU, RAM, and disk sized for peak, not average. If you’re consolidating many accounts, leave extra room for mail and backups.
• Time sync: confirm NTP is active on both servers.
• Firewall: allow outbound from destination to source for SSH (22) and rsync if used. Don’t expose WHM publicly just to transfer.
• Same or compatible OS family: cPanel supports specific OS releases; use a supported build only.
• DNS awareness: know where zones are hosted today (WHM DNS cluster, third-party DNS, or registrar).

On both servers, confirm identity, OS, and basic capacity:

hostname -f
cat /etc/redhat-release 2>/dev/null || cat /etc/os-release
df -h /
free -h
timedatectl status

If you’re moving business-critical hosting, a managed VPS hosting plan from HostMyCode can reduce risk on the destination build.

It helps with kernel updates, firewall sanity checks, and migration assistance. You still keep WHM control.

Step 1: Prepare the destination WHM (so transfers don’t “succeed” into a broken stack)

Your destination should be production-ready before you import a single account.

Treat the transfer as the last step, not the first.

• Set hostname in WHM: Networking Setup → Change Hostname.
• Resolver: verify /etc/resolv.conf points to reliable DNS resolvers.
• Update cPanel: use the same update tier as the source unless you have a reason to change.
• EasyApache 4 profile: match Apache/LiteSpeed choice and PHP extensions used on the source.
• Mail stack alignment: don’t change mail routing behavior mid-move unless you’re prepared to test deliverability.

Two quick checks that save you later:

# Confirm cPanel is healthy
/usr/local/cpanel/cpanel -V
/usr/local/cpanel/bin/whmapi1 version

# Quick service snapshot
systemctl status httpd exim dovecot 2>/dev/null | head -n 40

Step 2: Lower DNS TTL ahead of time (and plan rollback)

Low downtime comes from setting short TTLs before cutover.

If your current TTL is 3600 seconds, drop it to 300–600 seconds at least a few hours before you switch A records.

For a practical TTL plan, record verification steps, and a rollback sequence you can follow under pressure, use this DNS cutover tutorial.

Keep it open during the migration window.

Step 3: Decide on nameservers: keep them or move them

This decision shapes how clean the cutover feels.

• Keep existing nameservers (common): change A/AAAA records for sites, and MX if mail changes. Fewer moving parts, easier rollback.
• Move nameservers: update NS at the registrar (or DNS provider). It works, but it adds another layer of propagation to watch.

If you run WHM DNS clustering, make sure zones sync correctly before and after the move.

For a hands-on walkthrough, see this cPanel DNS cluster setup guide.

Step 4: Run a pre-flight audit on the source (catch the messy accounts)

Transfer Tool behaves best when the source is tidy.

Identify accounts that will drag the window out or fail in surprising ways.

• Accounts with huge maildirs (often years of attachments).
• Sites with non-standard document roots or custom vhost includes.
• Very large backup archives sitting in home directories.
• Accounts with outdated PHP code that won’t run on your destination defaults.

Quick source-side checks:

# Largest home directories
du -xhd1 /home | sort -h | tail -n 15

# Maildir heavy hitters
du -xhd2 /home/*/mail 2>/dev/null | sort -h | tail -n 15

If the old server is already tight on disk, you’ll move faster after cleanup.

Be conservative. Delete obvious junk and stale archives.

Don’t touch live application data unless you’re certain.

Step 5: Configure WHM Transfer Tool (and pick the right transfer method)

On the destination server, open WHM → Transfers → Transfer Tool.

Add the source server details, then pick your transport.

• Use SSH with root where possible. It’s usually the most predictable option.
• Authenticate with keys if your policy forbids passwords. Add the destination’s SSH key to the source’s authorized_keys for root (or an allowed transfer user).
• Enable incremental if you plan a second pass right before final cutover.

Common gotcha: restrictive firewalls on the source.

The destination must be able to reach it. Test connectivity first:

# From destination to source
ssh -o BatchMode=yes -o ConnectTimeout=10 root@SOURCE_IP 'echo ok'

If that fails, fix the network policy.

Don’t “solve” it by exposing WHM to the public internet.

Step 6: Choose account selection and transfer options

You can move everything in one shot.

Commercial hosting is calmer in waves. You get a known-good baseline before you touch the complicated accounts.

• Wave 1: your own test account(s) and low-traffic sites.
• Wave 2: normal customer sites.
• Wave 3: big mailboxes, high-traffic, and “special” stacks.

Options to review carefully:

• Copy home directory: keep enabled unless you have a separate content migration plan.
• Copy databases: usually enabled, but verify DB size and restore time constraints.
• Copy SSL certificates: helpful, but still validate behavior after cutover.
• Overwrite accounts: use only for re-runs when you know exactly what will be replaced.

Step 7: Monitor the transfer like an operator (logs, not vibes)

WHM’s UI is fine for progress.

Troubleshooting starts in the logs. On the destination server, follow the transfer session output while it runs:

# Useful locations (may vary by build)
tail -f /var/cpanel/logs/transfer_session* 2>/dev/null
ls -lah /var/cpanel/logs/ | grep -i transfer | tail

If an account fails, don’t blindly re-run the whole batch.

Read the error, fix the blocker (permissions, missing package, corrupt archive), then re-run that account.

Step 8: Post-transfer validation (web, PHP, cron, permissions)

Validate before you touch public DNS.

Keep the old server serving production traffic while you verify the new one.

Web and vhost sanity checks

• Confirm each domain resolves locally to the new vhost.
• Check HTTP status codes and redirect loops.
• Verify PHP version matches what the site expects.

A clean way to test without changing public DNS is a temporary hosts-file entry.

You can also use curl with a forced resolution:

# Replace DOMAIN and DEST_IP
curl -I --resolve DOMAIN:80:DEST_IP http://DOMAIN/
curl -Ik --resolve DOMAIN:443:DEST_IP https://DOMAIN/

File ownership and permissions

The most common post-transfer break is ownership drift on writable paths (uploads, cache, session storage).

Check per account:

# Replace USER
id USER
ls -lah /home/USER/public_html | head

Cron jobs

If a site depends on cron (billing, backups, queue workers, scheduled publishing), confirm the crontab made it across:

# Replace USER
crontab -u USER -l

Step 9: Email validation (mailboxes, routing, and deliverability basics)

Email is where migrations get expensive.

You’re protecting two things at once: mailbox data and deliverability.

• Mailbox presence: verify IMAP login and folder counts for a few real users.
• Outbound test: send to Gmail and Outlook, confirm it lands in Inbox and headers look sane.
• Inbound test: send from an external mailbox into your domain and confirm delivery time.

From the destination server, confirm mail services and get a quick read on the queue:

systemctl status exim dovecot --no-pager
exim -bpr | head

If deliverability degrades after cutover, the fastest path is usually SPF/DKIM/DMARC and rDNS alignment.

Keep these references close:

• email authentication setup tutorial (SPF/DKIM/DMARC/rDNS)
• email deliverability troubleshooting steps for bounces and spam placement

Step 10: SSL on the destination (don’t assume copied certs are usable)

Transfer Tool can bring certificates over.

Still confirm live behavior on the new IPs.

• Confirm the certificate matches the hostname and SANs.
• Verify the correct certificate is selected for each vhost (SNI).
• Make sure redirects don’t create loops after you enforce HTTPS.

Quick checks:

# Replace DOMAIN
openssl s_client -connect DOMAIN:443 -servername DOMAIN </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

If you plan to re-issue certs after cutover, do it as a controlled Let’s Encrypt rollout.

For Nginx-based stacks, keep this SSL setup guide tutorial handy for redirects and renewals.

Step 11: The cutover runbook (low downtime sequence)

This sequence keeps visible downtime close to your DNS TTL, plus normal cache variance.

1. Freeze changes (optional but recommended): pause deploys and heavy content changes.
2. Final incremental transfer: re-run Transfer Tool for the accounts in the cutover batch.
3. Switch DNS: update A/AAAA records (and MX if it changes). Keep the old server running.
4. Observe: watch access logs, error logs, and the mail queue on the new server.
5. Handle stragglers: some users will hit the old server briefly due to resolver caching.

For each domain, confirm public resolvers now see the destination IP:

# Replace DOMAIN
getent hosts DOMAIN

# Query a public resolver
dig +short A DOMAIN @1.1.1.1
dig +short A DOMAIN @8.8.8.8

Step 12: Post-cutover checks (first 60 minutes)

Most real problems show up fast if you watch the right signals.

• Web errors: tail domain error logs; look for 500s tied to missing PHP extensions.
• CPU/RAM: confirm you didn’t under-size the destination or miss caching requirements.
• Mail queue: a rising queue points to routing or outbound policy issues.
• SSL warnings: open a few sites in a real browser from a clean profile.

# Quick resource view
uptime
vmstat 1 5

# Mail queue trend (repeat a few times)
exim -bpc

Step 13: Keep the old server as a safety net (then decommission cleanly)

Don’t cancel the old server the moment a homepage loads.

Keep it online for a cooling-off period so you can:

• recover missed mail from late DNS propagation,
• copy last-minute user uploads,
• roll back a domain quickly if a critical app fails.

A practical pattern is keeping the old server for 7–14 days.

Decommission only after you’ve verified backups and restored at least one account into a test environment.

If you want a restore-first mindset (and you should), write a short runbook you can follow under pressure.

Use this disaster recovery tutorial as a template for “prove it restores,” not “assume it backed up.”

Troubleshooting: common Transfer Tool problems and fast fixes

Transfer stalls or is extremely slow

• Check source disk I/O saturation (maildir and large accounts can thrash disks).
• Verify the source isn’t rate-limiting SSH or hitting connection tracking limits.
• Move large accounts in a dedicated window, not mixed into a batch.

Sites work on the new server but break after DNS cutover

• Look for hardcoded IPs, API allowlists, or external services pinned to the old IP.
• Confirm IPv6 (AAAA) doesn’t still point at the old host.
• Check mixed content and forced redirects (HTTP→HTTPS→HTTP loops).

Email receives but outbound goes to spam or gets rejected

• Confirm PTR (rDNS) matches the new server hostname and that SPF includes the new IP.
• Verify DKIM signing is active on the destination.
• Check HELO/EHLO identity if remote servers complain.

Migration mini-checklist (printable)

• [ ] Destination WHM ready: hostname, updates, services running
• [ ] DNS TTL lowered in advance
• [ ] Transfer Tool connectivity tested (SSH from destination to source)
• [ ] Accounts migrated in waves; large mailboxes planned
• [ ] Pre-cutover validation done with --resolve tests
• [ ] Final incremental transfer completed
• [ ] DNS cutover executed (A/AAAA/MX as needed)
• [ ] Web logs, mail queue, and SSL validated post-cutover
• [ ] Old server retained for safety window
• [ ] Backups verified and at least one restore test performed

FAQ

Does the Transfer Tool move email messages and folders?

Yes. It typically copies mailboxes (Maildir), folder structure, and account settings.

Still test real IMAP logins and confirm new mail arrives after cutover.

Should I switch nameservers during a cPanel migration?

Only if you have a clear reason.

Keeping nameservers the same and changing A/AAAA records usually reduces propagation variables and simplifies rollback.

How do I keep downtime low during the final cutover?

Lower TTL ahead of time, run an incremental re-transfer right before you switch DNS, and keep the old server online to catch stragglers and late mail.

What’s the safest way to test sites before changing DNS?

Use curl with --resolve to force your domain to the destination IP, or use a temporary hosts-file entry on your workstation.

This avoids public DNS changes while you validate.

After migration, can I delete the old server immediately?

Don’t.

Keep it for a cooling-off period (often 7–14 days) so you can recover late mail, grab missed uploads, and roll back a critical domain if needed.

Summary: a Transfer Tool migration that stays boring (the good kind)

A successful WHM migration isn’t about clicking “Transfer” and hoping for the best.

It’s TTL planning, an incremental pass right before cutover, and validation while the old server is still live.

It also means careful email and SSL checks afterward.

Do that, and downtime becomes a short, predictable window instead of an all-night incident.

If you want a clean destination for WHM account moves in 2026, start with a HostMyCode VPS (or step up to a dedicated box for larger fleets).

The extra headroom and stability are what make migrations routine.