How to Move All cPanel Accounts from One Server to Another

Migrating all cPanel accounts between servers is the process of transferring every hosted domain, its files, MySQL databases, email accounts, DNS zones, SSL certificates, and cron jobs from a source WHM instance to a destination WHM instance — typically using the built-in WHM Transfer Tool over an authenticated SSH connection. When executed correctly, this process requires zero manual file copying and preserves all account metadata intact.

This guide covers the complete migration workflow at a production level: pre-flight checks, Transfer Tool configuration, DNS cutover strategy, post-migration validation, and cleanup — including edge cases that cause silent failures in real-world environments.

Prerequisites and Pre-Migration Checklist

Skipping preparation is the single most common cause of failed or incomplete cPanel migrations. Before touching either server, verify every item below.

Root access on both servers. The WHM Transfer Tool authenticates to the source server via SSH as root. If the source server has PermitRootLogin no in /etc/ssh/sshd_config, you must either temporarily enable it or pre-configure SSH key-based authentication for root.

Compatible cPanel/WHM versions. cPanel can transfer accounts from older versions to newer ones, but not in reverse. A destination running cPanel 110 can pull from a source running cPanel 98, but the opposite will fail. Check versions in WHM under Server Information or run:

cat /usr/local/cpanel/version

Matching or compatible PHP and MySQL versions. If the source runs PHP 7.4 and MySQL 5.7 while the destination runs PHP 8.2 and MySQL 8.0, applications may break after transfer even if the files copy cleanly. Audit installed PHP versions and default handlers on both servers before proceeding.

Sufficient disk space on the destination. The Transfer Tool requires free space equal to at least the total compressed size of all accounts being transferred, plus headroom for extraction. Run df -h on the destination and compare against the total account disk usage visible in WHM's List Accounts view on the source.

Firewall rules permitting SSH between servers. The destination server initiates an outbound SSH connection to the source. Ensure port 22 (or the custom SSH port) is open on the source server's firewall for the destination's IP address.

Full account backups on the source. Generate a full cPanel backup for every account before starting. This is your recovery point if the transfer corrupts or partially copies an account.

/scripts/pkgacct username /backup/directory

If you are running your new environment on a VPS Hosting plan, confirm that your VPS has cPanel/WHM already licensed and installed before proceeding. A fresh cPanel installation requires a valid license tied to the server's IP address.

Step 1: Install and Configure cPanel/WHM on the Destination Server

If cPanel is not yet installed on the destination, run the official installer as root. This process takes 20–45 minutes depending on hardware:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

After installation completes, access WHM at https://your-server-ip:2087 and complete the initial setup wizard. Pay particular attention to:

• Hostname: Set a fully qualified domain name (FQDN) that resolves to the server's IP. An unresolvable hostname causes mail delivery failures after migration.
• Nameservers: Configure your nameserver hostnames and their IP addresses if you plan to host DNS on the new server.
• PHP handlers: Install the same PHP versions available on the source server using WHM > MultiPHP Manager to avoid application compatibility breaks.
• MySQL/MariaDB version: Match the source server's database engine version where possible, or test application compatibility with the newer version before migrating production accounts.

For teams managing multiple client environments, a VPS with cPanel provides a pre-configured environment that eliminates the manual installation phase entirely.

Step 2: Configure the WHM Transfer Tool

The WHM Transfer Tool is the authoritative method for bulk account migration. It handles packaging, transfer, extraction, and account creation atomically for each account.

2.1 Access the Transfer Tool

On the destination server, log into WHM and navigate to:

WHM > Transfers > Transfer Tool

This is a critical point that confuses many administrators: the Transfer Tool is always run from the destination server pulling accounts from the source — not the other way around.

2.2 Connect to the Source Server

Enter the following connection details:

• Remote Server Address: IP address or hostname of the source server
• Remote SSH Port: Default is 22; use the actual port if it was changed (check /etc/ssh/sshd_config on the source for the Port directive)
• Authentication method: Root password or SSH key (key-based is strongly preferred for security and reliability)

To use SSH key authentication, copy the destination server's root public key to the source:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Once connected, the Transfer Tool queries the source server and returns a list of all cPanel accounts, packages, and reseller configurations.

2.3 Select Accounts and Transfer Scope

You can select all accounts or a subset. Beyond individual accounts, the Transfer Tool also offers:

• Packages: Transfer hosting plan definitions so accounts retain their resource allocations
• DNS Zones: Copy all zone files, which is essential if the new server will act as the authoritative nameserver
• Reseller Privileges and ACLs: Preserve reseller account configurations and their associated permissions

