Moving a handful of cPanel accounts to a new server is a low-stakes afternoon. Moving two hundred is a project with real consequences if it goes wrong client sites offline, email bouncing, and a support queue that fills up fast. The good news is that cPanel’s own tooling is built for exactly this, and the difference between a smooth migration and a painful one usually comes down to sequencing rather than any single technical trick. Here’s how to do it properly.
Start with the new server, not the migration itself
Before moving a single account, the destination server needs to be fully provisioned and verified independently of the migration process. That means cPanel and WHM installed and licensed, the hostname and main IP configured, and critically every site’s software requirements checked against what the new server actually offers. It’s worth confirming sites are running on an up-to-date, compatible PHP version and that database-dependent applications will work against whatever MySQL or MariaDB version the new server ships with, since a mismatch here is one of the most common causes of a migration that “worked” technically but broke half the sites functionally. Sorting this out before the transfer begins is far less painful than discovering it account by account afterward.
Lower your DNS TTLs several days ahead of time
This step gets skipped more often than it should, and it’s the single biggest lever for making a migration feel instant rather than gradual. DNS records carry a time-to-live value that tells resolvers around the internet how long to cache an answer before checking again and if that value is set to the default of an hour or more, your eventual DNS switch will propagate unevenly across the internet for that same window, with some visitors landing on the new server and others still hitting the old one. Lowering TTLs to around 300 seconds a day or two before the migration means that once you do flip DNS, the change propagates in minutes rather than hours, which is what actually makes a “zero downtime” migration possible rather than just less painful.
Use the WHM Transfer Tool rather than manual backups at this scale
For a handful of accounts, downloading a full backup from cPanel and restoring it manually on the new server works fine. At two hundred accounts, that approach turns into an enormous, error-prone, multi-day task. The WHM Transfer Tool exists specifically for this. Logging into WHM on the new server and opening the Transfer Tool lets you connect directly to the old server using its root credentials, scan for every existing cPanel account, and select as many as you want including all of them to migrate in a single operation. The tool copies files, databases, email accounts and their credentials, DNS zones, cron jobs, and forwarders as a connected package, recreating each account on the new server largely as-is. It’s a pull operation: the new server reaches out and pulls data from the old one, which is worth knowing if you’re troubleshooting a connection issue, since the destination server is the one that needs outbound access to the source, not the other way around.
For source servers that don’t allow password authentication over SSH, the destination server’s public SSH key needs to be added to the source server first so the connection can authenticate properly a step that’s easy to miss and shows up as a confusing connection failure if skipped.
Keep the old server live throughout
This is the part that actually delivers the “without downtime” promise. Don’t decommission or stop the old server once the transfer begins every account should keep serving live traffic from the old server for the entire duration of the migration and verification process. Because the Transfer Tool copies data rather than moving it destructively, the accounts exist in both places simultaneously once the transfer completes, which gives you a safety net and a live fallback if anything on the new server needs fixing before the cutover.
Verify every account before touching DNS
This is the step that separates a clean migration from a chaotic one, and at two hundred accounts it’s tempting to skip verification on the assumption that if the tool worked for the first twenty accounts, it worked for all of them. It’s worth resisting that temptation. Before changing any DNS record, each site should be previewed on the new server using a local hosts file entry that maps the domain directly to the new server’s IP address, bypassing DNS entirely for testing purposes. This lets you click through each site, confirm it loads correctly, check that admin logins work, verify database-driven functionality behaves as expected, and confirm outbound and inbound email settings are correctly configured all while the live site continues serving normally from the old server to actual visitors. Only once a site passes this check should its DNS be considered ready to switch.
For two hundred accounts, this is the stage worth allocating the most time to, and it’s reasonable to batch it verify and cut over accounts in groups rather than attempting all two hundred simultaneously, so that any issue that surfaces affects a manageable subset rather than the entire migration at once.
Switch DNS in batches, not all at once
Once a batch of accounts has been verified individually, update the DNS records for that batch to point at the new server’s IP. Because TTLs were lowered in advance, propagation for each batch happens quickly, and because the old server is still live and unaffected, any account that needs a rollback can simply have its DNS reverted with the same fast propagation. Working in batches rather than flipping every domain simultaneously also makes it far easier to isolate a problem if one appears if issues show up only in the third batch, you know exactly where to look rather than troubleshooting two hundred accounts’ worth of changes at once.
Don’t forget what the Transfer Tool doesn’t carry
The Transfer Tool moves cPanel account data comprehensively, but it doesn’t replicate WHM-level server settings things like firewall configuration, custom Apache or Nginx tweaks, installed third-party software, and server-wide security tool configurations need to be recreated manually on the new server rather than assumed to transfer along with the accounts. Building a checklist of server-level configuration on the old box before starting, separate from the account migration itself, avoids the situation where every site moves successfully but the server-level protections and customizations that kept things running smoothly quietly don’t.
What to check once every account has cut over
After the final batch’s DNS has propagated, don’t close out the migration immediately. Give it a few days of monitoring — checking for elevated error rates, email delivery issues, or resource usage patterns that look different from the old server’s baseline before decommissioning the old server entirely. Once everything has stayed stable, that old server is the last thing to shut down, not the migration’s final visible step.
