Moving existing client accounts onto your Fast Hive reseller plan is straightforward when the source is another cPanel server, because a full cPanel backup carries the files, databases, mailboxes, DNS zone and settings together. This guide covers the transfer methods, the order to do things in so nobody loses email, and the checks that turn a risky migration into an uneventful one.
Before you move anything
- Check capacity. Confirm your reseller pool has enough disk space and enough remaining cPanel accounts. Plans start at 25 accounts; your current usage is on your service page.
- Inventory each account. Note the PHP version, any unusual modules, the size of the databases and mailboxes, and anything scheduled in cron.
- Lower the TTL. A day or two before, drop the DNS TTL on the domains you are moving to 300 seconds. This is the single most effective thing you can do to make the cutover quick.
- Warn the client. Give them a window, and ask them not to publish content or take orders during it.
- Take a backup at the source and keep it until the migration is confirmed good.
Method 1 - WHM's transfer tool (best when you have the source WHM)
If you have root or reseller access to the source cPanel server, WHM can pull accounts across directly.
- In your WHM, open Transfers → Transfer or Restore a cPanel Account.
- Enter the source server's hostname and credentials.
- Select the accounts to transfer.
- Choose whether to bring packages and settings with them.
- Start the transfer and watch the log. It reports per-account success or failure with reasons.
This is the cleanest method because it preserves usernames, passwords, permissions and mail without you touching anything.
Method 2 - Full cPanel backup restore
Use this when you only have cPanel access to the source, not WHM.
- On the source, in cPanel, go to Files → Backup and click Download a Full Account Backup.
- Download the resulting
.tar.gz. - Upload it to your Fast Hive server - for large files, ask support to place it for you rather than fighting a browser upload.
- In your WHM, use Transfers → Transfer or Restore a cPanel Account and restore from the archive.
Method 3 - Manual migration
Only when the source is not cPanel. You are rebuilding rather than transferring:
- Create the account in WHM with an appropriate package.
- Move the files by SFTP or by uploading an archive.
- Export each database and import it into a newly created database, updating the application config with the new prefixed names.
- Recreate every mailbox, forwarder and filter.
- Recreate cron jobs.
- Recreate the DNS zone, matching the old records exactly.
Budget considerably more time for this, and expect email to be the hardest part - existing mail in mailboxes does not move by itself.
The cutover order that avoids downtime
The sequence matters more than the method.
- Migrate the account to your server while the old one stays live and serving traffic.
- Test on the new server before any DNS changes - use a temporary URL, or your local
hostsfile to point the domain at the new IP for your machine only. - Fix anything broken while the client is still being served by the old host and nobody has noticed.
- Do a final sync of files, database and mail immediately before switching, so nothing added in the meantime is lost.
- Change the nameservers to yours.
- Leave the old account running for at least a week. During propagation some visitors still reach it, and a live old copy means nobody sees an error.
- Only then cancel the old hosting.
After the migration - verify properly
- Load the site and click through the main pages, not just the homepage.
- Test forms, login and checkout - anything that writes to the database.
- Send a test email to and from a migrated mailbox.
- Confirm old mail is present in the mailbox, not just that new mail arrives.
- Check that SSL has issued for the domain on the new server.
- Confirm cron jobs exist and are scheduled correctly.
- Compare the DNS zone against the old one, record by record.
- Check the PHP version matches what the application expects.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| Transfer fails on "account already exists" | The username or a DNS zone survives from an earlier attempt. Remove the leftover zone under DNS Functions and retry. |
| Site loads but shows a database error | The database or user prefix changed with the new account name. Update the application's config file. |
| Old emails missing after migration | Mailboxes were recreated rather than restored. Restore from the full backup, which includes the mail directory. |
| Client's email stopped during the move | MX records did not carry over, or the old server was cancelled too early. Check the new DNS zone and Email Routing. |
| Site broken after transfer, worked before | Usually a PHP version difference. Set the version to match the old server in MultiPHP Manager, then update the application properly. |
| Transfer times out on a very large account | Split it - move files separately from the database - or ask Technical Support to run it server-side. |
| Some visitors see the old site for days | Normal propagation, made worse by a high TTL that was not lowered beforehand. It resolves as caches expire. |
| Pool disk usage jumped unexpectedly | Migration archives left on the server. Delete them once verified. |
Frequently asked questions
Will my clients experience downtime?
Not if you follow the cutover order - migrate first, test, switch DNS, and keep the old account alive through propagation. Visitors are served by one working copy or the other throughout.
Can Fast Hive do the migration for me?
Yes, migration is free. Open a ticket with Technical Support with the source server details and the accounts involved.
Do client passwords carry across?
With a WHM transfer or a full backup restore, yes - cPanel, FTP, email and database passwords are preserved, so clients notice nothing.
How long does it take?
A small account transfers in minutes. Large mailboxes and databases dominate the time. DNS propagation then runs for hours afterwards regardless.
What if the client's domain is registered elsewhere?
That is fine and changes nothing about the migration. You simply update the nameservers at whichever registrar holds it.
Should I move all clients at once?
No. Start with one low-risk site, ideally your own. Confirm it for a full day, then move the rest in small batches so any problem affects few people.
