Migrate cPanel to cPanel With WHM Transfer Tool

A clean server move comes down to two things: don’t lose email, and don’t break DNS at 2 a.m. This walkthrough shows how to migrate cPanel to cPanel with WHM’s Transfer Tool.

You’ll then cut traffic over with controlled DNS changes and a per-account verification checklist.

The steps below assume you’re moving to a new VPS or dedicated server you control. If you’re building new infrastructure first, managed VPS hosting from HostMyCode can handle the routine work.

That includes baseline hardening, monitoring, and cPanel maintenance windows.

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

WHM Transfer Tool can move almost everything you’d expect: cPanel accounts, home directories, databases, email, DNS zones, SSL, and many service configs.

How smooth the move feels depends on two choices you make before you start.

• Nameserver strategy: keep existing nameservers (most common) or switch to new nameservers at cutover.
• Mail routing strategy: keep mail on the old server while you cut web traffic over, or move mail and switch MX at the same time.

If you want the least drama, migrate first, test on the new server, then flip DNS. That’s the workflow used below.

Prerequisites on both servers (do these before the first transfer)

You need root access on both servers. You also need a working WHM on the destination.

The source can run any currently supported cPanel OS. The destination should stay within cPanel’s supported platforms for 2026. AlmaLinux or Rocky are the usual choices.

Plan disk usage honestly. You need space for the full copy and temporary transfer files.

Checklist: source server

• Root SSH access enabled
• Outbound SSH allowed to destination
• No active filesystem corruption; free space > the total size of accounts you’re moving

Checklist: destination server

• WHM working; hostname and resolver set correctly
• Dedicated IPv4 (recommended for clean rDNS and mail deliverability)
• Time synced (chrony/systemd-timesyncd); mismatched time breaks TLS and auth in subtle ways

On both servers, run a quick version and resource sanity check:

# SSH in as root
uname -r
cat /etc/os-release
whmapi1 version | head
df -h /
free -h

If you’re still locking down the destination, finish that work before you migrate.

Security changes after the move are where “mystery” permission and connectivity issues show up.

See: cPanel Server Security Tutorial (2026).

Lower DNS TTL before you migrate (so cutover is fast later)

Do this early. TTL changes don’t apply instantly.

Set lower TTLs a few hours ahead of cutover. If you can, do it 24 hours ahead for extra safety.

Lower TTLs for:

• A/AAAA records for the main site and common subdomains (www, mail if used)
• MX record(s) if you plan to move mail

A common temporary TTL is 300 seconds. If DNS lives on the source cPanel server, update zones in WHM → Edit DNS Zone. If DNS is external (registrar/Cloud DNS), make the TTL changes there.

If you want a methodical cutover playbook, follow DNS Cutover Tutorial (2026).

You can apply the same approach to your cPanel migration.

Open only the ports you need (avoid transfer failures)

The Transfer Tool connects over SSH from destination → source. At minimum, you need:

• TCP 22 from destination to source (or your custom SSH port)
• WHM ports on destination for your access (2087) and cPanel user access (2083) for testing

On a typical Linux firewall, allow SSH and the WHM/cPanel ports you’ll use for validation.

If you use UFW on the destination, this is a common minimal set:

ufw allow 22/tcp
ufw allow 2087/tcp
ufw allow 2083/tcp
ufw status verbose

If you want a quick refresher on tight, sane firewall rules, see Set Up UFW Firewall on Ubuntu for a Web Server.

Run WHM Transfer Tool (migrate cPanel to cPanel with predictable results)

Log into destination WHM as root.

1. Go to WHM → Transfers → Transfer Tool.
2. Under Add a Transfer Session, choose Remote Server Type: cPanel.
3. Enter the source server hostname or IP.
4. Choose authentication:
   • Root password (works, but not ideal for audits)
   • SSH key (preferred). Paste the private key or use WHM’s key management if available.
5. Click Fetch Account List.

After the account list loads, choose what you’re moving. For the first pass, migrate one low-risk account.

This confirms the workflow end-to-end.

Transfer options worth paying attention to

• Copy DNS zones: enable this if DNS is hosted on the source server and you want the destination to become authoritative after cutover.
• Replace conflicting accounts: keep this off unless you’re repeating a transfer and you’re certain what will be overwritten.
• Enable Restricted Restore: leave this enabled unless you have a specific reason. It helps prevent unsafe path restores.
• Service configurations: don’t import everything on autopilot. Source-specific settings can clash with the destination IP layout and network.

Start the transfer. WHM will show the session and per-account progress.

Depending on disk speed and mailbox size, transfers can take minutes or hours.

