Skip to content
Shahid Malla

Migration and backup

cPanel Server Migration and Backup Setup

I migrate cPanel servers with the WHM Transfer Tool and a planned DNS cutover, then set up local and off-site backups and prove them with restore tests. It is for hosting owners changing provider, hardware or operating system who cannot afford lost mail, broken sites or a backup that fails when needed.

By Shahid Malla, WHMCS developer and hosting infrastructure engineer · Updated

How does a cPanel server migration work?

A cPanel migration packages each account on the old server, restores it on the new one and then switches DNS, while the old server keeps serving visitors until you are ready. The WHM Transfer Tool on the destination server drives most of it.

The Transfer Tool connects to the source server with root credentials, lists the accounts and copies them in batches. Each account is packaged much as /scripts/pkgacct does it, into a cpmove archive, and restored with the same logic as /scripts/restorepkg. I move packages and feature lists first, so accounts land in the right plan. The package carries a lot, but not everything.

ItemTravels with the account?What I check
Home directory filesYesOwnership, permissions and symlinks that point outside the account.
Databases and database usersYesMySQL or MariaDB version differences, collations and SQL modes, which can break older applications.
Mailboxes, forwarders, filtersYesA final sync for messages that arrive during DNS propagation.
Per-account cron jobsYesPaths or URLs that mention the old hostname or IP.
Installed SSL certificatesYesAutoSSL cannot renew until the domain's DNS points at the new server.
DNS zonesYesRecords that contain the old IP, such as A records and SPF.
Dedicated IPsNoNew addresses are mapped to accounts by hand.
Server-level settings: root cron, custom Exim rules, ModSecurity rules, firewall rules, Tweak SettingsNoRebuilt and compared line by line.
cPanel licenseNoA new license for the new IP.

How do I cut over to a new server with little downtime?

Lower the DNS TTL first, test the new server through a hosts-file override, run a final sync and then change the records. Each step shrinks the window in which a visitor could land in the wrong place.

  1. Lower the TTL. Set the zones to a few minutes, for example 300 seconds, at least one old-TTL period before cutover so resolvers already hold the short value.
  2. Test with a hosts file. Add a line like the one below to your computer's hosts file, so the domain resolves to the new IP on your machine only. Then check pages, logins, uploads, forms, cron-driven features and mail.
  3. Freeze and sync. At a quiet time, pause changes on shops and forums, then run a final transfer of databases and mail.
  4. Switch. Change the A records, or the nameserver glue if the server hosts its own DNS. Watch /var/log/exim_mainlog and the web logs on both servers as traffic moves.
  5. Keep the old server. Leave it running until its logs go quiet, then sync mail one last time.
203.0.113.10  example.com www.example.com

Which settings depend on the server's IP address?

More settings depend on the IP than most owners expect, and each one fails quietly until someone notices.

  • Licenses. The cPanel license and any other software license bound to the address.
  • Mail identity. The PTR record, SPF records that list the old IP and the new IP's reputation on blocklists.
  • Allow-lists. Remote database access, payment gateways, registrar APIs, firewalls on other servers and the WHM API token rule.
  • WHMCS. The server entry holds an IP, a hostname and a token. If billing is moving as well, plan it as its own job, described under WHMCS migration.
  • Hard-coded values. IP addresses written into cron jobs, scripts, monitoring targets and application configs.

What backup strategy should a hosting server have?

Keep one local copy for fast restores, one encrypted off-site copy for disasters and a retention schedule that matches how much data you can afford to lose. Two numbers drive the design: the recovery point (how much recent data can be lost) and the recovery time (how long a restore may take).

CopyWhere it livesWhat it protects against
LocalA separate disk or volume on the same networkDeleted files and bad updates, with the fastest single-account restore.
Off-siteA different provider or region, reached over SFTP or S3-compatible storageLoss of the server, a provider outage or an account lockout.
ProtectedStorage the server can add to but not delete from or overwriteRansomware, and an intruder with root.