2.4 Configure Transfer Options

Two settings here have significant operational impact:

Express Transfer automates the DNS cutover by updating the DNS zones on the source server to point to the destination's IP immediately after each account copies. This minimizes the window during which a domain resolves to the old server. Use this only if the destination is ready to serve traffic immediately and you have confirmed all applications are functional.

Mail Routing: Set this to Automatic unless you have a specific reason to force local or remote routing. Incorrect mail routing is one of the top causes of email delivery failures post-migration.

2.5 Initiate the Transfer

Click Copy to start the process. WHM will:

1. SSH into the source server
2. Run pkgacct to create a compressed archive of each account
3. Transfer the archive to the destination over SSH/SCP
4. Run restorepkg on the destination to extract and create the account
5. Log the result for each account

Monitor the live transfer log carefully. Errors for individual accounts do not stop the overall process — an account can silently fail while others succeed. Review the complete log after the transfer finishes and re-run failed accounts individually.

The transfer duration depends on total data volume and inter-server bandwidth. A server with 50 GB of account data over a 1 Gbps link typically completes in under 30 minutes. Over a 100 Mbps link, budget 60–90 minutes.

Step 3: DNS Cutover Strategy

DNS management is where migrations most often create extended downtime. Understanding propagation mechanics is essential for minimizing user impact.

3.1 Reduce TTL Before Migration

Ideally, 24–48 hours before the migration, reduce the TTL on all A records for hosted domains to 300 seconds (5 minutes). This ensures that once you update DNS records, the change propagates globally within minutes rather than hours. If you did not do this in advance, you must account for the existing TTL value as your maximum propagation window.

3.2 Update DNS Zones

If the new server is the authoritative nameserver for the domains, update the A records in each zone file via WHM > DNS Functions > Edit DNS Zone, changing the IP from the old server's address to the new one.

If domains use an external DNS provider or registrar DNS, log into each registrar or DNS management panel and update the A records manually. For bulk updates across many domains, most registrars offer API access or CSV import.

3.3 Update Nameserver Glue Records

If you are also migrating nameservers (e.g., ns1.yourdomain.com), you must update the glue records at the domain registrar — not just the zone file. Glue records are IP address mappings for nameservers registered under the same domain they serve. Failing to update glue records is a common oversight that causes complete DNS resolution failure for all hosted domains.

3.4 Verify Propagation

Use dig to check resolution from multiple geographic locations:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Cross-reference with a web-based propagation checker. Full global propagation typically completes within 1–4 hours when TTL was pre-reduced, or up to 48 hours when TTL was not reduced in advance.

If your domains are registered through Domain Registration, nameserver updates can be managed directly from the same control panel, simplifying the cutover process.

Step 4: Post-Migration Validation

Never declare a migration complete based solely on the Transfer Tool's success log. Validate each layer of the stack independently.

4.1 Web Application Functionality

Access each transferred domain directly by IP using a hosts file override (to bypass DNS propagation) and verify the application loads correctly:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Check for database connection errors, missing file paths, and broken application configurations. WordPress sites commonly fail if the wp-config.php database credentials reference localhost but the MySQL socket path differs between servers.

4.2 Database Integrity

Log into cPanel for each account and verify databases exist and are accessible. For critical databases, run an integrity check:

mysqlcheck -u root -p --all-databases --check

4.3 Email Functionality

Test inbound and outbound email for each account. Verify MX records resolve correctly and that the mail server is accepting connections on ports 25, 465, and 587. Check /var/log/exim_mainlog for delivery errors:

tail -f /var/log/exim_mainlog

For businesses with dedicated mail infrastructure, Email Hosting provides isolated mail environments that are not affected by web server migrations.

4.4 SSL Certificate Verification

Confirm that SSL certificates transferred correctly and are active. In WHM, navigate to SSL/TLS > Manage SSL Hosts and verify each domain has a valid, non-expired certificate. AutoSSL should automatically reissue Let's Encrypt certificates for any that failed to transfer, but trigger it manually to avoid waiting for the scheduled run:

/usr/local/cpanel/bin/autossl_check --all

If you manage certificates independently, SSL Certificates can be installed directly on the new server without dependency on the transfer process.

4.5 Cron Jobs and Scheduled Tasks

Cron jobs are transferred as part of the account package, but verify them in cPanel > Cron Jobs for each account. Pay particular attention to cron jobs that reference absolute file paths or server-specific environment variables that may differ on the new server.

Step 5: Cleanup and Post-Migration Hardening

5.1 Suspend Accounts on the Source Server

