Migrate cPanel accounts between servers with JetBackup 5

JetBackup 5 moves cPanel accounts between servers two ways: a Clone Job that pushes accounts live over SSH, or a restore from a backup destination that both servers can read. Each fits a different migration shape — a planned fleet consolidation versus a rebuild from an existing backup repo — and picking the wrong one wastes a maintenance window.

This guide is for admins running JetBackup 5 on cPanel/WHM who already use it for backups and want to reuse that machinery for migration instead of standing up the WHM Transfer Tool. If you only need a single file back, see restore a single file from JetBackup instead.

Which method to use

Use a Clone Job when both servers are up and you want to pre-stage accounts, then do a final delta sync at cutover. Use a restore when the source is dead, decommissioned, or when you already ship Full Account backups to a remote destination like Wasabi and want to rehydrate them on new hardware.

Method 1: Clone Jobs over SSH

A Clone Job logs into the target server as root and rebuilds the selected accounts there. It is the closest JetBackup equivalent to pkgacct + restore, but driven from the source and re-runnable.

Register the clone destination

On the source server, in WHM → JetBackup 5 → Destinations → Create New Destination, pick SSH and flag it as a clone destination. Unlike a backup destination — where you should use an unprivileged user — a clone destination needs root credentials or an authorised root private key on the target, because it has to create accounts. Leave the backup directory blank; clones use rsync, not a repository path.

JetBackup generates the key pair and installs it on the target for passwordless login. Click Validate Destination before saving — it confirms the SSH login and that the remote is a compatible cPanel/JetBackup host. A green validation here is the single best predictor that the migration will run clean.

Create the Clone Job

Go to Clone Jobs → Create New Clone Job and fill in:

• Account selection — all accounts, or filter by owner/reseller, package, or an explicit list. For a phased move, clone one reseller's accounts at a time.
• Clone destination — the SSH destination you just validated.
• Restore package selection — switch this from Live Account Package to Backed up package. Otherwise the target tries to map each account to a package that may not exist there yet, and accounts land on the wrong limits.
• Schedule — run it now for a one-off, or nightly to keep the target warm until cutover. Re-runs rsync only the delta, so a second pass the morning of the move is cheap.

Start the job and watch Queue → the running task log. Each account shows as a separate task; a failure on one account does not block the rest.

How IPs are assigned on the target

JetBackup tries the source account's IP first. If that IP does not exist on the target, it falls back to a Failover IP set under JetBackup → Settings → Panel on the target, and if that is unset, to the target's main shared IP. Set the failover IP before cloning if you care where accounts land — chasing dedicated-IP reassignment after the fact across hundreds of accounts is miserable.

Method 2: Restore from a shared destination

When the source is offline or you simply back up off-box, skip cloning entirely: point the new server at the existing backup repository and restore.

Attach the existing repository

The clean path is a genuinely shared remote destination — S3, Wasabi, Backblaze B2, or SSH. On the new server, add the same destination (same bucket, same path, same credentials) you used on the old one, then run a Reindex so JetBackup discovers the existing snapshots. Reindex reads the repository metadata and populates the snapshot list without copying anything.

If the backups live on local disk you physically moved to the new box, add a Local (Legacy) destination pointed at the backup directory and mark it read-only so JetBackup never writes new backups into a repo you're only restoring from. Reindex it the same way.

Restore the accounts

Open the destination, browse to each account's Full Account snapshot, and Restore. Set the restore to recreate the account (not restore-into-existing) and again prefer the backed-up package so limits come across intact. A Full Account restore brings the home directory, databases, email, DNS zones, SSL certificates, and cron jobs in one operation.

For bulk or scripted restores during a tight window, drive it from the CLI as root:

# List snapshots on a reindexed destination
jetbackup5api -F listBackupForType -D '{"type":"accounts"}'

# Restore a full account snapshot, recreating the account
jetbackup5api -F manageJobsRestore -D '{
  "destination": "<destination_id>",
  "snapshot_id": "<snapshot_id>",
  "restore_account": 1,
  "restore_options": {"package": "backup"}
}'

jetbackup5api is idempotent and far faster than clicking through 200 accounts; loop it over a list of snapshot IDs from listBackupForType.

Cutover and DNS

Neither method flips DNS for you. After accounts exist on the new server and you've spot-checked a few sites by editing your hosts file to the new IP:

1. Lower the TTL on the affected zones 24 hours before the move so propagation is fast at cutover.
2. Re-sync the delta one last time (Clone Job re-run, or a fresh restore) to catch mail and database changes since the first pass.
3. Repoint A/AAAA records — or the nameservers — to the new server.
4. Keep the old server live and read-only for a few days to catch trailing mail and stragglers, then decommission.

If you're moving off cPanel entirely rather than between cPanel servers, JetBackup also clones into Plesk and DirectAdmin, but cross-panel clones rewrite far more (mail stack, DNS templates, vhosts) and need real validation — treat that as a panel migration, not a copy.

Next steps

• Activate or size your plan at JetBackup licensing and the JetBackup 5 license tiers.
• Set up the off-box repository this relies on: JetBackup 5 destinations for cPanel.
• Weighing JetBackup against the alternatives? See JetBackup vs cPanel built-in backups and R1Soft vs JetBackup.