Migrate to Jabali Panel: cPanel, DirectAdmin, HestiaCP, Plesk, WHM

Last updated

/jabali-admin/migrations. Parent page for the cPanel / DirectAdmin / HestiaCP / Plesk / CyberPanel / CloudPanel / WHM ingest pipelines. Each source has its own subpage:

Pipeline shape (shared)

Every source uses the same four-phase pipeline:

  1. Analyze: inspect the uploaded archive, list users, domains, databases, mailboxes, DNS zones, cron jobs. No write yet.
  2. Fix-perms: chown / chmod normalisations to match Jabali’s per-user pool layout.
  3. Validate: DB password hashes parseable, DNS zone files valid, mail account schemas consistent.
  4. Restore: create the panel user, ingest each domain, database, mailbox, cron job. Hand off to the reconciler for vhost render and per-user state convergence.

Each phase logs to a structured per-job journal viewable from /jabali-admin/migrations/<id>.

Page surface

  • Incoming archives: files uploaded but not yet started.
  • In-flight jobs: currently running; per-row progress percentage + current phase.
  • Completed jobs: succeeded or failed; click for full per-stage log.

Upload paths

  • Web upload: drag-and-drop on the page.
  • SCP: drop the archive into /var/lib/jabali/migrations/incoming/ and refresh the page.

The web upload chunks large files; SCP is faster for >1 GiB archives over slow links.

Stop-the-world semantics

Each pipeline run targets a single destination user. While that user’s domains, databases, and mailboxes are being created, panel-side writes against the same user (UI or CLI) are queued and applied after the run completes. Reads remain available.

After-the-fact tidy

After a successful restore:

jabali domain orphan-prune --dry-run    # report orphans
jabali domain orphan-prune --apply      # remove them

Catches domains the source had soft-deleted but the cpmove archive still referenced.

Limitations

  • No live migration. Each pipeline is offline relative to the destination user; the archive is a point-in-time snapshot, so freeze writes on the source at cutover.
  • No CSF / LFD rule translation. Carry over allowlists manually into CrowdSec Allowlists.
  • No reseller construct. Reseller-owned accounts migrate as individual panel users with no parent-child relationship, on every source. Re-model billing in FOSSBilling / WHMCS / Blesta if the hierarchy mattered.

Frequently asked questions

Which control panels can I migrate FROM to Jabali Panel?
cPanel (cpmove-.tar.gz), DirectAdmin (da backup-user output), HestiaCP (v-backup-user output), Plesk (Plesk full-backup .tar), CyberPanel, CloudPanel, and WHM server-wide dumps. Generic IMAP mailbox migration is also available for mail-only moves from any Dovecot/Courier/Cyrus source. Each source has its own subpage with the exact commands.
Where do I upload the migration archive?
Two paths: (1) drag-and-drop on `/jabali-admin/migrations` for archives under ~2 GiB; (2) SCP into `/var/lib/jabali/migrations/incoming/` for larger dumps over slow links. The page auto-detects new files in the SCP directory and adds them to the Incoming list. Chunked web upload handles multi-GB files but SCP with `--partial` resumability is faster over unreliable connections.
What phases does every migration go through?
Four phases per account: (1) Analyze — reads the archive, lists users, domains, DBs, mailboxes, DNS zones, and cron jobs; no writes yet. (2) Fix-perms — chown/chmod to match Jabali's per-user layout. (3) Validate — checks DB hash format, DNS zone syntax, and mail account schemas. (4) Restore — creates the user, ingests each asset, hands off to the reconciler. Each phase writes a structured audit row visible at `/jabali-admin/migrations/`.
Do migrations require downtime on the source panel?
No hard downtime, but the archive is a point-in-time snapshot. Any writes made on the source AFTER the archive is produced are lost. The recommended pattern: lower DNS TTLs 24-48h ahead, freeze writes on the source at cutover (or put the account in maintenance), produce the archive, ship + restore, then repoint DNS. See the [cPanel cutover playbook](./cpanel-migration.md#cutover-playbook-minimise-dns-propagation-downtime) — same shape applies to every source.
What is the difference between per-account and server-wide migration?
Per-account = one archive, one panel user. Server-wide = the source producer emits one archive per user plus a manifest (WHM `/scripts/cpbackup`, `da backup-all`, Plesk full-backup). The panel iterates the per-account pipeline for each user in the manifest, tracks per-user progress, and reports server-wide summary. Pass `--parallel N` to run N restores concurrently.
Are custom firewall or WAF rules migrated?
No. CSF/LFD (cPanel/DirectAdmin), Hestia iptables, and Modsecurity per-user rules are not migrated. Jabali replaces them with UFW as the baseline firewall, CrowdSec for dynamic bans and community blocklists, and AppSec (CrowdSec's WAF component) at the server level. Carry over allowlists manually into [CrowdSec Allowlists](./crowdsec-allowlists.md).