Once DNS has propagated and validation is complete, suspend all accounts on the source server via WHM > List Accounts > Suspend. Do not delete them yet. Suspension prevents new data from being written to the source while keeping it available as a fallback if a critical issue surfaces post-migration.

5.2 Post-Migration Backup

Create a fresh full backup of all accounts on the new server immediately after migration. The transferred state is your new baseline:

/scripts/cpbackup --force

Verify that backups complete successfully and are stored in a location separate from the server itself — ideally an off-server backup destination configured in WHM > Backup Configuration.

5.3 Performance Monitoring

Monitor the new server's resource utilization for 72 hours post-migration. Key metrics to watch:

• CPU load average (should remain below the number of CPU cores under normal load)
• Memory usage and swap activity
• Disk I/O wait (elevated I/O wait indicates storage bottlenecks)
• MySQL slow query log for queries that perform poorly on the new schema or engine version

Use top, iostat, and vmstat for real-time monitoring, and review cPanel's Resource Monitor in WHM for per-account resource consumption.

5.4 Decommission the Source Server

After a minimum 7-day observation period with no reported issues, you can decommission the source server. Before terminating the old server, archive a final backup to cold storage. This archive serves as a legal and operational record and costs very little to retain.

cPanel Account Migration: Method Comparison

Common Pitfalls and How to Avoid Them

Silent account transfer failures. The Transfer Tool continues processing even when individual accounts fail. Always read the complete transfer log — do not assume success because the tool finished without stopping.

MySQL user privilege mismatch. restorepkg recreates database users, but if a database username exceeds MySQL's 32-character limit (a common issue with legacy accounts), the user is created with a truncated name and the application's database credentials no longer match. Audit long database usernames before migrating.

Perl module and custom software dependencies. Applications that rely on custom-compiled Perl modules, Python packages, or system libraries installed outside of cPanel's managed paths will not transfer. These dependencies must be reinstalled manually on the destination.

Disk quota discrepancies. cPanel's disk quota system uses filesystem-level quotas. After migration, quotas may not reflect accurately until the quota recalculation script runs:

/scripts/fixquotas

ModSecurity rule conflicts. If the source server had custom ModSecurity rules or a different ruleset version than the destination, transferred sites may receive unexpected 403 errors. Review ModSecurity logs at /usr/local/apache/logs/error_log after migration.

Reseller account permission gaps. Reseller ACLs and package assignments transfer, but if the destination WHM has different feature lists configured, resellers may find their accounts have fewer or different capabilities than expected. Audit reseller configurations post-migration.

For high-traffic environments where downtime tolerance is near zero, consider running the migration on a Dedicated Server with dedicated resources, eliminating the risk of resource contention during the transfer and validation phases.

Technical Decision Matrix

Use this matrix to determine your migration approach based on environment characteristics:

FAQ

Can I migrate cPanel accounts without root access to the source server?

No. The WHM Transfer Tool requires root SSH access to the source server to run pkgacct and read all account data. If root access is unavailable, the only alternative is to request individual cPanel backup files (.tar.gz archives) from the source server's administrator and restore them manually using restorepkg on the destination.

How long does a full cPanel server migration take?

Transfer time depends on total data volume and network bandwidth between servers. A server with 100 GB of account data over a 1 Gbps dedicated link typically transfers in 15–30 minutes. Over shared or throttled connections, the same data may take several hours. DNS propagation adds an additional 1–48 hours depending on TTL values.

Will SSL certificates transfer automatically?

SSL certificates installed via AutoSSL (Let's Encrypt) do not transfer as valid certificates — they are reissued by AutoSSL on the destination server because they are bound to the server's IP and account. Commercially purchased certificates stored in cPanel do transfer as part of the account package, but must be verified and re-activated post-migration.

What happens to email on the old server during the migration window?

Email delivered to the old server during the migration window is stored in the old server's mail queue and user mailboxes. It does not automatically replicate to the new server. To prevent mail loss, either keep the old server's mail services running until DNS fully propagates, or configure the old server's Exim to relay incoming mail to the new server's IP during the transition period.

Can the WHM Transfer Tool migrate accounts between different operating systems (e.g., CentOS to AlmaLinux)?

Yes. The Transfer Tool is OS-agnostic at the application layer — it transfers cPanel account data, not OS-level configurations. Migrations from CentOS 7 to AlmaLinux 8 or Rocky Linux 8 are fully supported and are the most common migration scenario following CentOS 7's end-of-life. Verify that any custom system-level configurations (SELinux policies, custom kernel modules, non-cPanel services) are manually replicated on the destination.