Moving cPanel accounts to another server is a routine operation with an unforgiving detail: the copy is straightforward, and the switchover is where sites break. Getting the order right is most of the job.
Two ways to do it
Transfer Tool pulls accounts directly from the old server over SSH. You give it the source server's address and root credentials, it lists the accounts, and you choose which to bring.
This is the right method whenever you have root on both machines. It handles multiple accounts in one run, keeps packages and reseller ownership intact, and does not require you to move files by hand.
Backup and restore is the fallback. Generate a full cPanel backup on the old server, move the archive, restore it on the new one. Slower and more manual, and it works when you only have cPanel access rather than root.
Before you start
Three checks that prevent most failures.
Disk space on the destination. A transfer needs room for the archive and the extracted account at the same time. Running out mid-restore leaves a half-created account that has to be removed before retrying.
PHP versions. If the old server ran a version the new one does not have, sites come up broken after the move and the cause is not obvious. Install the versions you need before transferring, not after.
SSH access between the machines. Transfer Tool connects on the SSH port, and a firewall on either side blocks it. Test the connection first. The tool's own error message for this is not always clear.
Running a transfer
In WHM, open Transfer Tool. Enter the source server address, the SSH port and root credentials.
It connects and lists what it found: accounts, packages, and reseller privileges. Select what you want. Bringing packages across first is worth doing, because accounts restored without their package land on defaults you then have to correct one at a time.
Start the transfer and watch the log instead of the progress bar. Individual accounts can fail while the overall run reports success, and the log is where that shows.
Lower the DNS TTL first: days before
This is the step that decides how smooth the switchover is, and it has to happen well before the move.
TTL tells the world how long to cache your DNS records. A typical value is 14400 seconds. Four hours, which means after you point the domain at the new server, some visitors keep reaching the old one for up to four hours.
Drop it to 300 seconds a day or two ahead. The old TTL has to expire before the new one takes effect, which is why doing this at the moment of the move accomplishes nothing.
Then the cutover takes minutes rather than hours. Raise it again afterwards. Understanding DNS propagation walks through the mechanics.
The gap nobody plans for
Between copying an account and pointing the domain at the new server, the site is live on the old one and still receiving orders, comments and mail.
Everything that arrives in that window lands on the old server and is not in the copy you made. On a shop, that is missing orders.
Two ways to handle it. Either put the site into maintenance mode for the switchover so nothing new arrives, or re-sync the database and mail immediately before flipping DNS. Transfer Tool can re-run a single account, which makes the second option practical.
Test before pointing the domain
The account exists on the new server and the domain still points at the old one. You can and should check it anyway.
Edit your local hosts file to map the domain to the new server's IP. Your machine then reaches the new server while everyone else continues to reach the old one.
Load the site properly. A page with images, a form, the admin login. This is your only chance to find a broken database connection or a missing PHP extension without visitors seeing it.
Mail is the part that gets forgotten
Websites move visibly. Mail moves quietly and breaks quietly.
MX records have to be updated along with the site's records, and mail already in transit is delivered to whichever server the sending system resolved. Expect a small amount to land on the old server after the switch.
So keep the old server running for several days. Not as a fallback for the website. That would split your data across two machines, but so late mail is not bounced, and so you can retrieve anything that landed there.
Certificates do not come along by themselves
Certificates are usually included in the transfer, and they are tied to the domain in place of the server, so they remain valid.
Renewal is the question. AutoSSL on the new server has to be able to verify the domain, which it can only do once DNS points here. Run AutoSSL after the cutover and confirm each domain is covered rather than assuming.
After the move
Check the things that are configured per-server rather than per-account, because those do not travel.
Cron jobs transfer, and the paths inside them may not match if the new server is laid out differently. Any absolute path in application configuration has the same problem. A hardcoded /home/olduser/ in a config file is a common breakage when the username changed.
Then watch the error logs for a day rather than only checking that the homepage loads. Understanding cPanel error logs walks through finding them.
Keep the old account until you are sure
Do not terminate anything on the old server for at least a week. Suspend it if you want to guarantee nobody is reaching it, but keep the data.
Problems from a migration surface days later. A monthly cron that never ran, a form that stopped emailing, an upload directory that came across empty. Having the original still on disk turns each of those into a copy operation instead of a restore from backup.
