Hosting Migration Checklist: cPanel Transfer Tool vs Manual Migration for Moving Websites

Most cPanel-to-cPanel moves should start with the cPanel Transfer Tool, while manual migration should be reserved for mixed panels, broken accounts, custom stacks, or high-risk sites that need surgical control. cPanel describes the Transfer Tool as a WHM feature that copies accounts from a remote server to a local server [source: cPanel]. The catch is that “copy” does not always mean “ready.” DNS, SSL, cron jobs, email routing, PHP versions, and database permissions still need human checks.

TLDR: The cPanel Transfer Tool is usually faster for bulk migrations, especially when both servers run WHM/cPanel with root access. For example, an agency moving 18 small WordPress sites may finish the account copy phase in a few hours with the tool, while manual migration could stretch across a full weekend. Manual migration gives better control when only one site, one database, or one broken mailbox needs attention. The safest plan is to run a pre-migration audit, choose the transfer method, test on the new server, then update DNS only after every core feature works.

Quick Decision: cPanel Transfer Tool or Manual Migration?

The answer depends on access, account count, and site complexity. A hosting provider moving many full cPanel accounts should usually use the Transfer Tool. A developer moving one custom application from a non-cPanel server may need manual work.

• Use the cPanel Transfer Tool when both servers use cPanel/WHM, root or reseller access is available, and full account copies are needed.
• Use manual migration when the old host has no WHM access, the site uses a custom stack, or only selected files, databases, and mailboxes should move.
• Use a hybrid approach when most accounts can transfer automatically, but a few require hand fixing.

Pre-Migration Checklist

Before any transfer, the site owner or hosting team should collect facts. Skipping this step causes the ugly surprises: missing mail, wrong PHP versions, 500 errors, and clients asking why checkout failed at 2 a.m.

• List all domains and subdomains. Include parked domains, addon domains, aliases, and redirects.
• Check disk usage. The new server should have enough storage for files, mail, backups, logs, and growth.
• Record PHP, MySQL, and image library versions. Older sites may break on newer defaults.
• Lower DNS TTL. Set it to 300 seconds at least 24 hours before the move, if possible.
• Back up everything. Keep one local copy and one off-server copy.
• Review email routing. Confirm whether mail is local, remote, Google Workspace, Microsoft 365, or another service.
• Export key settings. Save cron jobs, redirects, DNS zones, SSL details, FTP users, and database users.
• Freeze risky changes. Stop major content edits, plugin updates, and store changes during the final sync window.

When the cPanel Transfer Tool Makes Sense

The Transfer Tool shines during full-account moves. It can copy home directories, databases, email accounts, DNS zones, and many cPanel settings in one process. That saves hours when many accounts need to move from one WHM server to another.

It also reduces typo risk. A manual database user copied with one wrong character can break an app. A missed hidden file can take down rewrite rules. Automation helps with that boring, fragile work.

Still, the tool is not magic. Honestly, it feels like every migration tool waits until the last 10% to reveal the weird stuff. Large mailboxes may stall. Custom DNS can confuse routing. Old PHP handlers may not map cleanly. Suspended accounts, malware, and damaged backups can also cause failed transfers.

cPanel Transfer Tool Checklist

1. Confirm WHM access on both servers, with the permissions needed to transfer accounts.
2. Update cPanel on both ends where practical, or at least confirm version compatibility.
3. Check server resources such as CPU, RAM, disk I/O, and available storage.
4. Run the Transfer Tool from WHM and select the source server.
5. Choose accounts carefully. Avoid moving abandoned or infected accounts without review.
6. Review the transfer log. Any warning should be treated as real until tested.
7. Compare account sizes before and after transfer.
8. Test sites with a hosts file edit before DNS changes.
9. Install or verify SSL certificates after the account lands on the new server.
10. Switch DNS only after web, database, email, and cron tests pass.

When Manual Migration Is the Better Choice

Manual migration is slower, but it gives more control. It fits cases where the source host does not provide WHM. It also helps when moving from Plesk, DirectAdmin, a VPS without a panel, or a managed WordPress platform.

Manual work is also safer for messy sites. A developer can move one directory at a time, clean old cache, skip junk backups, and repair database settings. That is useful when a site has years of abandoned files sitting in public_html.

Expect to waste time on tiny details. A database import that should take 40 seconds may take 6 minutes because of timeout limits. A mail folder may use a format that needs conversion. A WordPress site may load, then fail because the object cache points to the old server.

Manual Migration Checklist

1. Create a fresh backup of files, databases, email, and DNS records.
2. Copy website files with SFTP, rsync, SSH, or a file manager.
3. Export databases with phpMyAdmin, mysqldump, or another trusted tool.
4. Create matching databases and users on the new server.
5. Import database dumps and check character sets.
6. Update config files such as wp-config.php, .env, configuration.php, or settings.php.
7. Recreate mailboxes and migrate messages if mail stays on the hosting server.
8. Rebuild DNS records including A, AAAA, CNAME, MX, TXT, SPF, DKIM, and DMARC.
9. Recreate cron jobs and confirm paths work on the new server.
10. Test forms, login pages, checkout, search, uploads, and admin actions.

Testing Before the DNS Switch

Testing should happen before visitors reach the new server. The team can edit the local hosts file to preview the site at the new IP. This avoids public downtime during repair.

• Open the homepage and key landing pages.
• Log in to the CMS admin area.
• Submit contact forms.
• Place a test order if the site sells products.
• Check file uploads and media libraries.
• Review error logs for PHP warnings and permission issues.
• Send and receive test email.

Post-Migration Checklist

After DNS changes, the job is not done. The team should monitor for at least 24 to 72 hours. Some visitors may still reach the old server during propagation, even with a low TTL.

• Keep the old server online for several days, especially for busy sites.
• Run a final content sync for uploads, comments, orders, or forum posts.
• Check SSL and mixed content.
• Monitor email queues.
• Scan access and error logs.
• Confirm backups on the new server.
• Update third-party services that store IP addresses, including payment gateways, firewalls, CDNs, and uptime monitors.

FAQ

Is the cPanel Transfer Tool always better than manual migration?

No. It is better for full cPanel account transfers. Manual migration is better for custom setups, non-cPanel sources, partial moves, or damaged accounts.

Will the Transfer Tool move email accounts?

In many cPanel-to-cPanel transfers, yes. Still, the team should test mailbox access, passwords, routing, spam filters, and webmail after the move.

Does manual migration reduce downtime?

Not by itself. Downtime depends on planning, DNS TTL, data sync timing, and testing. A careful manual move can have low downtime, but a rushed one can be painful.

What is the biggest migration mistake?

The biggest mistake is changing DNS before testing. The site may look moved, but forms, SSL, email, cron jobs, or database writes may be broken.

Should the old hosting account be canceled right after migration?

No. It should stay active for several days. This gives the team time to recover missed files, sync late email, and catch DNS stragglers.