cPanel to DirectAdmin migration guide for 2026: move accounts, databases, email, DNS, SSL, and backups safely with a tested rollback plan.

A cPanel to DirectAdmin migration starts with a full cPanel account backup, a clean DirectAdmin server, a controlled transfer, conversion with the DirectAdmin cPanel migration tool, then verification of websites, databases, email, DNS, SSL, cron jobs, and application paths. The safe process is not “copy files and hope.” The safe process is a staged migration with a rollback point, a short DNS cutover window, and no cancellation of the old cPanel account until every service has been tested.

The reason this matters in 2026 is simple. Many hosting companies, agencies, and server owners are tired of rising cPanel license costs and want a practical cPanel alternative. DirectAdmin is usually the cleanest landing point because it supports multi-user hosting, reseller structures, domains, databases, mailboxes, DNS, SSL, backups, and a familiar hosting-panel workflow without forcing customers into a completely different operating model.

This guide is written for sysadmins, agencies, reseller hosts, and small hosting providers who need to migrate real accounts without losing data. If you want this handled for you, ServerSpan DirectAdmin Management is the natural handoff. If you are doing it yourself, follow the runbook in order.

Before you migrate: what this guide assumes

This guide assumes you have:

• root access to the source cPanel server
• root access to the destination DirectAdmin server
• enough free disk space on both servers for full account backups
• working SSH between the two servers
• a recent DirectAdmin installation on a supported operating system
• time for DNS propagation and post-migration testing

If you only have a single cPanel user login and no root access, you can still migrate, but the process changes. You will need full account backups from the cPanel interface or provider support. You may not be able to use /scripts/pkgacct yourself.

Do not start a production migration from an unpatched server or a half-built DirectAdmin node. Fix the operating system, hostname, resolver, firewall, DirectAdmin license, nameservers, backup path, and mail stack first. A migration is hard enough without debugging a broken destination server at the same time.

Pre-migration checklist

Run this checklist before touching account data:

• Lower DNS TTL to 300 seconds at least 24 hours before migration.
• Record current nameservers, A records, MX records, TXT records, SPF, DKIM, and DMARC.
• Export or screenshot custom DNS zones before changing anything.
• List all cPanel accounts, domains, addon domains, parked domains, and subdomains.
• List all databases and database users.
• List all mailboxes, forwarders, autoresponders, filters, and mailing lists.
• Check disk usage on the source server and destination server.
• Check PHP versions used by the websites.
• Check cron jobs and hardcoded paths.
• Take an independent off-server backup before starting.

The DNS TTL step is not cosmetic. If the current TTL is 14400 seconds or higher and you switch nameservers without preparing, some visitors and mail servers may keep hitting the old server for hours. Lowering TTL in advance gives you a cleaner cutover and a faster rollback if something breaks.

The 10-step cPanel to DirectAdmin migration process

Step 1: Generate a full cPanel account backup

On the cPanel server, generate a full package backup for each account. With root access, the standard command is:

/scripts/pkgacct USERNAME /home

This creates a backup file such as:

/home/cpmove-USERNAME.tar.gz

For multiple accounts, create a list first:

ls /var/cpanel/users > /root/cpanel-users.txt

Then package accounts one by one. Do not blindly run a massive loop on a busy production server without checking disk space. Full account backups can consume serious I/O and storage, especially on servers with large mailboxes.

