cPanel Migration Tutorial (2026): Move Accounts to a New VPS with WHM Transfer Tool and Low Downtime DNS Cutover

A cPanel move can be clean or chaotic. The difference is usually process. This cPanel migration tutorial walks you through a WHM transfer to a new VPS. You’ll do preflight checks, safe TTL changes, incremental syncs, and a controlled DNS cutover.

You’ll use WHM’s Transfer Tool as the primary method. Then you’ll verify websites, email, SSL, cron jobs, and DNS behavior before switching traffic.

The steps below assume you control both cPanel/WHM servers (VPS or dedicated). That’s the common reseller or agency setup.

What you’ll migrate (and what you should plan to rebuild)

Before you touch DNS, write down what must survive the move. WHM transfers a lot. Some items still need hands-on work.

Typically migrates well: cPanel accounts, home directories, databases, email mailboxes (IMAP), forwarders, cron jobs, DNS zones (if you choose), SSL data (varies by setup), and most service configs tied to accounts.
Often needs manual attention: custom firewall rules, third-party security agents, custom Apache/Nginx reverse-proxy configs, non-standard PHP extensions, and bespoke systemd services.
Licensing: cPanel licenses are tied to IP. Plan licensing for the destination server before the final cutover.

If you’re standing up a new destination server, start with a stable base. A HostMyCode VPS works well for migrations because you control WHM, DNS behavior, and mail flow end-to-end.

Prerequisites checklist (do this first, or pay for it later)

Keep this list strict. Each item prevents a common failure mode.

Source and destination: Both are running supported cPanel/WHM builds for 2026 and have enough disk headroom for at least 1.3× the total account data you’re moving.
Root access: Root SSH access to both servers, or at least WHM root access plus SSH for troubleshooting.
Network access: Destination can reach source over SSH (TCP 22) and WHM (typically 2087). If you restrict admin access, temporarily allowlist the destination IP.
Time window: Pick a cutover window. Even “near-zero downtime” migrations go smoother during quiet hours.
DNS plan: Know where authoritative DNS is hosted today (server, third-party DNS, registrar). You’ll cut over either nameservers or A/AAAA records.
Mail plan: Decide if you’ll keep mail on cPanel, route via an external service, or split during cutover.
Backups: Take a known-good backup before any transfer. If you haven’t set that up yet, use WHM backups and remote storage as your baseline.

For ongoing resilience after the move, keep a real WHM backup routine in place. HostMyCode has a solid walk-through here: cPanel Backup Tutorial (2026): Configure WHM Backup, Remote Storage, and Restore Testing.

Step 1: Lower DNS TTL ahead of time (the simplest downtime reducer)

TTL changes don’t apply instantly. They take effect as caches refresh.

Make this change 24–48 hours before cutover.

Find the current TTL for the key records (A/AAAA for the website, MX for mail, and any subdomains like cpanel, mail, webmail).
Set TTL to 300 seconds (5 minutes) for:
- example.com and www.example.com A/AAAA
- MX records (if you’re moving mail too)
- Any API/app subdomains that must cut over quickly

Quick verification commands from your workstation:

dig +nocmd example.com A +noall +answer
dig +nocmd example.com MX +noall +answer

If you want a cutover that’s safer than “change IP and hope,” look at DNS failover (health checks, fast cutovers, and rollback planning). See: DNS Failover Setup Guide Tutorial (2026): Low TTL, Health Checks, and Fast Cutovers.

Step 2: Prepare the destination cPanel server (baseline configs that prevent surprises)

Set up the destination like it will run long-term. This is where you prevent “mystery breakage” after cutover.

Managed hosting can also save time. With managed VPS hosting, you can hand off parts of OS hardening and service verification. That lets you focus on the transfer and client coordination.

OS and hostname

Set a fully qualified hostname (FQDN) that resolves to the destination IP (forward and reverse DNS ideally).
Confirm time sync (chrony/systemd-timesyncd) and correct timezone if your stack expects it.

Storage layout and quotas

Check free space: account data + databases + mail can spike during transfer.
Confirm quotas are enabled (common requirement for hosting environments).

PHP, web server stack, and compatibility

Match what your accounts already rely on. If the source runs EasyApache 4 with multiple PHP versions, make sure the destination supports the same before you migrate anything.

“We’ll fix PHP later” is how a routine move turns into a weekend of break/fix.

For a clean PHP-FPM baseline after the move, this guide helps you set sane pools and avoid CPU thrash: PHP-FPM Performance Tuning Tutorial (2026): Complete Configuration Guide.

Firewall and SSH

Confirm you can administer the server safely and consistently. For a production-ready SSH posture (keys, allowlists, auditability), follow: SSH Lockdown Tutorial (2026).

Step 3: Preflight the source server (reduce what has to move)

Don’t migrate problems you already know about.

