cPanel Transfer Tool Tutorial (2026): Migrate Accounts to a New VPS with Sync, Mail Safety, and a Clean Cutover

Most hosting migrations fail for boring reasons. Common causes include a missed MX record, an expired SSL chain, or a mailbox that kept receiving mail on the old server. Another frequent culprit is a TTL that was never lowered. This cPanel Transfer Tool tutorial avoids those traps by treating the move as a staged process, not a single button click.

You’ll migrate one or many cPanel accounts from an old WHM server to a new VPS. You’ll keep data synced during the transition. You’ll validate sites and email before you touch DNS. Then you’ll cut over with a simple rollback plan.

The steps below assume root-level WHM access on both servers.

What you’ll build (and what you won’t)

• Build: a repeatable WHM Transfer Tool workflow with pre-checks, staged sync, controlled DNS, and verification.
• Not building: a new control panel, a reverse proxy layer, or a generic “copy files + hope” migration.

If you need a new destination server sized for hosting workloads, start with a HostMyCode VPS. If you’d rather not juggle OS updates, security baselines, and monitoring during cutover, managed VPS hosting keeps the platform side quieter while you migrate.

Prerequisites checklist (do these before touching Transfer Tool)

Transfer Tool is picky for a reason. If the fundamentals are off, it may still “work.” You’ll just spend hours cleaning up strange side effects.

• Compatible OS + cPanel: Source and destination should run supported cPanel & WHM for 2026 (stay on current stable; don’t migrate from an end-of-life OS).
• Root WHM access: You need WHM root login (or root SSH) on both servers.
• Disk headroom: Target server should have at least 25–30% free disk after migration. Transfers spike temporary usage.
• RAM headroom: Plan extra RAM during initial import because Apache/PHP-FPM/Exim will rebuild caches and indexes.
• Network access: Destination must reach source over SSH (port 22 or your custom port).

Step 1 — Freeze risk: lower DNS TTL and map current records

DNS is the one part you can’t rush once you start. Lower TTL first, then give it time to take effect.

1. In your DNS provider, reduce TTL for the zone’s A/AAAA, CNAME, and MX records to 300 seconds (or 600 if your provider caps it).
2. Do it at least 6–24 hours before cutover so resolvers actually pick up the new TTL.

Snapshot the current records so you have a known-good reference:

dig +short A example.com
dig +short AAAA example.com
dig +short MX example.com

# If you use nameservers with multiple records:
dig example.com ANY +noall +answer

If you want a strict cutover checklist, follow the pattern in our DNS cutover tutorial. The idea stays the same. Lower TTL early, test before switching, and keep rollback easy.

Step 2 — Make sure SSH won’t block the transfer

Transfer Tool moves data over SSH. If the source uses a custom port or strict firewall rules, prove connectivity from the destination before you queue any transfers.

# From the DESTINATION server:
ssh -p 22 root@SOURCE_IP "hostname; uptime"

If SSH runs on a custom port, don’t change it mid-migration. Put the port change in its own maintenance window.

If you need to move ports safely, use our SSH port change tutorial, then return here.

Step 3 — Prepare the destination WHM for clean imports

Messy destination settings produce messy results. You can end up with the wrong PHP handler or missing modules. Mail routing can also get confusing, and accounts may land on the wrong IP.

• Set the correct hostname: a stable FQDN like server2.example.com.
• Confirm main shared IP: the destination’s primary IPv4 should be ready for accounts that use shared IP.
• Match PHP expectations: if customers rely on a specific PHP version, confirm it exists on the destination.
• Time sync: NTP drift breaks SSL validation and makes logs misleading.

Quick checks:

# On destination
hostname -f
whmapi1 version | head
/usr/local/cpanel/bin/restartsrv_cpsrvd --status
/usr/local/cpanel/bin/restartsrv_exim --status
timedatectl status

If you’ve seen “random” SSL errors after a move, clock drift is often the real cause. Fix it cleanly with: VPS time sync troubleshooting.

Step 4 — Run the cPanel Transfer Tool (the right way)

In WHM on the destination server, go to:

WHM → Transfers → Transfer Tool

Then:

1. Add Remote Server: enter the source server IP/hostname and root credentials. Prefer SSH keys if you already manage them.
2. Fetch account list: WHM pulls available accounts and packages.
3. Select accounts: start with one low-risk account first, even if you plan a bulk move.
4. Copy options:
   • Copy home directory (yes)
   • Copy databases (yes)
   • Copy SSL certificates (yes, but you’ll still validate chains)
   • Copy mail (yes, but you’ll do a final sync later)
5. Start transfer: watch the transfer session logs.

Transfer Tool is efficient, but it can’t protect you from changes after the first copy.

Assume uploads, cache writes, and mailbox activity will continue until you force a stop.

Step 5 — Validate the migrated site without changing public DNS

Test the site on the new server while real users still hit the old one. A hosts-file override from your laptop is usually the quickest option.

On macOS/Linux:

sudo nano /etc/hosts

# Add:
NEW_SERVER_IP   example.com www.example.com

On Windows, edit C:\Windows\System32\drivers\etc\hosts as Administrator.

Now test the parts that actually break during migrations:

• Homepage loads
• Login works (WordPress admin, client area, etc.)
• Forms submit
• Uploads work
• Scheduled tasks/cron (if used)

For SSL, confirm the right certificate is installed and the chain is complete:

curl -I https://example.com

# Check certificate chain from your machine:
openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null

If SSL is wrong, fix it before DNS moves. This workflow is covered end-to-end in our VPS SSL certificate migration tutorial.

Step 6 — Make email safe: MX, local delivery, and the “split mailbox” trap

Email is where migrations lose data quietly. Users keep receiving messages on the old server while you test the new one. Then DNS flips, and the inbox looks “missing” mail.