df -h
du -sh /home/* | sort -h

If the source server is low on disk, move older backups off the machine first or generate packages to another mounted storage path.

Step 2: Transfer the cPanel backup to the DirectAdmin server

Create a clean import directory on the DirectAdmin server:

mkdir -p /home/admin/cpanel_backups

From the cPanel server, transfer the package with rsync:

rsync -avz --progress /home/cpmove-USERNAME.tar.gz root@DIRECTADMIN_IP:/home/admin/cpanel_backups/

For large accounts, rsync is safer than a browser download because it handles interrupted transfers better and shows progress. After transfer, verify file size on both sides:

ls -lh /home/cpmove-USERNAME.tar.gz
ssh root@DIRECTADMIN_IP 'ls -lh /home/admin/cpanel_backups/cpmove-USERNAME.tar.gz'

For very large mail accounts, transfer during a quiet period. Maildir trees with hundreds of thousands of small files can take longer than the raw data size suggests.

Step 3: Convert the cPanel backup with DirectAdmin's migration tool

DirectAdmin provides an official cPanel-to-DirectAdmin conversion tool. Paths can change between DirectAdmin versions, so check the official DirectAdmin migration documentation before running it on production. The common workflow uses the conversion script under the DirectAdmin shared migration directory:

cd /usr/local/directadmin/shared/cpanel_to_da
./cpanel_to_da.sh /home/admin/cpanel_backups/cpmove-USERNAME.tar.gz

On some installations, the tool expects backups in a specific directory and writes converted DirectAdmin backup files into an output path. Do not guess. Read the script help or official docs on the destination server:

cd /usr/local/directadmin/shared/cpanel_to_da
./cpanel_to_da.sh --help 2>/dev/null || ls -lah

After conversion, restore the converted DirectAdmin backup through the DirectAdmin admin backup restore interface, or via the CLI method recommended by the current DirectAdmin documentation.

The important operational point is this: conversion is not the same thing as verification. A successful conversion log only means the tool completed. It does not prove that every website, mailbox, database, cron job, DNS record, and SSL certificate works.

Step 4: Verify databases and application configuration

After restore, check that the databases and database users exist in DirectAdmin. For WordPress sites, verify wp-config.php:

grep -E "DB_NAME|DB_USER|DB_HOST|table_prefix" /home/USERNAME/domains/DOMAIN/public_html/wp-config.php

Common breakage includes:

• database username changed during conversion
• database name prefix differs from cPanel
• DB_HOST still points to an old remote MySQL host
• hardcoded absolute paths still reference /home/olduser/public_html
• PHP version differs from the old cPanel account

Test database login manually:

mysql -u DB_USER -p DB_NAME

For WordPress, enable debug logging only during troubleshooting:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Then check:

tail -f /home/USERNAME/domains/DOMAIN/public_html/wp-content/debug.log

Turn debug display off after testing. Leaving errors visible on a production site is sloppy and can leak paths or plugin details.

Step 5: Verify and sync email carefully

cPanel to DirectAdmin migrations can restore mailboxes, but email deserves extra attention because mail can arrive during the migration window. The safest approach is to keep the old cPanel mail service online until after DNS cutover and then run a final IMAP sync.

Install imapsync on a temporary admin machine or migration server:

apt update
apt install imapsync

Then sync a mailbox from old to new:

imapsync \
  --host1 old.mail.server \
  --user1 user@domain.com \
  --password1 'OLD_PASSWORD' \
  --host2 new.mail.server \
  --user2 user@domain.com \
  --password2 'NEW_PASSWORD' \
  --ssl1 --ssl2

For many mailboxes, script it from a CSV file instead of running commands manually. Also warn users before migration. If they use desktop mail clients, they may need to update server names, ports, and passwords after cutover.

Check mail folders, sent items, read status, forwarders, autoresponders, spam settings, and filters. Do not assume email is fine because the inbox exists.

Step 6: Check DNS zones before changing nameservers

Before changing nameservers, compare DNS records from cPanel and DirectAdmin. This is where many migrations break email or third-party services.

dig DOMAIN A
dig DOMAIN MX
dig DOMAIN TXT
dig www.DOMAIN CNAME
dig _dmarc.DOMAIN TXT

Record types to verify:

• A and AAAA records for the root domain and subdomains
• CNAME records for www and service aliases
• MX records for mail routing
• TXT records for SPF, DKIM, DMARC, Google, Microsoft, payment gateways, and verification services
• SRV records if the domain uses special mail or collaboration services

Do not overwrite a DNS zone with only website records. Many domains depend on hidden TXT records for email, analytics, payment processors, CRMs, and SaaS tools. Losing one TXT record can break a business process that nobody connects to the migration until days later.

Step 7: Re-issue SSL certificates on DirectAdmin

SSL certificates from cPanel may not map cleanly to DirectAdmin. In most cases, the clean path is to issue fresh Let's Encrypt certificates after DNS points to the DirectAdmin server.

Before cutover, you can test the site locally by editing your workstation hosts file and pointing the domain to the DirectAdmin IP. After DNS cutover, issue or re-issue SSL from DirectAdmin.

Check HTTPS after issuance:

curl -I https://DOMAIN
openssl s_client -connect DOMAIN:443 -servername DOMAIN </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

If the certificate fails, check DNS first. Let's Encrypt HTTP validation will fail if the domain still points to the old cPanel server or if a firewall blocks port 80.

Step 8: Verify SPF, DKIM, and DMARC

Email authentication often breaks silently during panel migrations. If DirectAdmin becomes the new mail sender, SPF and DKIM must reflect that. If mail remains with a third-party provider, do not replace those records with local defaults.

dig DOMAIN TXT
dig default._domainkey.DOMAIN TXT
dig _dmarc.DOMAIN TXT

Typical SPF problems after migration:

• old cPanel server IP remains in SPF but new DirectAdmin IP is missing
• SPF includes two conflicting records
• third-party mail sender was removed accidentally
• domain now sends through DirectAdmin but DKIM is not enabled

Send a real test email to Gmail, Outlook, and a mailbox you control. Check headers. Do not rely only on “message sent successfully” from the webmail interface.

Step 9: Test all services after cutover

After changing nameservers or A records, test the site like a user and like a sysadmin.

Website checks:

• home page loads over HTTPS
• admin login works
• forms submit successfully
• uploads work
• pretty permalinks work
• cron jobs run
• PHP version is correct
• error logs are clean

Command checks:

curl -I https://DOMAIN
curl -I https://www.DOMAIN
dig @1.1.1.1 DOMAIN A +short
dig @8.8.8.8 DOMAIN MX +short
tail -n 100 /var/log/httpd/domains/DOMAIN.error.log 2>/dev/null
tail -n 100 /var/log/nginx/domains/DOMAIN.error.log 2>/dev/null
tail -n 100 /var/log/exim/mainlog 2>/dev/null

Email checks:

• webmail login works
• IMAP works from a desktop client
• SMTP authentication works
• inbound mail arrives
• outbound mail reaches Gmail and Outlook
• forwarders and autoresponders work
• spam filtering behaves as expected

For WordPress and WooCommerce, place a test order if possible. A store that loads but cannot send order emails or process checkout is not migrated.

Step 10: Keep the old cPanel account until rollback is no longer needed

Do not cancel the old cPanel account on the day of migration. Keep it online for at least 7 to 14 days, longer for complex mail migrations or high-value stores.

Before cancellation, confirm:

• all DNS resolvers point to the new DirectAdmin server
• no recent web traffic is hitting the old cPanel server
• no mail is still arriving on the old server
• all users can access mail on the new server
• all databases and applications are stable
• off-server backups exist for the new DirectAdmin environment

On the old server, check logs before shutting anything down:

tail -f /usr/local/apache/logs/access_log
tail -f /var/log/exim_mainlog

If the old server still receives meaningful traffic or mail, do not cancel it. Find out why. DNS caches, forgotten MX records, hardcoded IPs, and external integrations can keep old infrastructure alive longer than expected.

Rollback plan: what to do if the migration fails

A real migration plan includes rollback. If the DirectAdmin side breaks badly, you need a clean way back.

Rollback requires three things:

• the old cPanel account still online
• DNS TTL already lowered before migration
• no irreversible writes lost during the cutover window

If rollback is needed, point DNS back to the old cPanel IP or nameservers:

dig DOMAIN A +short
dig DOMAIN NS +short

Then re-check website and mail on the old server. If the site accepted orders, form submissions, or user changes on the DirectAdmin server before rollback, export and replay that data manually. This is why high-change sites need a maintenance window or write freeze during final sync.

The best rollback is the one you never need. But if you do need it, DNS TTL and old-server retention decide whether rollback takes minutes or becomes a public incident.

Common migration failures and fast fixes

Problem	Likely cause	Fix
Website shows database connection error	Wrong database name, user, password, or host	Check DirectAdmin database names and update application config
WordPress admin works but pages return 404	Rewrite rules or web server config mismatch	Re-save permalinks or fix Nginx/Apache rewrite rules
Mailboxes exist but users cannot log in	Password mismatch or mail client using old hostname	Reset mailbox password and update IMAP/SMTP settings
Outbound mail lands in spam	SPF, DKIM, DMARC, PTR, or IP reputation issue	Fix DNS records, enable DKIM, verify reverse DNS
SSL certificate fails	DNS points to old server or port 80 is blocked	Verify DNS and firewall, then re-issue certificate
Uploads fail	Wrong ownership or permissions	Fix ownership under the DirectAdmin user and web server model
Cron jobs stop running	Old paths from cPanel environment	Update PHP binary and script paths

The pattern is predictable. Most cPanel to DirectAdmin migration failures are not caused by the conversion tool itself. They are caused by paths, DNS, mail authentication, PHP versions, permissions, and assumptions carried over from the old environment.

When to use managed DirectAdmin migration instead of doing it yourself

Do the migration yourself if you have root access, understand DNS, can read mail logs, know how to restore backups, and can tolerate the troubleshooting window. Hand it off if the account hosts a store, customer email, reseller clients, production databases, or business-critical services.

The dangerous migrations are not the large ones. They are the poorly understood ones. A small website with important email can cause more business damage than a large static site if mail routing breaks and nobody notices for two days.

If you want the DirectAdmin side built, hardened, migrated, and checked by people who run hosting infrastructure every day, use ServerSpan DirectAdmin Management. For customers moving away from cPanel, this is exactly the kind of work where managed help pays for itself.

Where ServerSpan fits in the migration path

A cPanel to DirectAdmin migration often means more than switching panels. It can also mean changing hosting architecture, nameservers, mail handling, backup policy, support model, and reseller structure.

ServerSpan can support the migration path in several ways:

• DirectAdmin Management for server administration, panel setup, hardening, troubleshooting, and migration support
• DirectAdmin web hosting for customers who want shared hosting without running their own server
• reseller hosting for agencies and hosting providers moving clients from cPanel to DirectAdmin
• cPanel Management for source-side cleanup, backups, and transition work before leaving cPanel
• Linux Administration for custom migration, mail repair, DNS cleanup, and post-migration debugging

The cleanest migration is not always the cheapest one. The cleanest migration is the one where accounts, databases, mailboxes, DNS records, SSL certificates, and support responsibility land in a stable state.

The practical answer

Migrating from cPanel to DirectAdmin is a controlled process: lower DNS TTL, create full cPanel backups, transfer them safely, convert with the DirectAdmin migration tool, restore accounts, verify databases, sync email, check DNS, re-issue SSL, validate SPF/DKIM/DMARC, test every service, and keep the old cPanel account online until rollback is no longer needed.

The migration is not difficult because the commands are complex. It is difficult because each account can hide old paths, mail rules, DNS dependencies, PHP version assumptions, and user habits. Treat the move like infrastructure work, not like a file copy.

If you are moving because cPanel costs keep rising and DirectAdmin is your next platform, plan the migration properly. If the accounts matter, use managed DirectAdmin migration support instead of discovering the edge cases during live cutover.