Migrate from cPanel to NovaPanel

Let's be straight: NovaPanel does not have a one-click cPanel importer yet. Moving away from cPanel to anything else is a manual job everywhere, and this guide is the reliable hand path. It's account-by-account, but each account is usually 30–60 minutes of unattended copying. If you have a handful of accounts, do them one evening. If you have hundreds, wait for the importer (it's on the roadmap).

What you'll need

• SSH (root) on the source cPanel server, or the ability to generate a full cPanel account backup.
• SSH (root) on the destination NovaPanel server.
• Access to the domain's DNS (registrar or wherever the nameservers point) for the final cutover.
• A short maintenance window per account — realistically the only visible downtime is DNS propagation, which you control by lowering TTL ahead of time.

The plan

For each cPanel account you migrate the four things a cPanel account actually holds: files, databases, email, and DNS. You land all of it on NovaPanel first, test against the new server without touching live DNS, and only then flip DNS. Nothing on the old server is deleted until you've confirmed the new one works.

Step 1 — Create the account on NovaPanel

In the admin panel: Customers → Add account. This creates the Linux user and the account's home under /srv/sites/<user>. Then log in as that customer (or use Login as) and add each domain the cPanel account hosted under Sites → Add site. The account's first site lives at /srv/sites/<user>/public_html/; each additional site gets its own folder, e.g. /srv/sites/<user>/<domain>/public_html/.

Match the PHP version the site ran on cPanel (Sites → the site → PHP version). Starting like-for-like avoids plugin/app breakage; you can upgrade PHP after the migration is stable.

Step 2 — Move the files

The cleanest source is cPanel's own backup, but a plain rsync or tarball is faster if you have SSH. cPanel stores a site's files under /home/<cpanel-user>/public_html (addon and subdomain docroots live in their own folders under the same home).

# On the cPanel server — tar just the docroot
cd /home/<cpanel-user>/public_html
tar czf /tmp/site.tar.gz .
scp /tmp/site.tar.gz root@new-host:/tmp/

On NovaPanel, extract into the matching docroot and fix ownership:

sudo -u <user> tar xzf /tmp/site.tar.gz \
  -C /srv/sites/<user>/<domain>/public_html/
sudo chown -R <user>:<user> /srv/sites/<user>/<domain>

No SSH? Use the customer panel's File Manager: upload the tarball and extract it from the right-click menu. Repeat for every addon domain and subdomain the account had — each is just another site + docroot on NovaPanel.

Step 3 — Move the databases

List the account's databases in cPanel (or mysql -e "show databases" as root) and dump each one:

# On the cPanel server
mysqldump -u root <cpanel_dbname> > /tmp/<dbname>.sql
scp /tmp/<dbname>.sql root@new-host:/tmp/

On NovaPanel, create a database for each under Databases → Create database (note the new name, user, and password), then import — either from the panel (Databases → the DB → Import, pick the .sql) or over SSH:

mysql -u <new-user> -p <new-db> < /tmp/<dbname>.sql

Then update each app's config to point at the new DB name/user/password — for WordPress that's wp-config.php; for most other apps a .env or a config file in the docroot. If the app is WordPress, the dedicated WordPress migration guide covers the config + search-replace details.

Step 4 — Recreate email

Mailboxes don't transfer with the files. For each mailbox the cPanel account had, recreate it in the customer panel under Email → Add mailbox (same address, set a new password). NovaPanel provisions the Dovecot/Postfix entries and publishes the mail DNS (MX, SPF, DKIM, DMARC) automatically — see the email setup guide.

To bring across existing messages, the reliable tool is imapsync (old server → new server, per mailbox) once both mailboxes exist. If the accounts are low-volume or the users are fine starting fresh, you can skip message transfer entirely.

Step 5 — Recreate DNS

If NovaPanel will run authoritative DNS for the domain, recreate the zone under DNS. Export the existing records from cPanel first — in cPanel's Zone Editor, or on the server the zone file lives at /var/named/<domain>.db — and copy the A/AAAA/CNAME/MX/TXT records across, pointing the A records at the new server's IP. NovaPanel already adds the mail records from Step 4, so you mainly need the website and any custom records.

If DNS stays with an external provider (Cloudflare, the registrar), you don't recreate the zone here — you just change the A/AAAA records there at cutover (Step 7).

Step 6 — Test before you flip DNS

Point your own machine at the new server without changing real DNS. Add a line to your local /etc/hosts:

203.0.113.42  example.com www.example.com

Now browse the site as if DNS had moved. Check the homepage, a few inner pages, the app's admin login, image-heavy pages, and any forms. Fix anything broken now, while real traffic is still hitting the old server. Remove the /etc/hosts line when you're done testing.

Step 7 — Flip DNS

A day before cutover, drop the domain's DNS TTL to 5 minutes so the change propagates fast. At cutover, change the A (and AAAA) records to the new server's IP — either at your external DNS provider, or by moving the domain's nameservers to NovaPanel if it's running DNS.

Caddy on the new server issues a fresh Let's Encrypt certificate within seconds of the first real HTTPS request. Watch it if you like: journalctl -u novapanel -f.

Step 8 — Decommission the old account

Leave the cPanel account running for at least 24–48 hours after the DNS flip — stale caches will still send a trickle of traffic (and mail) to the old server until every TTL expires. Once it's quiet, cancel the old account. Do this per-account so a problem on one migration never affects the others.

Common gotchas

• Ownership. Tarballs from cPanel often carry the old UID. Always run chown -R <user>:<user> on the extracted files or the site won't be writable.
• Addon & parked domains. A cPanel account can hide several sites behind one login. Each addon domain is its own site + docroot on NovaPanel — don't forget them.
• Hardcoded paths. Apps that stored an absolute path (/home/<cpanel-user>/...) in the database or a config need it changed to /srv/sites/<user>/....
• Mail cutover window. Recreate mailboxes and mail DNS before flipping the domain's DNS, or inbound mail bounces during the gap.
• PHP version. Migrate on the same PHP version the site ran, then upgrade once it's stable — a jump from 7.4 to 8.3 breaks some older plugins.

An automated importer that does most of this in one step is the headline item on our roadmap — it'll appear in the changelog when it ships. Until then, this hand path is dependable and, for a modest number of accounts, quick.