Before cutover, decide where mail should deliver:

• If you host mail on the cPanel server, MX should point to the server’s hostname (or mail subdomain) that resolves to the correct IP.
• If mail is external (Microsoft 365, Google Workspace), don’t import mailboxes you don’t own, and don’t overwrite MX.

On the destination server, confirm Exim treats the domain as local after the account transfers:

# On destination
grep -R "^example.com" /etc/localdomains /etc/remotedomains 2>/dev/null || true

Plan the mail window: the cleanest approach is a short, explicit window where new delivery is paused or queued while you do the final sync.

• For low-volume domains, you can temporarily set the domain to remotemail on the source right before cutover. This stops local delivery on the old server.
• Alternatively, keep the source accepting mail, then run a final rsync/copy of mailboxes and switch MX immediately after.

If you hit spam spikes, queue buildup, or delivery failures after the move, you’ll want fast log visibility. Keep this reference close: Email log troubleshooting tutorial.

Step 7 — Perform a final “delta sync” for websites and mail

The first transfer gets you close. The last delta sync is what keeps your support inbox quiet.

Web content delta: if sites receive uploads or content edits, run a final sync right before cutover. Paths vary, but these are common:

• /home/USERNAME/public_html/
• /home/USERNAME/mail/ (maildir storage)

If you have root SSH on both servers, run rsync from the destination (replace placeholders):

# From destination, sync site files (example)
rsync -aHAX --delete -e "ssh -p 22" root@SOURCE_IP:/home/USERNAME/public_html/ /home/USERNAME/public_html/

# Sync maildir (can be large; run close to cutover)
rsync -aHAX --delete -e "ssh -p 22" root@SOURCE_IP:/home/USERNAME/mail/ /home/USERNAME/mail/

Database delta: if the site writes constantly, use a short maintenance window and re-dump/import. Another option is to schedule cutover during a quiet period.

Transfer Tool copies databases, but it can’t stop last-minute writes for you.

Step 8 — Cut over DNS with a rollback plan

Cutover should be boring. Change IPs and mail routes, not application code.

1. Update A/AAAA records to the destination server IP.
2. If you host mail on cPanel, update MX (and the mail hostname A record if needed) to point at the new server.
3. Keep the old server online for at least 24–72 hours as a rollback buffer.

Verify from multiple networks (mobile data + office ISP helps). DNS “propagation” issues often come from resolver caching close to the user. If users see the wrong IP or NXDOMAIN, use: DNS propagation troubleshooting tutorial.

Step 9 — Post-cutover checks you can run in 15 minutes

Run these in order. They catch the common “it worked in testing” failures.

• Confirm public DNS:

  dig +short A example.com
  curl -I http://example.com
  curl -I https://example.com

• Watch web logs for 404s/500s: on cPanel servers you’ll often check virtual host logs under /etc/apache2/logs/ (symlinks vary) or per-domain logs in users’ logs directories.
• Check email flow: send test messages from Gmail/Microsoft 365 to your domain and reply back. Confirm SPF/DKIM alignment hasn’t changed.
• Confirm AutoSSL: run AutoSSL for affected users in WHM if needed, especially if you changed IPs and have new vhost mappings.

If AutoSSL stalls or issues the wrong certificate, don’t troubleshoot by trial and error. Use: cPanel AutoSSL troubleshooting tutorial.

Step 10 — Harden and stabilize the new server after the move

Don’t mix migration work with security refactoring. Once traffic is stable, do a tight, practical hardening pass.

• Update OS packages and schedule safe reboots for kernel updates.
• Lock down SSH access (keys, allowlist IPs where possible).
• Set up backups immediately. Transfers are not backups.
• Enable account isolation if you host multiple customers on one VPS.

For a clear baseline, see our cPanel hardening tutorial and, for multi-tenant hosting, our cPanel account isolation tutorial.

Troubleshooting: the issues that show up most often

Transfer Tool can’t authenticate to the source

• Confirm SSH reachability from destination: ssh root@SOURCE_IP
• Check firewall rules on the source allow the destination IP.
• If the source changed SSH port, specify it in the Transfer Tool remote server profile.

Site works via hosts file, but breaks after DNS cutover

• You may have forgotten a www CNAME or a subdomain A record.
• Check if the domain uses CDN/proxy settings that still point at the old IP.
• Confirm the destination vhost matches the domain and has the correct document root.

Email arrives late or disappears around cutover

• MX might still point to the old server.
• Some clients cached the old IMAP server. Have users restart clients or re-check account server names.
• Run a final maildir sync again if you suspect split delivery.

FAQ

Should I migrate one account first or transfer everything at once?

Move one low-risk account first. It validates SSH, packages, PHP handlers, and SSL behavior. Then migrate in batches.

Do I need to disable the source server immediately after cutover?

No. Keep it online for 24–72 hours. That window lets you resync missed uploads and recover from DNS surprises without panic.

Can Transfer Tool move SSL certificates safely?

It can copy certificates, but you still need to verify the correct certificate is installed per vhost and the chain is complete after the move.

How do I avoid lost emails during migration?

Lower TTL early, plan a short “final sync” window, and verify MX and local delivery settings before and after cutover. Treat mail as its own cutover step.

Summary: a migration that doesn’t create a support backlog

The Transfer Tool works best when you treat it as one stage in a larger plan.

Lower TTL early, transfer, and test via hosts-file. Then run a final delta sync for web and mail. Finally, cut over DNS while the old server stays available.

If you want a destination server sized for cPanel workloads and ready for production hosting, pick a HostMyCode VPS. If you prefer hands-off operations after launch, managed VPS hosting keeps patching, monitoring, and stability on track while you run the business.