Verify the transfer from the command line (quick sanity checks)

On the destination, confirm the account exists. Also confirm the home directory is populated:

# Replace USERNAME
whmapi1 accountsummary user=USERNAME | egrep 'user:|domain:|ip:|suspended:'
ls -lah /home/USERNAME | head

Then confirm databases exist:

# MySQL/MariaDB
mysql -e "SHOW DATABASES;" | head

# Look for the user's db prefix (often username_*)
mysql -e "SHOW DATABASES LIKE 'username\_%';"

Preview each website on the new server before DNS cutover

Don’t rely on assumptions. Test each site on the destination while public DNS still points at the source.

Method A (recommended): edit your local hosts file

On your laptop/desktop, temporarily map the domain to the destination IP.

• macOS/Linux: /etc/hosts
• Windows: C:\Windows\System32\drivers\etc\hosts

# Add lines like:
203.0.113.10 example.com
203.0.113.10 www.example.com

Load the site in your browser. If everything is set correctly, you’ll be hitting the destination server.

Method B: curl with a Host header

This checks HTTP routing without touching your hosts file:

# Replace IP and domain
curl -I --resolve example.com:80:203.0.113.10 http://example.com/
curl -I --resolve example.com:443:203.0.113.10 https://example.com/

What to look for:

• HTTP status 200/301/302 as expected
• No unexpected redirect to the old server
• No PHP fatal errors

Fix the common post-transfer breakages (before you switch DNS)

Most migration problems follow a few repeat patterns. Fix them now, while real users still land on the source.

1) PHP version or PHP extensions mismatch

If the destination runs a different PHP version, apps can fail immediately.

Common culprits include older ionCube loaders and missing extensions like intl or imagick.

In WHM:

• WHM → Software → MultiPHP Manager (set per-domain PHP versions)
• WHM → Software → EasyApache 4 (install missing modules)

Quick check from CLI (destination):

php -v
php -m | egrep 'intl|imagick|redis|opcache|ionCube' || true

2) Wrong IP bindings (especially for services and SSL)

New server, new IPs. Verify the bindings.

After transfer, confirm each domain points to the correct IP inside cPanel/WHM.

In WHM check:

• WHM → Account Functions → List Accounts (verify dedicated/shared IP)
• WHM → SSL/TLS → Manage SSL Hosts (verify cert installed for each vhost)

If you’re relying on AutoSSL after cutover, decide that upfront.

Then keep your validation steps consistent.

If renewals later get messy, this workflow saves time: cPanel AutoSSL Troubleshooting Tutorial (2026).

3) WordPress cache paths, permissions, and hardening drift

Transfers can preserve permissions that no longer match your destination hardening.

For WordPress hosts, review permissions and hardening after the move and before you cut DNS.

This guide is written for that window: WordPress hardening tutorial (2026).

Mail migration: verify delivery, mailboxes, and DNS records

Email is where “mostly fine” becomes tickets fast.

Verify three things: mailboxes exist, IMAP works, and the destination’s DNS mail records are ready.

Step 1: confirm mailboxes came across

On destination, spot-check maildirs. Paths vary by configuration, but this is typical:

# Replace USERNAME and DOMAIN
ls -lah /home/USERNAME/mail/DOMAIN/ | head

Step 2: check Exim queue and logs after a test email

Send a test message from an external mailbox to an address on the migrated domain.

Do this either after cutover, or by temporarily forcing mail routing.

On destination:

exim -bp | head
# Recent mail activity
tail -n 80 /var/log/exim_mainlog

Step 3: prepare SPF/DKIM/DMARC and rDNS for the new server

If the destination IP changes, update mail DNS records and ideally rDNS.

If you skip this, deliverability will wobble.

For domain-level records, follow: Set Up DKIM, SPF, And DMARC For A Domain.

If you run mail through WHM on the destination, use WHM’s email deliverability interface.

Validate end-to-end.

This runbook covers what matters for cPanel mail in 2026: WHM Email Deliverability Tutorial (2026).

Common mistake: you update the site’s A record but leave MX pointing to the old server.

That creates split delivery. Some senders keep hitting old inboxes.

Do a “parallel run” sync to catch last-minute changes

Your sites won’t pause just because you’re migrating.

Before cutover, run another transfer pass or re-transfer selected accounts. This picks up fresh uploads, plugin updates, and recent mail.

WHM Transfer Tool supports repeat transfers. Treat overwrite options with respect.

Recommended approach:

• Schedule a short content freeze window for dynamic sites (store checkouts, forum posts, etc.).
• Re-run the transfer for the account(s) during the freeze.
• Verify again using hosts file/curl.

