CyberPanel migration: move websites from CyberPanel to Jabali Panel
Last updated
The CyberPanel ingest path. Status: production-supported. Like Plesk migration, this is SSH pull-based — no archive to produce on the source, no manual file transfer step.
How it differs from cPanel / DirectAdmin / HestiaCP
| Source | Discovery | Data transfer |
|---|---|---|
| cPanel | Upload cpmove-<user>.tar.gz | Archive |
| DirectAdmin | Upload da backup-user tarball | Archive |
| HestiaCP | Upload v-backup-user output | Archive |
| CyberPanel | SSH into source, read cyberpanel MySQL DB | Streamed on Restore |
| Plesk | SSH into source, run plesk bin | Streamed on Restore |
| CloudPanel | SSH into source, read SQLite DB | Streamed on Restore |
| WHM | Upload multi-account cpmove dump | Archive |
CyberPanel keeps its entire inventory in the cyberpanel MySQL database. The pipeline reads that database directly over SSH — no plesk bin-style CLI scraping, no CyberPanel API dependency. Every read is a plain SELECT statement.
Prerequisites
- SSH access to the source CyberPanel host as
root. CyberPanel’s mysqld grants root passwordless local access, which the pipeline relies on. - Credentials: SSH password or private key.
- Source CyberPanel version: any modern CyberPanel (2.x) on CentOS/AlmaLinux/RHEL 7-9 or Ubuntu 20.04+.
- Network reachability: destination Jabali host must reach the source over SSH. Private-IP sources require
migration_allow_private_hostsenabled.
Operator workflow
- Add the source in
/jabali-admin/migrations:- Kind:
cyberpanel - Host:
<source-fqdn-or-ip> - Port:
22(or custom) - Auth: SSH password or private key
- Kind:
- Discover — the panel connects via SSH and reads
SELECT domain FROM websiteFunctions_websites. Every site becomes an account row. - Select websites — pick one, several, or all. Per-site: pick the target Hosting Package.
- Analyze — reads websites, databases, DNS, mailboxes, forwarders, cron jobs from the source. No writes.
- Restore — synthesizes a cpmove-shape archive on the destination, ingests each asset. Per-phase progress in the UI.
- Communicate generated mail passwords to mailbox owners.
- Repoint DNS at the registrar.
- Issue SSL via the per-domain SSL toggle.
What gets migrated
| Asset | Source table / command | Behavior |
|---|---|---|
| Websites | websiteFunctions_websites | Become panel Domain rows; docroot at /home/<domain>/. |
| Linux users | websiteFunctions_websites.externalApp | Recreated on destination; UID may differ. |
| Child / addon domains | websiteFunctions_childdomains | Become subdomain Domain rows. |
| MySQL databases | databases_databases | Restored with users; password hashes preserved where compatible. |
| DNS zones | CyberPanel’s PowerDNS backend | Translated to Jabali PowerDNS. |
| Email accounts | e_users | Recreated in Stalwart with generated passwords. |
| Mail forwarders | e_forwardings | Translated to Stalwart forwarders. |
| Mail-domain mapping | e_domains | Applied as mail-enabled flag on destination Domain rows. |
| Hosting packages | packages_package | Surface as suggested Hosting Package mappings. |
| Cron jobs | crontab -u <user> | Translated to systemd-user timers via the Cron allowlist. |
| SSL certificates | — | Reissued via Let’s Encrypt on destination. |
What is not migrated
- OpenLiteSpeed vhost configuration. Jabali serves nginx + PHP-FPM. Vhosts are rendered fresh from the Jabali template.
- LSCache. Replaced by Jabali Cache for WordPress sites — wired to the panel’s Redis instance.
- OpenLiteSpeed WAF rules / ModSecurity per-site rules. Replaced by AppSec at the server level.
- CyberPanel Docker feature. Use Docker Apps marketplace instead — hardened multi-tenant, backups, reverse proxy, SSL wired up.
- Rainloop webmail. Jabali ships Roundcube.
- CyberPanel backup jobs. Re-model in Backups.
Troubleshooting
Discovery fails with Access denied for user 'root'@'localhost'.
CyberPanel’s mysqld usually grants root passwordless local access on 3306. If the source has been hardened with a root password, either grant root@localhost passwordless access temporarily, or pre-dump the cyberpanel DB manually and upload as an archive.
Site restore succeeds but shows “hello world” PHP.
The site’s docroot on CyberPanel was under /home/<domain>/public_html/ but the site’s own routing was in a subdirectory. Update the destination Domain row’s docroot to match.
Mailboxes missing after restore.
CyberPanel stores mail under /home/vmail/<domain>/<local>/; if the destination volume differs, symlink /home/vmail/ into the migration source path before Analyze.
DNS zones empty after restore.
CyberPanel proxies DNS through its own PowerDNS instance. Confirm the source’s PowerDNS is running and the pdns.records table is populated: `mysql -e “SELECT COUNT(*) FROM pdns.records” — if 0, the source has no zones to migrate.
Audit
Standard per-phase audit rows. The SSH origin + reading queries are recorded on every audit row.
Related reading
- Plesk migration — same SSH-pull model.
- CloudPanel migration — SSH-pull but web-only (no mail).
- cPanel migration — archive-upload model.
Frequently asked questions
Can I migrate from CyberPanel to Jabali Panel?
Yes. Jabali Panel's CyberPanel pipeline connects over SSH and reads the source's `cyberpanel` MySQL config database directly. Discovery is strictly read-only — plain `SELECT` statements against the `cyberpanel` DB, no mutating command. Restore synthesizes a cpmove-shape archive on the destination and hands off to the cPanel restore path. CyberPanel's OpenLiteSpeed vhosts become Jabali's nginx + PHP-FPM vhosts.
What credentials does the CyberPanel pipeline need?
SSH access to the source CyberPanel host with a root principal — CyberPanel's mysqld grants root passwordless local access, which the pipeline uses to run read-only SELECTs against the `cyberpanel` config database. SSH password or private key both work. Non-standard SSH ports supported.
What tables does the CyberPanel pipeline read?
websiteFunctions_websites (one row per site with domain, external Linux user, admin email, package_id); databases_databases (dbName, dbUser, website_id) for MySQL databases; e_users (email accounts with disk usage and owner_id); e_forwardings (source, destination) for mail forwarders; e_domains (mail domain to website mapping); websiteFunctions_childdomains for addon domains; packages_package for hosting-package definitions. Read-only SELECTs only — no mutating statements.
Does OpenLiteSpeed configuration translate to nginx?
Yes, but not verbatim. Jabali Panel serves nginx + PHP-FPM. The pipeline reads CyberPanel's per-site PHP version + docroot and renders a fresh nginx vhost from the Jabali template. OpenLiteSpeed's `.htaccess` handling (LSAPI) translates to nginx-native `try_files` + rewrites. Custom OLS rewrite rules that depend on LSAPI-specific directives need manual re-implementation in the nginx `location` block. LSCache is replaced by [Jabali Cache](https://wordpress.org/plugins/jabali-cache/) for WordPress sites.
Are CyberPanel mailboxes migrated?
Yes — unlike CloudPanel, CyberPanel has a mail server (Postfix + Dovecot). Mailboxes migrate to Stalwart; passwords are reset because Dovecot's hash format is not portable to Stalwart's Argon2id store. Forwarders and the mail-domain-to-website mapping are translated. Mailbox contents (INBOX + folders + flags) migrate intact via IMAP.
What CyberPanel features do not migrate?
OpenLiteSpeed WAF rules do not translate (replaced by AppSec / CrowdSec at the server level). ModSecurity per-site rules do not migrate. CyberPanel Docker feature does not translate 1:1 — use the panel's [Docker Apps marketplace](./docker-apps.md) instead. Rainloop webmail configuration is not carried over (Jabali ships Roundcube). Backup jobs from CyberPanel's own backup system do not migrate; re-model in the panel's [Backups](./backups.md).