Migrate from CyberPanel to cPanel: a step-by-step playbook

CyberPanel built a real audience between 2019 and 2023 as the free OpenLiteSpeed-based alternative to cPanel. Then October 2024 happened: CVE-2024-51567 and the related authentication-bypass chain were exploited at scale by the PSAUX ransomware crew, and a generation of small hosts and self-hosters discovered that "free panel" and "panel I can put my customers on" are not the same product. Most of the migration tickets we see for CyberPanel arrive with a ransom note attached or a customer who has been told their data might be on a leak site.

This guide is the post-incident, or just post-confidence, playbook for moving an existing CyberPanel server to cPanel & WHM. It assumes you have a working cPanel destination — if you don't, start with installing cPanel on a VPS and come back. Budget 30 minutes of customer-visible downtime per site if you batch the DNS cutover, plus half a day of operator time for a server with 20-50 accounts.

What doesn't translate one-to-one

CyberPanel and cPanel make different architectural choices that you need to account for:

The single biggest decision is the web server. If your customers depend on LSCache for WordPress performance — and most CyberPanel WordPress sites do — moving to Apache means a visible page-speed regression. The path that preserves performance is to license LiteSpeed Web Server for the destination cPanel box and keep the existing LSCache plugins in place after migration.

Step 1 — Inventory the source

Before touching the destination, build a complete list of what's on the CyberPanel box. SSH into the source as root and pull:

# All websites with their PHP version and document root
ls /home/ | grep -v -E '^(cyberpanel|cyberpanel-backup|lscpd|vmail|backup)$'

# All databases
mysql -e "SHOW DATABASES" | grep -v -E '^(Database|information_schema|mysql|performance_schema|sys|cyberpanel)$'

# All email accounts
ls /home/vmail/

# DNS zones managed by PowerDNS
mysql -u root powerdns -e "SELECT name FROM domains"

# Cron jobs per user
for u in $(ls /var/spool/cron/); do echo "=== $u ==="; cat /var/spool/cron/$u; done

Capture the output into a single migration manifest. The accounts you find under /home/ are the ones you'll recreate on cPanel; the databases and DNS zones map to them. Pay attention to mismatches — a database with no matching /home/ directory usually means a deleted-but-not-cleaned account, or, less innocently, an attacker-created database.

Step 2 — Prepare the cPanel destination

On the destination cPanel server:

1. Match or exceed the source's resource footprint. CyberPanel runs lean on OpenLiteSpeed; cPanel with Apache and the CloudLinux stack will need 25-40% more RAM for the same site count. A CyberPanel server running 30 WordPress sites in 4 GB will want 6-8 GB on cPanel.

2. Match the PHP version mix. CyberPanel exposes PHP 7.4 through 8.4 by default. On cPanel, install the matching versions through EasyApache 4 — see adding a PHP version to EasyApache 4. Don't migrate a PHP 7.4 site onto a cPanel server that only has 8.2 installed and hope for the best.

3. Install MySQL or MariaDB to match the source. CyberPanel ships MariaDB 10.5 or 10.6. If you're on MariaDB on the source, install MariaDB on cPanel too — this avoids the dump/restore edge cases around MariaDB-specific column types (JSON storage differences in particular).

4. Decide on the web server. If you're keeping LiteSpeed, install LiteSpeed on cPanel before the first account move so the document roots come up under LSWS from day one.

5. Pre-create the resolvers for nameserver glue. If the CyberPanel server was also the authoritative DNS, you'll either keep its IP for DNS only or move the zones into the cPanel server's BIND.

Step 3 — Move accounts one at a time

CyberPanel has no pkgacct-equivalent format, so there's no transfer-tool wizard. The practical pattern is to rebuild each account on cPanel, then copy files and databases in.

For each website on the source:

