How to Migrate from cPanel to DirectAdmin (Step by Step)

There are two real ways to move a hosting account from cPanel to DirectAdmin. The first is a conversion: DirectAdmin can restore a cPanel full-account backup and rebuild the account from it. The second is a manual move, site by site, with rsync, mysqldump and imapsync. Which one you use depends mostly on whether somebody has administrator access to the DirectAdmin server. This guide covers both, then the differences between the panels that cause the post-migration tickets: paths, database names, mail directories and DNS. If you are still deciding whether to move at all, read cPanel vs DirectAdmin first.

Choose your route

Before either: lower the DNS TTL to 300 seconds a day or two ahead, and take an inventory of what the account contains. Both steps are in the agency migration checklist.

Route A: create the cPanel backup

With root on the old server, package the account with cPanel's own script:

/scripts/pkgacct username
ls -lh /home/cpmove-username.tar.gz

Without root, log in to cPanel, open Backup in the Files section and use the full account backup option, with the home directory as destination. When it finishes, an archive named backup-<date>_<username>.tar.gz appears in the home directory. Download it or pull it over SSH:

scp username@old-host.example:backup-*_username.tar.gz .

Tip: a full backup includes everything in the home directory, including old backups and cache directories. Clean up first, and check the size with du -sh ~ so you know the archive fits in the remaining quota. A backup that fills the disk half-way through leaves a truncated archive.

Route A: restore it in DirectAdmin

DirectAdmin recognises cPanel archives and converts them during restore. The restore is done from the administrator's backup and transfer tool, so it needs admin access to the DirectAdmin server:

rsync -avP cpmove-username.tar.gz root@new-server.example:/home/admin/admin_backups/
ssh root@new-server.example 'chown admin:admin /home/admin/admin_backups/cpmove-username.tar.gz'

Then, at Admin level, open the backup/transfer page, choose restore, select the archive and the IP address the account should use, and submit. The job runs in the background and reports the result in the admin message system. DirectAdmin's own documentation has a page on migrating to DirectAdmin from cPanel; read it for the current list of what converts, because that list grows between versions.

On shared or reseller hosting you do not have that access, and the route is simpler still: give your host the archive and they restore it. If you are moving to us, ask for it through the free migration page.

What the conversion does not carry, and you must set again:

• The PHP version per domain, and custom PHP settings.
• SSL certificates issued by cPanel's AutoSSL. Issue new ones after the DNS switch.
• Data belonging to cPanel-only plugins.

Then skip to the checks at the end.

Route B: files

DirectAdmin gives every domain its own directory tree. Where cPanel has one public_html with addon domains in subdirectories, DirectAdmin has:

Create the domain in DirectAdmin first, then pull the files from the new server:

rsync -avz -e ssh \
  --exclude='addon.com/' \
  cpuser@old-host.example:public_html/ \
  /home/dauser/domains/example.com/public_html/

The --exclude keeps an addon domain's directory out of the main site; copy it separately into its own domains/addon.com/public_html/.

Then search for the old absolute path, which hides in config files, cron scripts and cache settings:

grep -rIl '/home/cpuser/public_html' /home/dauser/domains/example.com/public_html | head

Tip: open .htaccess and remove the block cPanel's MultiPHP Manager wrote, the lines between the php -- BEGIN cPanel-generated handler and END comments containing AddHandler application/x-httpd-ea-php. That handler does not exist on a DirectAdmin server, and leaving it in is the classic cause of a migrated site that offers its PHP files as downloads or returns a 500. Remove cPanel-generated php.ini and .user.ini files in the document root too, unless you put settings there yourself.

Route B: databases

Dump each database on the old server:

mysqldump --single-transaction --quick --routines --no-tablespaces \
  -u cpuser_wp -p cpuser_wp | gzip > cpuser_wp.sql.gz

Both panels prefix database names and database users with the account username and an underscore. If the DirectAdmin username is the same as the cPanel one, the names can stay identical and the site's config needs only the new password. If the username differs, so does the prefix, and every config file must be updated. Create the database and user in DirectAdmin's MySQL Management page, then import:

gunzip < cpuser_wp.sql.gz | mysql -u dauser_wp -p dauser_wp

For WordPress, update wp-config.php:

define('DB_NAME', 'dauser_wp');
define('DB_USER', 'dauser_wp');
define('DB_PASSWORD', 'the-new-password');
define('DB_HOST', 'localhost');

Tip: if the import stops with an error about a DEFINER, the dump contains views, triggers or routines owned by the old database user. Recreate that user name if the prefix allows it, or edit the definer out of the dump:

gunzip < cpuser_wp.sql.gz | sed -E 's/DEFINER=`[^`]+`@`[^`]+`//g' | mysql -u dauser_wp -p dauser_wp

Route B: mail

Create every mailbox in DirectAdmin's E-mail Accounts page, then copy messages over IMAP, one mailbox at a time:

imapsync \
  --host1 old-host.example --user1 anna@example.com --passfile1 old.pass --ssl1 \
  --host2 new-server.example --user2 anna@example.com --passfile2 new.pass --ssl2

This is slower than copying directories but it does not care how either server stores mail, which matters because some cPanel mailboxes use the mdbox format and cannot be copied as plain Maildir files. Passwords do not come across on this route: set new ones, or ask users for the current ones and reuse them.

Recreate forwarders, autoresponders and any catch-all by hand. Tell users the webmail address has changed: cPanel's port 2096 does not exist on the new server.

DNS zone differences

If the zone moves to the DirectAdmin server, do not assume the default zone equals the old one. Compare them record by record:

dig +noall +answer example.com MX @old-ns.example
dig +noall +answer example.com TXT @old-ns.example
dig +noall +answer default._domainkey.example.com TXT @old-ns.example

What differs in practice:

• DKIM selector. cPanel signs with the selector default; DirectAdmin signs with x. The old default._domainkey record is useless after the move. Enable DKIM in DirectAdmin and publish the x._domainkey record it generates.
• SPF. The record must name the new server's IP. See SPF, DKIM and DMARC explained.
• cPanel service records. Names such as cpanel, webmail, webdisk, cpcontacts and cpcalendars point at services that will not exist. Drop them.
• Custom records. Third-party verification TXT records, external MX records for Microsoft 365 or Google Workspace, and subdomains pointing elsewhere must be copied exactly.

Post-migration checks

Test against the new server before switching DNS:

curl -skI --resolve example.com:443:203.0.113.55 https://example.com/ | head -n 1

Then work through the list:

• Set the PHP version for each domain to what the site ran on cPanel: changing the PHP version in DirectAdmin.
• Recreate cron jobs. Paths change twice: the script path gains domains/example.com/, and cPanel's /opt/cpanel/ea-php82/root/usr/bin/php becomes the PHP binary your DirectAdmin host provides, commonly /usr/local/bin/php.
• Log in to the site's admin area, upload a file, submit a form, send and receive a test email.
• After the DNS switch, issue certificates: free Let's Encrypt SSL in DirectAdmin.
• Run the final rsync, database import and imapsync pass just before the switch, and one more imapsync a day after.

Keep the cPanel account for a week before cancelling. The mailbox someone forgot and the cron job nobody listed both turn up in that week, and they are only recoverable while the old account exists.