Import an account from cPanel, DirectAdmin or HestiaCP

NovaPanel imports a hosting account from a cPanel, DirectAdmin or HestiaCP backup archive. You take a backup on the old panel, upload it here, and the panel recreates the account: the sites and their files, addon domains and subdomains, databases with their data, mailboxes with their stored messages, forwarders, DNS records, and each site's PHP version.

It works from a backup file, not by logging in to the old server. That means it works even when the old hosting has already been cancelled, and it means you need no shell access on either machine — which matters, because most people leaving shared hosting have neither.

Account migration is a Pro feature. It is grouped with web server selection for a reason: migrated sites usually rely on .htaccess, and honouring those means running Apache or OpenLiteSpeed, which is the same entitlement.

Take the backup

cPanel — in the account's cPanel:

• Files → Backup → Download a Full Account Backup
• Backup Destination: Home Directory, then Generate Backup
• It emails you when it finishes. The file appears in File Manager at the top of the home directory, named backup-<date>_<time>_<user>.tar.gz. Download it.

With root SSH on the cPanel server, /scripts/pkgacct <username> produces the same thing as /home/cpmove-<username>.tar.gz. Either works.

DirectAdmin:

• User level: Account Manager → Create/Restore Backups → tick everything → Create Backup. It lands in the account's backups/ folder; download it from File Manager.
• Admin level: Admin Tools → Admin Backup/Transfer, which produces user.admin.<username>.tar.gz.

Current DirectAdmin versions write .tar.zst by default. That is read directly, so upload whatever DirectAdmin gives you.

HestiaCP:

• User level: User → Backup → Create Backup, then download it.
• With root: v-backup-user <username>, which writes to /backup/.

Hestia produces <user>.<date>_<time>.tar, an uncompressed archive holding a compressed archive for each site, each mail domain and each database. Upload it as it is — NovaPanel unpacks both layers.

Compression does not matter. .tar.gz, .tar.zst, .tar.xz, .tar.bz2 and plain .tar are all read as they come; there is nothing to convert first.

Upload it

In the admin panel, open Migrate Account and click Upload archive. Large accounts take a while — keep the tab open until the progress bar finishes. If you do have shell access on the NovaPanel server you can instead drop the file straight into /var/lib/novapanel/migrations.

Read the archive

Select the archive and click Read archive. This creates nothing. It reports what the archive actually contains — domains and their types, databases with their sizes, mailboxes and how much mail each holds, forwarders, DNS records, cron jobs — and a list of things that will not carry across.

Read that list. It is the useful part. It will tell you, for instance, that a DirectAdmin backup contains no DNS records at all, that HestiaCP does not record which domain is the account's main one so the panel had to choose, that this server's web engine does not read .htaccess, or that the account has mailboxes with no stored mail in the archive. Any of those is easier to deal with before the migration than after.

Dry run, then migrate

Set the NovaPanel username and contact email. Keep the original username if you can: database names carry their original prefix, so changing the username renames every database and the site's configuration files will need updating to match. The contact email must not already belong to another account here.

Run the dry run. It walks the entire migration and creates nothing, listing every resource it would make. The real migration is not offered until a dry run has completed — not as a formality, but because the dry run is the only thing that reports which resources already exist on this server and would therefore be skipped.

Then Migrate for real. Progress appears as it goes; a large account runs for a while and you can leave the page, since the migration continues on the server and the result is kept.

Save the credentials

The result ends with a credentials box: the account, each database, and each mailbox. These are shown once. They are stored hashed or known only to the database server, so if you close the page without saving them, every one has to be reset by hand.

The account signs in to the customer panel with its email address, not its username.

What does not carry across

Everything in this list is reported during the migration too — nothing here happens silently.

• Mailbox passwords. Every mailbox gets a new password. The other panels store SHA-512 crypt hashes and NovaPanel stores bcrypt; there is no conversion between them, and writing the old hash across would produce a mailbox that rejects every password including the right one. Those users update their mail clients once. Plan to tell them.
• Cron jobs arrive disabled. They are imported with their schedule and command, and the account's home path is rewritten for this server, but nothing runs until you enable it under Cron Jobs. A migrated job that started running immediately could email a customer list or back up to the old server while DNS still points there.
• SPF, DKIM and DMARC records. Not copied, deliberately. This server publishes its own, and two SPF records on one name is a permanent error that every receiver treats as a misconfigured domain.
• Address records and nameservers. Not copied — they point at the old server. NovaPanel creates its own pointing here. Everything else in the zone (MX, TXT, CNAME, SRV) does come across.
• HestiaCP does not name a main domain. cPanel and DirectAdmin both record which domain the account belongs to; Hestia treats every web domain as equal. The panel picks the domain the others sit beneath and tells you it did, so check that line in the plan before migrating — if it chose wrong, the account's home page ends up on the wrong hostname.
• DirectAdmin carries no DNS at all. That is the backup format, not a limitation here. If the account's email is hosted elsewhere — Google Workspace, Microsoft 365 — copy its MX records from the old server before switching nameservers, or its mail stops while the website carries on working.
• SSL certificates. Not imported; NovaPanel issues fresh Let's Encrypt certificates once DNS points here, which is almost always what you want.
• Autoresponders, mail filters, mailing lists and extra FTP logins. Reported so you know they existed, but recreated by hand.

.htaccess and the web engine

cPanel and DirectAdmin both run Apache, and HestiaCP most often runs nginx in front of Apache, where .htaccess is read on every request. NovaPanel's default engine does not read it at all. WordPress permalinks are handled either way, but custom rewrites, redirects and access rules would stop working silently.

The panel checks this for you and says, before you migrate, whether this server's engine will honour the archive's rule files. If it will not, switch the server or the migrated sites to Apache or OpenLiteSpeed.

After the migration

• Update the site's database credentials. wp-config.php and equivalents still name the old database user and password. Use the ones from the credentials box.
• Test against the new server before touching DNS. Point your own machine at it with a hosts-file entry and check the site, the admin area, and anything that sends mail.
• Compare the DNS zone against the old server, then switch nameservers. Keep the old server reachable until DNS has propagated.
• Review and enable the cron jobs.
• Old messages that arrived after the backup are not in the archive. If the customer needs them, an IMAP sync from the old server brings them over.

If something goes wrong

Nothing is ever overwritten. An account, hostname, database or mailbox that already exists is skipped and reported rather than replaced, which means re-running a migration is safe — it fills in what is missing and leaves what is there.

If a migration went wrong badly enough to want a clean start, delete the account from the panel (which removes its sites, databases, mailboxes and system user) and run the migration again. The archive is untouched, and so is the old server.

Doing this by hand instead is still documented: see the manual cPanel migration guide, which is also the right reference for anything the importer reports it could not bring across.