Update account backups: Run a fresh backup cycle in WHM if your policy allows it.
Clear obvious bloat: Old logs, stray cache directories, and oversized tmp folders inside user accounts.
Check for compromised accounts: If you’ve seen spam or malware, clean first. Otherwise you’re just moving the incident.
Inventory disk hogs: Large public_html, mail, or database directories will set your transfer timeline.

Useful quick checks on the source (run as root):

# Biggest accounts by home directory size
for d in /home/*; do du -sh "$d"; done 2>/dev/null | sort -h | tail -n 20

# Maildir size for a specific cPanel user
du -sh /home/USER/mail 2>/dev/null

Step 4: Run the WHM Transfer Tool (the right way)

WHM’s Transfer Tool is built for this job. Use it instead of manually copying /home. Only skip it if you have a specific edge case you can justify.

4.1 Start the transfer

On the destination server, log into WHM.
Go to Transfers » Transfer Tool.
Enter the source server hostname/IP, SSH port, and root credentials (or an SSH key).
Choose the transfer type:
- Copy (recommended): leaves the source intact for rollback.
- Restore: used when you’ve already created and downloaded account backups.
Select the accounts to move. If you’re migrating many accounts, work in batches (10–30). This makes it easier to monitor and react.

4.2 Transfer options that matter

Package settings: Keep consistent limits (disk/bandwidth) to avoid “sudden suspensions.”
DNS zones: Only transfer zones if your destination server is authoritative DNS. If DNS is external, manage records there.
SSL data: Migrate where possible, but still plan to re-issue/validate AutoSSL post-transfer.
MySQL: WHM handles this, but large databases can dominate the timeline. Schedule around that reality.

4.3 Watch logs like a sysadmin, not like a tourist

The Transfer Tool UI is fine for progress. The logs tell you what is actually happening.

# On the destination, watch transfer-related logs (paths may vary by build)
tail -f /usr/local/cpanel/logs/error_log

If a transfer fails, write down which phase failed (package, restore, DNS, MySQL, mail). Fix the root cause, then re-run only the affected accounts.

Step 5: Post-transfer validation (web, email, DNS, SSL, cron)

Don’t cut over because “the accounts are there.” Cut over because the parts users depend on behave correctly.

5.1 Validate websites without changing DNS (hosts-file testing)

Use your workstation’s hosts file to browse the site on the new server. The public will still hit the old server.

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

Add:

NEW_SERVER_IP example.com www.example.com

Then check what matters:

Homepage loads cleanly and without mixed-content warnings
Login pages work (WordPress admin, app dashboards)
File uploads work (permissions)
Critical forms submit and send mail (contact forms, checkout)

5.2 Confirm PHP and extensions per account

In WHM/cPanel, confirm each account is on the expected PHP version and handler. A common failure is landing on a newer default PHP. That can break older plugins or extensions.

5.3 Validate email (IMAP/SMTP) and mailbox presence

For a quick sanity check, compare mailbox counts before cutover. On the destination, spot-check several mailboxes per domain via webmail and IMAP.

If you need to brief users or standardize client settings, keep this reference handy: cPanel Email Setup Tutorial (2026).

5.4 AutoSSL and certificate checks

Even if certificates transferred, run AutoSSL after the move. That ensures the destination can issue and renew without surprises.

In WHM: SSL/TLS » Manage AutoSSL
Run AutoSSL for the transferred accounts.
Verify key hostnames: example.com, www, mail, cpanel, webmail (depending on your setup).

If you want a deeper SSL refresher, use: cPanel SSL Certificate Management Tutorial (2026).

5.5 Cron jobs

Cron jobs usually migrate cleanly. Scripts often rely on absolute paths or specific PHP binaries.

For each important account, run a dry test. Execute the script manually over SSH as the user.

# Example: run as the cPanel user
su - USER -s /bin/bash
php -v
php /home/USER/public_html/path/to/cron.php

Step 6: Plan the cutover (choose one of two DNS strategies)

There are two standard approaches. Choose based on where your authoritative DNS lives.

Option A: Change A/AAAA (and MX) records at your DNS provider

Best for: external DNS providers, Cloud DNS, registrar DNS, or any setup where authoritative DNS is not the cPanel server.
Cutover action: update A/AAAA for @ and www to the new IP.
Email: if mail moves too, update MX, plus SPF/DKIM/DMARC records as needed.

Option B: Change nameservers (move authoritative DNS to the new server)

Best for: hosting resellers who want DNS managed inside WHM/cPanel.
Cutover action: change nameservers at the registrar to the new ns1/ns2.
Warning: nameserver changes can feel less predictable. Caching and registrar propagation can vary. Lower TTL helps, but you still need a rollback plan.

Step 7: Execute the DNS cutover with a controlled freeze

For any site that writes data, plan a short “write freeze.” This prevents the two servers from diverging while DNS is mid-flight.

7.1 Freeze content changes

For WordPress/WooCommerce: pause editing, updates, and checkout changes during the final sync window.
For apps: temporarily disable writes or put the site in maintenance mode if practical.

7.2 Do a final sync (if you have ongoing changes)

WHM Transfer Tool supports incremental behavior depending on method and data types. High-change directories sometimes need a targeted rsync during the freeze window.

Only do this if you know what you’re doing.

Example (careful, run from destination; adjust paths and users):

rsync -aHAX --delete -e ssh root@SOURCE_IP:/home/USER/public_html/ /home/USER/public_html/

Don’t blindly rsync mail/ during active delivery. If you must, coordinate a brief inbound pause. Otherwise, some messages may land on the old server during propagation.

7.3 Change DNS

Update A/AAAA records (and MX if moving mail).
Verify externally from multiple resolvers:

dig +short example.com A @1.1.1.1
dig +short example.com A @8.8.8.8

Step 8: Handle email safely during propagation

Email is where low-downtime moves most often go sideways. Messages keep arriving while DNS caches update. Treat mail as its own mini-migration.

Recommended approach for cPanel-to-cPanel mail moves

Keep the old server accepting mail for 48–72 hours after DNS cutover.
Ensure the old server can still deliver outbound mail without being blocked (rDNS, SPF alignment).
After most DNS caches flip, do a final mailbox sync or re-run mail transfer for the affected accounts.

If deliverability is on your post-migration checklist, these references cover the usual causes of “everything started landing in spam”:

Step 9: Post-cutover checks (the first 60 minutes)

This is your smoke-test window. Keep it tight. Check the things that break loudly.

HTTP status and redirects: confirm http to https redirects, www/non-www canonical behavior.
SSL: check certificate chain and hostname coverage.
Admin paths: WordPress login, cPanel login for at least one migrated account.
PHP errors: look at domain error logs for new warnings and fatal errors.
Email send/receive: send a test email to a major provider, then reply back.
Server load: load averages, RAM usage, and disk I/O. Transfers often leave background jobs running.

If you need a structured “why is this slow after moving?” workflow, keep this bookmarked: VPS Troubleshooting Tutorial (2026): Diagnose Slow Website Response.

Step 10: Decommission the old server (only after you prove stability)

Don’t shut down the source server on cutover day. Keep it available for rollback, straggler caches, and mail drift.

Keep the old server online for at least 7 days for business-critical sites. Keep it longer if you serve global traffic with stubborn caches.
Monitor access logs on the old server. When requests drop to near-zero, you’re close.
Set a final reminder to:
- Remove temporary allowlists and any “migration-only” firewall exceptions
- Cancel old licenses cleanly
- Archive or snapshot the old server before deletion

Troubleshooting: common migration failures and the fastest fixes

Site loads but admin is broken: PHP version mismatch. Set the correct PHP version per domain/account and retest.
Random SSL warnings: missing www SAN or wrong vhost mapping. Re-run AutoSSL, then validate the vhost uses the expected certificate.
Email clients can’t connect: users still pointing to old server hostnames. Ensure mail.example.com resolves to the new IP and has a valid certificate.
Outbound email goes to spam: SPF/DKIM/DMARC not updated, rDNS missing, or IP reputation issues. Fix DNS auth first; then review mail logs.
Disk fills unexpectedly: mail spools, backups, and transfer temp files. Audit /home, /var/spool, and WHM backup destinations.

Summary: a repeatable cPanel move that doesn’t punish your customers

A good migration is intentionally boring. Lower TTL early. Build the destination correctly. Transfer in batches. Validate with hosts-file testing.

Then cut over with a short write freeze and clear verification.

After the switch, leave the old server up long enough to catch stragglers and late mail. If you want a stable landing spot for your next transfer, start with a HostMyCode VPS or step up to managed VPS hosting when you’d rather spend time on customer work than server housekeeping. HostMyCode’s focus is simple: Affordable & Reliable Hosting that you can operate confidently.

If you migrate cPanel accounts for clients, you’ll get cleaner outcomes on a VPS that’s sized for steady performance and easy recovery. HostMyCode offers HostMyCode VPS plans, plus managed VPS hosting if you want help covering the operational checklist around your migration.

FAQ

How long does a cPanel migration usually take?

For small accounts, minutes. For mail-heavy or database-heavy accounts, hours. Disk I/O on both servers is usually the limiting factor, not network speed.

Should I migrate DNS zones with WHM Transfer Tool?

Only if the destination will be authoritative for DNS. If your DNS lives at your registrar or a third-party provider, keep DNS there and update records manually.

Can I migrate without any downtime?

You can get close for read-heavy sites by lowering TTL early and doing a short write freeze for the final sync. Truly zero downtime requires application-level strategies (not typical for shared hosting workloads).

What’s the safest way to handle email during propagation?

Keep the old server receiving mail for 48–72 hours after cutover, and verify mail.example.com points to the new server with valid SSL. Expect some straggler deliveries while caches expire.

What should I do if a transferred site is slow on the new server?

Check PHP handler/version, caching, and server resource saturation first. Then follow a structured triage process like HostMyCode’s slow-response troubleshooting tutorial to find the bottleneck quickly.