# On the source: package files and database
SITE=example.com
USER=examplec
tar -czf /tmp/$SITE-files.tar.gz -C /home/$SITE public_html
mysqldump --single-transaction --databases $(mysql -e "SHOW DATABASES" | grep "^${USER}_") > /tmp/$SITE-db.sql

On the destination cPanel server, create the account in WHM under Account Functions → Create a New Account, matching the source username where possible (some CyberPanel usernames will exceed cPanel's 16-character limit — note these for customer comms). Then move the archives over and restore:

# On the destination: extract into the new account
scp source:/tmp/$SITE-files.tar.gz /home/$USER/
tar -xzf /home/$USER/$SITE-files.tar.gz -C /home/$USER/
chown -R $USER:$USER /home/$USER/public_html
mysql < /tmp/$SITE-db.sql

# Update WordPress wp-config.php with the new DB password
sed -i "s/DB_PASSWORD.*/DB_PASSWORD', 'new-password-here'/" /home/$USER/public_html/wp-config.php

The wp-config edit is the step people skip and then waste an hour on. CyberPanel and cPanel generate different database passwords by default, so the dump restores cleanly but the site can't connect until the new credentials are wired in.

Step 4 — Email migration

CyberPanel stores mail under /home/vmail/<domain>/<user>/Maildir/. cPanel stores it under /home/<user>/mail/<domain>/<user>/. The Maildir format is identical, so an rsync of each user's Maildir into the cPanel layout preserves messages and IMAP folder structure:

rsync -av source:/home/vmail/$DOMAIN/$MAILUSER/Maildir/ \
  /home/$USER/mail/$DOMAIN/$MAILUSER/
chown -R $USER:$USER /home/$USER/mail/$DOMAIN/$MAILUSER/

After the rsync, recreate the mail account in cPanel → Email Accounts with the same password (or force a reset and communicate it). Then re-publish the DKIM key from cPanel — the CyberPanel key won't be in WHM, and using the wrong key tanks deliverability. See cPanel email deliverability with SPF, DKIM, and DMARC for the post-migration DNS records to publish.

Step 5 — DNS cutover

Drop TTLs on the public DNS to 300 seconds at least 24 hours before the cutover. At cutover:

1. Verify the destination cPanel site serves correctly over the IP directly using a --resolve curl: curl -I --resolve example.com:443:NEW.IP.HERE https://example.com/.
2. Update the A/AAAA records to point to the new server.
3. Watch error logs on both servers for 30 minutes. Anything still hitting the old IP after that is a stale resolver — either a customer cron or a monitoring service. Note the IPs, contact the owners, give them another 24 hours.
4. Re-issue SSL on the destination once DNS propagates. cPanel AutoSSL will pick up the validated domain on its next run, usually within an hour — or trigger it manually from WHM → SSL/TLS → Manage AutoSSL → Check "example" Now.

If AutoSSL fails after the cutover, the cause is almost always a stale CAA record set by CyberPanel pointing at Let's Encrypt only — work through the WHM AutoSSL failures decision tree.

Step 6 — Decommission carefully

Leave the CyberPanel server up for at least 7 days post-cutover, serving 301 redirects to the new server's hostname for any remaining direct-IP traffic. Pull customer email at least once per day from the old server during this window — IMAP clients can take days to fail over fully, and any mail delivered to the old vmail in that window is lost if you wipe early.

After the grace period, snapshot the source, archive the snapshot to cold storage for 90 days (long enough to cover a customer "we lost a file" ticket), and then destroy the instance. If the migration was triggered by a compromise, destroy is the only acceptable endpoint — do not reuse the OS image.

FAQ

Next steps

• New to the cPanel side? Walk through the cPanel VPS install and then WHM two-factor authentication setup before exposing the panel.
• Want to keep LiteSpeed performance on the destination? See installing LiteSpeed on cPanel and enabling LSCache for WordPress on cPanel.
• Migrating after a compromise? Lock the destination down with Imunify360 on cPanel and CloudLinux before the DNS cutover, not after.