cPanel migrations to Jabali Panel: end-to-end guide

Leaving cPanel is a project. Even when the new panel is simpler, the source has years of hosting quirks embedded in it — old FTP accounts, custom DNS records, mail forwarders nobody remembers setting up, WordPress installs with hardcoded absolute paths. This post walks through how Jabali Panel handles a cPanel migration end-to-end, what the ingest actually preserves, and where the standard cutover playbook has bear-traps.

When to reach for the migration path

The Jabali cPanel path is designed for two shapes of move:

1. Single-account — one hosted user, one cPanel account, moving to a new Debian 13 box. Common when a freelancer moves their whole client roster or a small agency retires an old shared server.
2. Whole-server — a WHM server retirement. Every hosted account gets a cpmove archive; the migration iterates.

If you’re staying inside the cPanel ecosystem (server-to-server upgrade), keep using WHM’s own migration tools. Jabali Panel replaces cPanel — the migration path is one-way.

The one command that produces the input

On the cPanel source, from WHM:

Home → Backup → Backup Wizard → Generate Backup

Or from the shell as root:

/scripts/pkgacct <username>
# produces /home/cpmove-<username>.tar.gz

For a server-wide migration, loop pkgacct over /etc/trueuserdomains or use WHM’s server-transfer tool to dump every account into one directory.

cpmove-<user>.tar.gz is the canonical format Jabali expects. Version-specific WHM extensions (custom skins, cPanel-XMLAPI plugins, WHMCS integration hooks) are ignored — everything the panel needs is in the standard subtree.

What the ingest reproduces on Jabali

Upload the cpmove archive at /jabali-admin/migrations. The restore is per-account and tracks progress live in the UI. Under the hood:

From cPanel	To Jabali
Linux user account	Recreated (UID may differ if the target server has a UID conflict)
Home directory	Copied to /home/<user>/, preserving mode + ownership
Hosted domain(s)	Created as panel Domain rows; nginx vhosts rendered by the reconciler within ~1s
Subdomains	Same, or promoted to aliases based on the cPanel addon_domains map
DNS zones	Translated into PowerDNS records rows; served immediately from the local PowerDNS Authoritative
MySQL databases	Restored via mysql against panel-managed MariaDB
MySQL users	Preserved with bcrypt hashes intact — hosted apps keep authenticating without a password reset
DKIM keys	Imported as-is so outbound mail flow doesn’t break
Mailboxes	Created in Stalwart Mail; contents migrated via IMAP
FTP accounts	Not migrated — the panel does not host FTP. SFTP replaces it.
Mailing lists (Mailman)	Not migrated — Mailman is not in the panel

Two of these deserve a callout.

MySQL bcrypt hash preservation

The panel stores MySQL user bcrypt hashes directly rather than requiring a password reset on each hosted user’s database credentials. This is the difference between a WordPress site working the moment you flip DNS versus a support ticket queue full of “site is broken” complaints. Every hosted app that talks to MySQL — WordPress, Drupal, Joomla, custom PHP — keeps working with the same wp-config.php, no reset needed.

Mailbox passwords, on the other hand, do not survive

cPanel uses Dovecot’s CRAM-MD5 hashes. Stalwart Mail’s password store is Argon2id — there’s no way to translate CRAM-MD5 into Argon2id without the cleartext. The migration generates fresh passwords per mailbox and prints them in the migration report; you deliver them out-of-band. Mailbox contents are moved intact via IMAP.

If preserving login is critical, the workaround is to run an IMAP proxy that authenticates against both stores during the transition, but that’s not something the panel provides out of the box — most operators just distribute the new passwords.

Downtime-minimising cutover playbook

There’s one moment of unavoidable downtime: the DNS A-record flip. Everything else is pre-stageable.

1 week out

• Verify you can reach the source server for pkgacct runs
• Install Jabali Panel on the destination Debian 13 host, add the panel host to DNS, get the panel’s own TLS working

24 hours out

• Lower the domain’s DNS TTL to 60-300 seconds. The registrar’s SOA doesn’t need to change; just the record TTL.

Cutover day

• Produce the cpmove archive on source
• Upload via /jabali-admin/migrations on destination
• Watch the UI restore live; the panel reports progress per-account
• Verify every hosted site loads via the destination’s IP by editing /etc/hosts on your workstation to point at the new server
• Flip the domain A record to the new IP
• Watch the panel’s live nginx logs to confirm real traffic arrives

24 hours after

• Raise TTL back to a normal value (3600+)
• Keep the source server up for 72 hours as a fallback
• Deliver new mailbox passwords to users

What breaks and how the panel reports it

The Migrations UI produces a per-account report at the end of the restore. Anything that couldn’t be migrated is listed under a section header — mailing lists, FTP-only accounts, plugins that reference cPanel APIs directly, PHP scripts that assume /usr/local/cpanel/bin/whmapi1 is on $PATH.

A frequent surprise is WordPress installs with hardcoded absolute paths in wp-config.php (e.g., ABSPATH set to the old /home/username/public_html/). Jabali paths do match cPanel’s convention — the home directory ends up at /home/<user>/, the docroot at /home/<user>/public_html/ — so most WordPress installs keep working. When they don’t, it’s usually a plugin that hardcoded the previous panel’s install path.

DirectAdmin, HestiaCP, WHM — same UI, different pipeline

The Migrations section also ingests archives from DirectAdmin, HestiaCP, and WHM. Each uses a different backup format, but the destination flow — Linux user recreation, domain provisioning, DNS translation, MySQL restore, mailbox handoff — is identical. If you’re moving from a mixed source, drop each archive into the same Migrations UI.

Try it before you cutover

The demo panel at /demo/ shows the Migrations section live, including a dry-run restore of a sample cPanel archive. The installation guide covers panel-hostname DNS prep and reverse-DNS recommendations for outbound mail deliverability.

For the technical reference on the cPanel-specific mapping (which files land where, which fields translate to which schema rows), see the cPanel Migration docs.