DNS cutover: switch traffic with minimal downtime

Once the destination tests clean, switch DNS.

The exact change depends on where authoritative DNS is hosted.

Scenario A: DNS hosted externally (registrar/Cloud DNS)

Update the relevant A/AAAA records to the destination server IP.

If you split records for web and mail, update those as well.

Verify the change:

# Replace with your domain
dig +short A example.com
dig +short A www.example.com
dig +trace example.com | head -n 30

Scenario B: DNS hosted on the cPanel server (nameservers point at it)

You have two clean options:

• Keep nameservers the same (ns1/ns2 remain), but point those nameservers’ A records to the destination IPs.
• Change nameservers to new ones hosted on the destination (requires registrar change and propagation time).

Keeping nameservers is usually the least disruptive path.

If you’re migrating to new infrastructure at HostMyCode and want stable nameserver hosting, you can also keep DNS external via your domain provider.

If you need a registrar move or new domain, domains at HostMyCode keeps billing and DNS management under one roof.

Post-cutover verification: a tight checklist you can run per account

After DNS starts resolving to the destination, validate in this order:

1. DNS resolution
   • dig +short A example.com matches destination IP
   • dig +short MX example.com matches your mail plan
2. Web
   • curl -I https://example.com returns expected status
   • Login works for admin areas (WordPress /app admin / cPanel redirects)
3. TLS
   • Certificate matches the domain and is not expired
   • No mixed content warnings on key pages
4. Database
   • Dynamic pages load without DB errors
   • Background jobs (cron) run normally
5. Email
   • Inbound email arrives
   • Outbound email sends without queue buildup
   • SPF/DKIM/DMARC validate for the new IP

Keep the source server online for a short overlap period (often 24–72 hours).

Some resolvers ignore low TTLs, even when you plan well.

If you moved mail, consider setting the old server to reject new inbound mail for migrated domains after cutover.

That prevents stray deliveries from landing in old mailboxes.

Clean up: remove old server risk without breaking anything

Once traffic and mail look stable on the destination:

• Take a final snapshot/backup of the source server (for a defined retention period).
• Disable outbound mail on the source to avoid accidental sends.
• Lock down SSH access on the source or power it off entirely.

If you want a recovery plan that includes tested restores (not just “we have backups”), adapt the runbook here: Disaster recovery tutorial (2026).

Troubleshooting quick hits (what fails most often)

Transfer Tool can’t connect to source (SSH failure)

• Confirm SSH port: ss -lntp | grep ssh on source
• Check firewall rules on source allow destination IP
• Verify DNS: the hostname you entered resolves to the right IP

Site loads, but admin logins fail

• Check PHP sessions path permissions
• Confirm time sync: timedatectl (bad time breaks auth cookies)
• Look at domain error logs in cPanel and Apache/Nginx logs on the destination

Email sends but lands in spam after migration

• Update SPF to include the new sending IP
• Enable DKIM signing for the domain on the destination
• Set rDNS (PTR) for the new IP to match a valid hostname

Summary: the safest way to migrate accounts with minimal downtime

The least risky pattern has three phases: transfer and test in parallel, sync again during a short freeze, then cut DNS after lowering TTLs.

WHM Transfer Tool handles the copying.

Your DNS plan and verification checklist prevent the real failures: missing mail, stale caches, and TLS surprises.

If you’re moving to new infrastructure and you care about consistent performance under load, start on a HostMyCode VPS.

Or step up to managed service if you don’t want to babysit cPanel updates. Either way, keep the source online briefly and verify account-by-account.

FAQ

Do I need to shut down the source server during the transfer?

No. You can transfer while the source is live.

Plan a short freeze and re-sync right before DNS cutover to avoid missing recent changes.

Should I migrate web first and mail later?

If your mail volume is high or deliverability risk is unacceptable, migrating web first can reduce risk.

Just keep MX unchanged until you’re ready, and avoid splitting mailboxes across servers.

How long should I keep the old server online after DNS cutover?

Typically 24–72 hours. Some resolvers ignore low TTLs.

The overlap prevents lost traffic and gives you a rollback window.

Will AutoSSL work immediately after I switch DNS?

Usually yes, once the domain resolves to the destination and HTTP validation succeeds.

If it fails, it’s commonly DNS propagation, wrong vhost IP, or DCV rate limits. Use the AutoSSL troubleshooting workflow linked above.

What’s the cleanest way to verify I’m hitting the new server?

Edit your local hosts file or use curl --resolve.

Browser testing alone can lie because of cached DNS or redirects.