How to migrate an entire cPanel server: a step-by-step plan

To migrate an entire cPanel server, you move every account (websites, databases, mail, DNS zones, SSL, cron jobs) to the new server one account at a time, using full account backups, and then point each domain's DNS at the new IP. The safe way is to move in batches while the old server keeps running. Don't try to clone the disk onto the new machine: the operating system, PHP versions and paths almost never match.

This is the process we recommend for hosting companies and agencies running a cPanel or DirectAdmin server with tens to hundreds of accounts: inventory, DNS preparation, choosing a tool, moving in batches, handling mail and data that arrives mid-move, and the clean-up afterwards.

Why migrate an entire cPanel server?

The usual reasons:

• Licence cost. cPanel prices by account count, so the bill grows with every new customer. Our breakdown of cPanel licence cost in 2026 goes into the numbers.
• An end-of-life OS. Plenty of older servers still run CentOS 7, which reached end of life on 30 June 2024 and no longer gets free security updates.
• Hardware or provider. A faster or cheaper VPS, or one closer to your customers.
• A different panel. Consolidating several small servers, or moving to a panel whose architecture and pricing suit you better.

Whatever the reason, the goals are the same: no lost data, downtime measured in minutes, and no flood of "what happened to my site?" tickets.

Step 1: inventory the old server

Know exactly what you're moving before you pick a tool. On a cPanel server, as root:

# Accounts on the server
ls /var/cpanel/users