In WHM I set up Backup Configuration with a remote destination and a retention rule you choose. I also copy system configuration such as /etc and /var/cpanel, because account archives alone cannot rebuild a server. Encrypt before data leaves the machine, store the key away from both the server and the backup store, and add a heartbeat check, as described under server monitoring, so a silent failure raises an alert.

How do I know a backup actually works?

You only know after you restore it, because a backup that was never restored is untested. Jobs can report success for months while archiving empty databases or missing directories.

My test uses three accounts: the largest, one with heavy mail and one with many databases. I restore them onto a scratch server with /scripts/restorepkg or WHM's restore tool, load each site through a hosts-file override, compare database table counts and open a mailbox. I record the time taken and anything missing. That time is your real recovery time. I repeat the test after any change to the backup system.

What a migration cannot do

A migration cannot make DNS change instantly, repair an application that was already broken or move a server I am not authorized to access. Some resolvers ignore TTLs, so a few visitors reach the old server after cutover, which is why it stays online. I do not move unlicensed software and I do not delete your old server. Moving between different panels is scoped separately. Expect about one to five days depending on scope, with a fixed quote or $55 to $65 per hour. The destination build follows cPanel and WHM setup, and hardening comes next in server hardening.

Who this is for

  • Hosting owners moving to a new provider, faster hardware or a newer operating system
  • Resellers whose current server is old, full or unreliable
  • Teams whose backups have never been restored
  • Businesses consolidating several servers into one

What is included

  • Inventory of accounts, packages, IPs, cron jobs, mail and server-level settings
  • A destination server built to match or improve the source software stack
  • Account transfers in batches with the WHM Transfer Tool
  • DNS TTL reduction, hosts-file testing and a timed cutover with a rollback path
  • A final sync of mail and changed data at cutover
  • Local and off-site encrypted backup configuration with retention rules
  • A restore test and a written restore procedure

How the work runs

  1. 1

    Inventory

    I record every account, package, dedicated IP, cron job, custom config and integration on the source server, and I list what the transfer will not carry.

  2. 2

    Build and transfer

    I prepare the destination to match the source software stack, move accounts in batches and compare file, database and mailbox counts after each batch.

  3. 3

    Test

    I test every site and mailbox through a hosts-file override while real visitors still use the old server, then fix what differs.

  4. 4

    Cut over

    After lowering DNS TTL, I run a final sync, move the DNS records and watch the logs on both servers. The old server stays online as a fallback.

  5. 5

    Prove the backups

    I configure backups, restore a sample onto a scratch server and write down the steps and how long the restore took.

Frequently asked questions

How much downtime is there during a cPanel migration?

Sites keep running on the old server while we test, and the switch happens through DNS. With a lowered TTL, most visitors reach the new server within minutes, although a few resolvers cache longer. A final sync catches changes made in between, and the old server stays up until its logs go quiet.

Will I lose email during the move?

Not if it is planned. Mailboxes travel with each account. Messages delivered to the old server while DNS propagates are copied across by a final sync of the mail directories. I then check that new mail lands on the new server before the old one is switched off.

Can you migrate from Plesk or DirectAdmin to cPanel?

Sometimes. It is a different job from moving cPanel to cPanel. Accounts are rebuilt with the target panel's migration tools or by hand, and some settings do not map across. I inspect the source first, tell you whether I can take it on and what will not carry, and quote that work separately.

How long does a server migration take?

A few accounts with modest data can move in one or two days. Hundreds of accounts or very large mailboxes take longer because copying and testing take real time. The main drivers are data volume, the number of accounts and any special applications. I estimate after the inventory step.

How often should I test restoring backups?

Test after the backup system is first set up, after any change to it, and then on a schedule you agree, such as monthly or quarterly. A backup that has never been restored is untested. Each test gives you a real recovery time instead of a guess.

Are my host's snapshots enough as backups?

Usually not alone. Snapshots often live in the same provider account as the server, so a billing suspension, an account compromise or a provider outage can remove both together. Keep at least one encrypted copy with a different provider or in a different account, and test restoring from it.

Related services

Ready to talk about your project?

Send the details and I reply within one business day with questions, an estimate and a plan.