cPanel Migration
Last updated
If you are moving your account from a cPanel host to Jabali, this is the typical path. Operator-side details are in cPanel Migration.
What gets moved
The administrator handles the import. Once your account is restored on the new panel, the following are in place:
- Your Linux home directory, with files at their original paths.
- Hosted domains.
- DNS zones (translated to PowerDNS records).
- MySQL databases and DB users, passwords preserved (cPanel bcrypt hashes are accepted by MariaDB directly), so application configurations keep working without edits.
- Email accounts, recreated in Stalwart. Email passwords are reset because cPanel’s Dovecot password hash format cannot be imported into Stalwart. You receive new generated passwords; communicate them to mailbox owners.
- DKIM keys.
- Cron jobs (those whose commands pass the Cron allowlist).
- SFTP, old cPanel FTP credentials do not transfer. Add your SSH public key under SSH Keys.
What does not get moved
- Spamassassin per-mailbox rules (Stalwart’s spam filter is server-side; per-mailbox tuning is currently operator-controlled).
- Mailing-list configurations (Mailman is not part of the panel).
- Apache
.htaccessdirectives that depend onmod_phpor other Apache-only modules.mod_rewritedirectives translate; review your.htaccessfiles after the migration to confirm rewrite rules still work as expected. - TLS certificates, the panel reissues via Let’s Encrypt automatically.
After your account is restored
- Log in: your panel password is set by the administrator and communicated separately. Set a new one under Profile → Security → Change Password.
- SFTP: add at least one SSH public key under SSH Keys before you try to upload anything.
- Email: collect the generated mail passwords from the administrator and pass them on, or have mailbox owners use the recovery flow if the administrator enabled it for your domain.
- DNS: when the administrator confirms the migration is complete, update your domain’s nameservers (or A records) at the registrar to point to the new panel. Wait for propagation before letting users hit the new endpoint.
- Verify: visit each migrated site, log in to each mailbox, run a test query against each database. Open a support ticket immediately if anything is missing.
Gotchas
- WordPress site URL: if the source cPanel served
https://oldhost.example.com/path/and you cut over tohttps://example.com/, runwp search-replaceon the migrated database to update the site URL. The migration pipeline does not do this; only you know your final URL. - Email signatures with absolute URLs: links pointing at the old domain may need updating in mail client signatures.
- Cron jobs that referenced
phpat an absolute path:/opt/cpanel/ea-php80/root/usr/bin/phpdoes not exist on Jabali. Re-edit the cron job to use the unqualifiedphp(the per-user FPM pool resolves it via the per-user$PATH).