# Disk usage per account, largest first
du -sh /home/* 2>/dev/null | sort -rh | head -20

# Database sizes
mysql -e "SELECT table_schema, ROUND(SUM(data_length+index_length)/1024/1024) AS MB
          FROM information_schema.tables GROUP BY table_schema ORDER BY MB DESC LIMIT 20;"

Record, for each account:

Item	Why it matters
Size of files, databases and mail	Estimates transfer time and the new server's disk
PHP version	Old sites on PHP 5.x or 7.x may break on newer PHP
Whether mail is used	Decides how you handle incoming mail during the DNS switch
Who hosts DNS	Your nameservers, Cloudflare or the registrar
Paid SSL certificates	Reinstall them or move to Let's Encrypt
Shops and sites with constant orders	Need a quiet window and a plan for new data
PostgreSQL, unusual cron jobs, complex .htaccess	The things that get forgotten

That spreadsheet doubles as your checklist once the move is done.

Step 2: size the new server properly

Don't buy a new server identical to the old one and hope it fits. Add up the sizes from step 1, plus room for local backups and a year of growth. For CPU and RAM, how many WordPress sites a 4 GB VPS can host gives measured reference numbers. Set up your packages and resource limits before you start, so each account lands on the right plan.

Step 3: prepare DNS a day ahead

How long the switch really takes depends on your DNS TTLs. If an A record has a TTL of 14,400 seconds (4 hours), some visitors will keep reaching the old server for up to 4 hours after you change it.

1. Lower the TTL of A, AAAA and MX records to about 300 seconds, at least one old TTL before move day (usually a day ahead).
2. Find out who hosts DNS. If customers use your own nameservers (say ns1.yourcompany.com) running on the old server, you'll move the DNS zones too and update the glue records at your registrar.
3. Set reverse DNS (PTR) for the new IP with your VPS provider if the server sends mail.

Step 4: choose a migration tool

Method	Use it when	Pros	Cons
WHM Transfer Tool	cPanel to cPanel	Moves many accounts from a UI	The new server needs a cPanel licence too
pkgacct + restorepkg	cPanel to cPanel, scripted	Full control of each step	You copy files and track errors yourself
rsync plus manual database dumps	Any panel to any panel	Most flexible	A lot of manual work: accounts, mail, DNS, passwords
The target panel's importer	cPanel or DirectAdmin to a new panel	Recreates accounts, mail and DNS automatically	Limited to what the importer supports

On cPanel, a full account backup comes from the pkgacct script and is written as cpmove-USER.tar.gz:

/usr/local/cpanel/scripts/pkgacct alice /home/transfer

That file holds the account's websites, databases, mail, DNS and settings. Most migration tools, including other panels' importers, read this format.

Step 5: test one account, then move in batches

Never move a whole server in one click without a trial run. Pick a real but low-risk account (your own site, for example), move it, and check it on the new server before touching DNS. You can preview the site on the new server by editing your computer's hosts file:

203.0.113.20   example.com www.example.com

Check the home page, the admin area, contact forms, image uploads, webmail login and the PHP error log.

Then move in batches of, say, 20 to 50 accounts:

1. Static and rarely updated sites first.
2. Business sites with mail next.
3. Shops and sites with constant orders last, in your quietest hours.

Step 6: switch DNS and deal with data that arrives mid-move

A backup is a snapshot. Between taking it and DNS finishing its switch, the old server can still take orders, comments and mail. This is the part people forget.

Sites with constant orders or new content:

• Put the site in maintenance mode or pause checkout on the old server, take the backup, move it, switch DNS, then reopen on the new server.
• Or move it once as a rehearsal, then take a fresh backup right before the DNS switch and move that account again.

Mail:

• With low TTLs, most new mail reaches the new server within minutes.
• Mail that lands on the old server in the gap can be copied over with an IMAP sync tool such as imapsync, or customers can check the old webmail once.
• Update SPF records with the new IP, and DKIM records if the new server signs with a new key.

Step 7: after the move

• Check SSL has been issued for every domain on the new server.
• Watch error logs for the first few days: different PHP versions, missing extensions, old absolute paths (/home/user/public_html) in config files.
• Test backups on the new server, including a restore.
• Keep the old server running for one to two weeks, read-only if you can, in case something was missed. Then cancel it.
• Tell customers the new panel address and what has changed.

Migrating an entire cPanel server to ZoPanel

ZoPanel can move a whole cPanel or DirectAdmin server, as described in the migration documentation:

1. Go to Migrate in → Move a whole server and enter the old server's address and its root SSH password or private key. They're used for this move only and never stored.
2. Choose the source: The server's panel (ZoPanel detects cPanel or DirectAdmin, lists every account and makes each backup on the old server itself with pkgacct or DirectAdmin's own backup task), or A folder of backup files.
3. Connect and list accounts. The old server's host key is shown so you can check it. Accounts whose name already exists here are marked and skipped.
4. Tick the accounts, choose a package and click Move.

Accounts move one after another in the background, so you can close the browser. Each is backed up, downloaded, imported, and its temporary files are removed on both servers, so the disk only needs room for one account at a time. A failed account is reported and the next one still moves, and the log lists the DNS records to change. The old server is left untouched.

From cPanel, ZoPanel carries over the account and its panel password (kept when the hash format can be checked), main, addon and subdomain sites, the PHP version, MySQL databases and users, mailboxes and Maildir messages, forwarders, autoresponders, cron jobs, DNS zones, FTP accounts and SSL certificates. Left for you to do by hand: PostgreSQL databases, mdbox mailboxes and DirectAdmin domain pointers. Sites that rely on .htaccess can switch to Apache mode in their Tools tab (see Websites and PHP). Anything not carried over is listed in the log with the reason.

On licensing: the Free plan allows 3 hosting accounts, 10 websites and 10 databases across the server, enough to trial one or two accounts. Moving a full server of customers needs Pro (USD 49 a year, unlimited websites on one server) or the Lifetime launch offer (USD 199 one-time). Prices may change, so check pricing.

The takeaway

Migrating an entire cPanel server isn't hard if you treat it as a small project rather than a button: inventory, lower TTLs, test one account, move in batches, plan for orders and mail that arrive mid-move, and keep the old server for a while. Most migration incidents come from things that weren't on the inventory.

If you're thinking about leaving cPanel, install ZoPanel on a fresh VPS with curl -fsSL https://get.zopanel.net | sudo bash and move one account on the Free plan before you decide.

Frequently asked questions

How long does it take to migrate an entire cPanel server?

Transfer time depends on total data and the bandwidth between the servers, from a few hours to a few days for a large server. Customer-visible downtime is a different thing: with TTLs at about 300 seconds and DNS switched only after testing, each site is usually down for minutes.

Will customers have to change their passwords?

It depends on the tool. With ZoPanel, panel and SFTP passwords keep working when the old hash format can be checked, and database and mailbox passwords are kept when their format allows; when they can't be, the log says so and you set new ones.

Will email be lost during a server migration?

Mail already in mailboxes moves with the account. The risk is mail that reaches the old server before DNS has fully switched; lower TTLs in advance, and copy those messages with an IMAP sync tool or ask customers to check the old mailbox.

Should I move every account in one night?

Not on a large server. Batches let you catch shared problems (PHP versions, missing extensions) on the first few accounts instead of all of them, and keep support tickets at a manageable level.

How long should I keep the old server?

One to two weeks after the last account has switched DNS. During that time you can still recover a missed file, mailbox or database without going to backups.