How to Migrate cPanel to DirectAdmin

What Changes When You Move from cPanel to DirectAdmin?

cPanel and DirectAdmin solve many of the same hosting tasks, but they are not identical products and they do not store every setting in the same place. A migration is therefore more than copying a public_html directory. The account must be converted so DirectAdmin can recreate its user, domains, website files, databases, mailboxes, DNS zone, FTP accounts and other supported settings in the structure expected by the destination server.

On cPanel, the main website normally lives under /home/USERNAME/public_html. DirectAdmin normally stores each domain in its own directory, such as /home/USERNAME/domains/example.com/public_html. Email paths and account configuration also differ. DirectAdmin's importer reads the cPanel archive, translates supported account data and produces a DirectAdmin-compatible backup for restoration.

The website address does not need to change

Your domain name, public URLs and WordPress site address can remain the same. Visitors do not need to know which control panel manages the service. What changes behind the scenes is the server IP, account layout and possibly the nameservers or DNS records. A well-planned migration preserves the same domain while directing it to the new hosting only after testing is complete.

The control-panel workflow will look different

Customers moving from cPanel will find familiar features under different names and menus. Addon domains become normal domains under DirectAdmin's domain management. AutoSSL is replaced by DirectAdmin's automated certificate handling. EasyApache does not move across; DirectAdmin uses CustomBuild to manage its web server, PHP versions and associated software. Existing websites do not need to be rebuilt simply because the panel changes, but custom server-level cPanel configuration must be recreated rather than copied blindly.

Not every cPanel feature has a direct equivalent

Normal PHP and WordPress sites are the straightforward cases. More specialised services need review. DirectAdmin's own migration guidance notes that Mailman mailing lists are not converted into an equivalent list system, and applications dependent on PostgreSQL or Ruby require manual planning because those features are not handled in the normal cPanel conversion path. Custom cPanel plugins, bespoke EasyApache modules and server-wide Apache includes are also outside an ordinary account archive.

Choose the Correct Migration Route

Before creating backups, decide which of the following situations matches your move. This prevents you from following root-level commands when you only have a normal hosting login, or choosing a manual upload when DirectAdmin can pull the accounts directly from a cPanel server.

Choose DirectAdmin web hosting when you want the hosting company to maintain the operating system, web server, mail services and control panel. Choose a UK VPS when root access and complete server control are actual requirements. A VPS is self-managed, so the server owner is responsible for updates, security, backups, monitoring and migration checks.

Before You Start: Build a Migration Inventory

The backup is only one part of the move. A short inventory makes it much easier to identify missing data and prevents an external email service or special DNS record from being overwritten during the cutover.

• Record every primary domain, addon domain, alias, subdomain and redirect.
• List the cPanel account usernames and identify which accounts belong to resellers.
• Check website disk usage, database sizes and mailbox storage.
• Record the PHP version and extensions required by each important website.
• List MySQL databases, database users and applications that use them.
• Export or photograph the current DNS zone, including MX, SPF, DKIM, DMARC and verification records.
• Identify whether email is hosted locally, with Microsoft 365, Google Workspace or another provider.
• Record cron jobs and inspect them for cPanel-specific file paths.
• Check SSL certificates, redirects and forced HTTPS behaviour.
• List FTP users, SSH access, scheduled backups and any application integrations tied to the old IP.

Check available disk space before packaging accounts

Creating a full account archive needs temporary disk space on the cPanel server, and conversion and restoration need working space on the DirectAdmin server. cPanel's current guidance for pkgacct says the source and destination should have free space greater than twice the size of the largest account, plus an additional 1GB. Treat that as a starting point rather than a target; large databases and compressed mail stores can create additional temporary usage.

df -h
df -i
du -sh /home/* 2>/dev/null | sort -h

Lower DNS TTL before the move

If you manage the DNS zone, lower the TTL for records that will change—usually the website A or AAAA record and possibly mail records—around 24 to 48 hours before the cutover. A value such as 300 seconds can make the final switch faster, although resolvers may still retain older answers. Do not change MX records simply because the website is moving if email is hosted elsewhere.

Take a backup outside both servers

Keep a copy of the original full account archive somewhere other than the source and destination servers. An archive stored only on the server being decommissioned is not a safe rollback plan. Confirm that the file has a sensible size and can be listed with tar before deleting anything.

ls -lh cpmove-USERNAME.tar.gz
tar -tzf cpmove-USERNAME.tar.gz | head -n 40

Route 1: Move from cPanel Hosting to a DirectAdmin Host

This is the usual route for a website owner changing providers. You have a cPanel login but no root access to the old server, and the new provider operates DirectAdmin. You create the full account backup; the new provider performs the trusted account conversion and restore.

Step 1: Generate a full cPanel account backup

Sign in to cPanel and open Files → Backup or Files → Backup Wizard. Choose a Full Backup, select Home Directory as the destination and enter an email address for the completion notification. The backup runs on the server and appears for download when it is complete.

A full backup is different from downloading the home directory. It packages account data needed for a migration, including website files, databases, email and supported configuration. A partial home-directory backup cannot recreate a complete hosting account.

Step 2: Download the archive and note its username

Download the finished .tar.gz file to your computer. cPanel user-generated backups are commonly named in a form beginning with backup-, while the DirectAdmin conversion documentation expects a trusted archive named cpmove-USERNAME.tar.gz. Do not rename a partial backup and assume it has become a full one. Tell the destination provider the original cPanel username and let them confirm the correct import filename.

Step 3: Send the backup securely

Large account backups should not be attached to email. Upload the archive through the secure method offered by the destination provider, such as a migration upload area, SFTP or a temporary server location. Share credentials through a protected channel and remove temporary access after the transfer.

Step 4: The DirectAdmin provider imports the account

The destination administrator verifies that the archive came from a trusted source, converts it to DirectAdmin format and restores it under the correct account or reseller. Ordinary users should not expect to upload an untrusted cpmove archive and restore a complete system user themselves; the conversion operates at administrator or authorised reseller level because the archive contains account-level data.

Step 5: Test before pointing the domain

Ask for the new server IP and the restored DirectAdmin login. Test the site with a local hosts-file entry or a command such as curl --resolve. Check WordPress, forms, database-driven pages, redirects and email before changing DNS. The full testing process appears later in this guide.

Route 2: Move cPanel Accounts to a VPS with DirectAdmin

This route gives you control of the destination server. It is suitable when you need your own users, reseller structure, server software or root access. It also carries more responsibility: the DirectAdmin installation must be secured, monitored, backed up and kept updated after the migration.

The move has five broad phases:

Prepare a Clean Rocky Linux VPS

DirectAdmin should be installed on a clean operating system without an existing hosting panel or manually installed Apache, Nginx, PHP, MySQL or mail stack. At the time of writing, DirectAdmin supports current Rocky Linux releases within its published support window. Rocky Linux 9 is a sensible choice for a new general-purpose hosting VPS when your required third-party software supports it.

Choose a proper server hostname

Use a fully qualified hostname that is not the same as a customer's hosted domain, for example server1.example-host.co.uk. Create an A record pointing that hostname to the VPS IP before or immediately after installation. A correct hostname helps with service certificates, mail identification and administration.

hostnamectl set-hostname server1.example-host.co.uk
hostname -f
cat /etc/os-release
ip -br address

Update the clean operating system

Apply available operating-system updates before installing the panel. Reboot if the kernel or core libraries were updated, then reconnect as root. Do not install a separate web or database stack first; DirectAdmin's installer and CustomBuild manage the supported services.

dnf -y update
reboot

Confirm the VPS has enough capacity

Size the server for the combined website, database and email workload rather than the number of cPanel accounts alone. The destination also needs room for the original cpmove archives, converted DirectAdmin archives, extracted files and database imports. During migration, temporary storage can be considerably higher than steady-state usage.

free -m
lscpu | sed -n '1,15p'
df -h
df -i

Install DirectAdmin on the New VPS

Have an active DirectAdmin licence ready. Log in as root and run the official installation script. The web-based installer prints a temporary browser URL so you can choose the installation options. A command-line installation can also be started by passing a licence key, but the web installer is easier when you need to review the software stack before importing accounts.

sh <(curl -fsSL https://download.directadmin.com/setup.sh)

For a command-line installation using the defaults:

sh <(curl -fsSL https://download.directadmin.com/setup.sh) 'YOUR_DIRECTADMIN_LICENSE_KEY'

The installer displays the administrator credentials and DirectAdmin normally listens on port 2222. Credentials are also stored in /usr/local/directadmin/conf/setup.txt. Protect this file, change exposed passwords and enable stronger administrator authentication before treating the server as production-ready.

Verify the panel and services

da version
da license
systemctl status directadmin --no-pager
ss -lntp | grep ':2222'
df -h

You can request a one-time administrator login URL from the server:

da login-url

Match the destination software before restoring everything

Check the source websites' PHP requirements and install compatible versions and extensions through DirectAdmin's CustomBuild interface. A cPanel account archive does not recreate the server's EasyApache profile. If a site needs ionCube, ImageMagick, a particular PHP extension or a legacy PHP version, the destination must provide it separately.

Do the same for database compatibility. A newer MariaDB or MySQL server usually accepts ordinary WordPress databases, but old applications can rely on removed SQL modes, collations or authentication behaviour. Test the most demanding account first rather than importing a complete production server and discovering a shared compatibility problem afterwards.

Method A: Use DirectAdmin's Remote cPanel Import Tool

When you have root SSH access to the cPanel server, DirectAdmin's remote import tool is normally the cleanest method. It is available at administrator and authorised reseller level. The tool connects to the source over SSH, creates a cPanel backup remotely, downloads it to the DirectAdmin server, converts it and restores the resulting account.

Typical workflow

1. Sign in to DirectAdmin at administrator level.
2. Open the cPanel account import tool under the administrator or reseller tools.
3. Enter the old server hostname or IP, SSH port and root SSH credentials or key details.
4. Load the available cPanel accounts and select a small test account first.
5. Choose the destination owner or reseller carefully.
6. Start the import and monitor the progress and messages.
7. Check the converted account thoroughly before selecting the remaining users.

DirectAdmin's documented remote process packages the cPanel user, downloads the archive into a temporary location, runs the conversion script, restores the account and removes temporary working files. Imported users belong to the administrator or reseller who performs the import unless the original ownership can be preserved and the relevant reseller also exists or is included in the migration run.

Use SSH keys instead of leaving a root password exposed

A temporary root SSH key can reduce the need to enter a reusable password into a migration form. Restrict the source server firewall to the destination IP where practical, monitor the import and remove the key when the migration is complete. Never leave an unrestricted temporary root key installed as a forgotten migration convenience.

Method B: Move One cPanel Account with Commands

The command-line method is useful when you want explicit control, the GUI import is unavailable or you are troubleshooting one account. Replace every placeholder before running a command. The examples assume root access on both servers.

1. Create the cpmove archive on the cPanel server

mkdir -p /home/user_backups
/usr/local/cpanel/scripts/pkgacct USERNAME /home/user_backups

The expected output file is:

/home/user_backups/cpmove-USERNAME.tar.gz

Check that the command completed and that the archive is not suspiciously small:

ls -lh /home/user_backups/cpmove-USERNAME.tar.gz
tar -tzf /home/user_backups/cpmove-USERNAME.tar.gz | head

2. Transfer the archive to the DirectAdmin server

rsync -avt --progress \
  /home/user_backups/cpmove-USERNAME.tar.gz \
  root@NEW_SERVER_IP:/home/admin/

Use the new server's SSH port with -e "ssh -p PORT" if it does not listen on port 22. Compare the file size or a SHA-256 checksum on both servers before starting conversion.

sha256sum /home/user_backups/cpmove-USERNAME.tar.gz
# Run the same command against /home/admin/cpmove-USERNAME.tar.gz on the new server.

3. Convert the cPanel archive on DirectAdmin

mkdir -p /home/admin/converted_user_backup
/usr/local/directadmin/shared/cpanel_to_da/cpanel_to_da.sh \
  /home/admin/cpmove-USERNAME.tar.gz \
  /home/admin/converted_user_backup/
chown -R admin:admin /home/admin/converted_user_backup

Read the conversion output. Warnings about renamed databases or database users are especially important because an application configuration may still contain the old name. Keep the original cpmove archive even after the converted backup appears.

4. Restore the converted account

In DirectAdmin, open Admin Backup/Transfer, choose restore, set the backup path to /home/admin/converted_user_backup, select the generated account backup and start the restore. Return to the backup page to view progress, and check the DirectAdmin message system for warnings or failures.

A restore can also be observed from SSH by running the task processor in debug-output mode:

/usr/local/directadmin/dataskq d80

5. Inspect the restored account before DNS changes

Confirm the account owner, domain list, database list, email accounts and document roots. A successful restore message means the process completed; it does not prove that every application behaves correctly under the new PHP, database and web-server environment.

Method C: Move All cPanel Accounts with Commands

For a complete server migration, create a separate cpmove archive for every cPanel user. Run a pilot account first—ideally one with long database names and a representative WordPress or PHP setup—then proceed with the rest.

Create all account archives on cPanel

mkdir -p /home/all_backups

for userfile in /var/cpanel/users/*; do
  user="${userfile##*/}"
  echo "Creating backup for ${user}"
  /usr/local/cpanel/scripts/pkgacct "${user}" /home/all_backups || {
    echo "Backup failed for ${user}" >&2
    exit 1
  }
done

This stops at the first failed account instead of silently continuing and presenting an incomplete directory as a finished migration set. Review the output and count the archives:

find /home/all_backups -maxdepth 1 -type f -name 'cpmove-*.tar.gz' -printf '%f %s bytes\n' | sort
find /var/cpanel/users -maxdepth 1 -type f | wc -l
find /home/all_backups -maxdepth 1 -type f -name 'cpmove-*.tar.gz' | wc -l

Transfer the migration directory

Create the destination path, then copy the archives. The example deliberately avoids --delete so a typing mistake does not remove unrelated destination files.

# Run on the DirectAdmin server first:
mkdir -p /home/admin/all_backups

# Then run on the cPanel server:
rsync -avt --progress /home/all_backups/ \
  root@NEW_SERVER_IP:/home/admin/all_backups/

Set ownership and import from DirectAdmin

chown -R admin:admin /home/admin/all_backups
find /home/admin/all_backups -maxdepth 1 -type f -name 'cpmove-*.tar.gz' -ls

Open Admin Backup/Transfer, set the restore directory to /home/admin/all_backups and select the cPanel archives. Current DirectAdmin restores can recognise cpmove archives and perform the conversion stage before the account restore. Monitor every account and retain a list of failures requiring another run or manual correction.

Transfer one account at a time when the source is short on space

If the cPanel server cannot store every archive simultaneously, package one account, transfer it, verify it and then remove only the successfully copied source archive. Do not remove the live account or its original data.

mkdir -p /home/all_backups

for userfile in /var/cpanel/users/*; do
  user="${userfile##*/}"
  archive="/home/all_backups/cpmove-${user}.tar.gz"

  /usr/local/cpanel/scripts/pkgacct "${user}" /home/all_backups || exit 1
  rsync -avt --progress "${archive}" \
    root@NEW_SERVER_IP:/home/admin/all_backups/ || exit 1

  rm -f "${archive}"
done

Large Accounts, Databases and Limited Migration Space

Large mailboxes, media libraries and databases turn a straightforward account move into a storage and timing problem. The temptation is to skip parts of the backup, but that can leave a technically restored account with missing customer data.

Measure what makes the account large

du -sh /home/USERNAME
du -sh /home/USERNAME/public_html 2>/dev/null
du -sh /home/USERNAME/mail 2>/dev/null
mysql -e "SELECT table_schema AS database_name,
ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.tables
GROUP BY table_schema
ORDER BY size_mb DESC;"

Exclude obvious disposable caches only when you understand the application and have a separate verified backup. A cpmove migration package is designed for a complete account transfer and does not use cPanel's global backup-exclusion file in the same way as normal scheduled backups.

Plan a two-stage migration for changing sites

A large WooCommerce store can take long enough to package and transfer that orders change before the archive is restored. Use an initial migration to build and test the destination. At cutover, enable maintenance mode or otherwise stop writes, take a fresh database export or fresh cpmove archive, apply the final data, confirm it and then update DNS. The old server remains available, but it should no longer accept independent changes after the final synchronisation begins.

Do not manually rsync cPanel home paths into DirectAdmin paths without a map

The two panels use different directory structures. A blind rsync /home/USERNAME/ can put files in locations DirectAdmin does not serve, overwrite restored mail structures or create ownership problems. Use the converter for account data. Manual file synchronisation should target a known DirectAdmin document root and should be performed only after the user, domain and permissions exist.

DNS and the Final Cutover

DNS determines when visitors start reaching the DirectAdmin server. It should be one of the last changes, not the first. The destination account can be restored and tested while the public domain still points to cPanel.

Decide whether you are changing records or nameservers

If the DNS zone is hosted with a registrar or third-party DNS provider, you may only need to change the website A record to the new server IP. If the domain currently uses cPanel-hosted nameservers and the DirectAdmin server will become authoritative, recreate the complete zone first and then change the nameserver delegation at the registrar.

Preserve records for services that are not moving. These often include:

• Microsoft 365 or Google Workspace MX records
• SPF, DKIM and DMARC records
• Domain-verification TXT records
• Subdomains pointing to external platforms
• CAA records controlling certificate authorities
• Third-party email marketing and transactional mail records

Test the new virtual host before DNS changes

From a terminal, curl --resolve sends the request to the new IP while preserving the real domain in the HTTP host header and TLS request. This is more reliable than browsing directly to the IP, because name-based hosting needs the domain to select the correct website.

curl -I --resolve example.com:80:NEW_SERVER_IP http://example.com/
curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/

For browser testing, add a temporary hosts-file entry:

NEW_SERVER_IP example.com www.example.com

On Windows, the file is normally C:\Windows\System32\drivers\etc\hosts. On Linux and macOS, it is /etc/hosts. Remove the temporary entry immediately after testing so your computer follows public DNS like everyone else.

Switch DNS only after the final data freeze

1. Confirm the destination account passes the testing checklist.
2. Put dynamic websites into maintenance mode or stop content changes.
3. Complete the final database, files and mailbox synchronisation.
4. Verify the final copy on DirectAdmin.
5. Change the A/AAAA records or nameserver delegation.
6. Monitor access logs, application errors and email on both servers.
7. Keep the old server online until the cutover is stable.

dig +short A example.com
dig +short AAAA example.com
dig +short MX example.com
dig +short TXT example.com

Email Migration Needs Its Own Plan

Email is often the part of a hosting migration most likely to appear successful while messages are quietly split between two servers. During DNS propagation, some senders can still use the old MX answer while others use the new one. Leave the old mail service running and check both sides until the old traffic stops.

Confirm where email is actually hosted

If the domain uses Microsoft 365, Google Workspace or another external provider, the website move may not require any MX change. Preserve the current records. If email is local to cPanel and is moving into DirectAdmin, compare every mailbox, alias and forwarder after import.

Test authentication and delivery

• Sign in to webmail on the new server.
• Send from the migrated domain to an unrelated external address.
• Reply from the external address and confirm receipt.
• Test SMTP submission on the ports and encryption settings customers use.
• Check IMAP folders, Sent items and custom folders.
• Confirm forwarders and autoresponders behave as expected.
• Inspect SPF, DKIM and DMARC after DNS changes.
• Watch the mail queue and rejection logs for authentication or routing errors.

Do not assume every password format will behave identically

Many account and mailbox passwords migrate successfully, but customers should be prepared to reset credentials that fail on the new authentication stack. Do not delay testing until after the old service has been cancelled. Also remember that two-factor authentication settings for a control-panel login are platform-specific and should be configured again on DirectAdmin.

Complete Testing Checklist Before You Cancel cPanel

Test from the customer's point of view and from the server administrator's point of view. A homepage loading is only the beginning.

Website and application checks

• Homepage, inner pages, images, CSS and JavaScript load without mixed-content errors.
• WordPress administrator login works.
• Forms submit and their notification emails arrive.
• Search, member login, baskets and checkout work where applicable.
• Uploads can be created and the application can write to required directories.
• Permalinks and .htaccess redirects behave correctly.
• PHP version, memory limit, extensions and upload limits suit the application.
• Scheduled tasks and WordPress cron behaviour are checked.
• API callbacks, payment gateways and allow-listed server IPs are updated.

Database checks

• Every expected database exists.
• The database user exists and has the required privileges.
• Application configuration uses the restored database name and username.
• Table counts and recent content match the source.
• No collation or SQL-mode errors appear in application logs.

Hosting account checks

• Primary and additional domains belong to the correct user.
• Subdomains, aliases and redirects are present.
• FTP accounts and SSH access are recreated or deliberately removed.
• Cron jobs use valid DirectAdmin paths.
• SSL is valid for the root domain and www hostname.
• Disk quota leaves enough room for growth, logs and backups.
• Backups run to a location outside the VPS.

systemctl status directadmin --no-pager
df -h
df -i
free -m
tail -n 100 /var/log/directadmin/error.log
tail -n 100 /var/log/directadmin/errortaskq.log

Common cPanel to DirectAdmin Migration Problems

The DirectAdmin importer cannot see the backup

Check the restore path, filename and ownership. DirectAdmin's cPanel conversion guidance expects a trusted full account archive named cpmove-USERNAME.tar.gz. A cPanel user backup beginning with backup- may need to be renamed by the administrator before conversion. Renaming changes only the filename; it cannot turn a partial archive into a full account backup.

mv backup-DATE_TIME_USERNAME.tar.gz cpmove-USERNAME.tar.gz
chown admin:admin cpmove-USERNAME.tar.gz

A WordPress site shows “Error establishing a database connection”

Open wp-config.php and compare DB_NAME, DB_USER, DB_PASSWORD and DB_HOST with the restored DirectAdmin database. Long cPanel database prefixes can occasionally be normalised or renamed during conversion. The converter output should warn when this happens.

The homepage works but internal pages return 404

For WordPress, save the Permalinks screen once to regenerate rewrite rules, and confirm the website is using an Apache-compatible setup if it relies on .htaccess. When the DirectAdmin server uses Nginx or OpenLiteSpeed differently from the source, custom rewrite rules may need translation or a compatible web-server configuration.

PHP errors appear on the destination

Compare the source PHP version and modules with the destination. Old code can fail on a newer PHP release, while newer frameworks can fail if the destination lacks extensions such as mbstring, intl, zip, gd, imagick or ionCube. Do not solve the problem by enabling every extension globally without understanding its support and security implications.

SSL fails before DNS is switched

Automated certificate validation normally requires the public domain to resolve to the new server or use a supported DNS validation method. You can still test the HTTP site using a hosts-file override. Plan to issue or reissue the production certificate during cutover, then confirm automated renewal after DNS points correctly.

Mail reaches the old server after cutover

This is usually DNS caching or an unchanged MX record. Check the authoritative zone and query multiple public resolvers. Leave the old mailbox service available, collect late messages and avoid deleting the account until the old server stops receiving mail.

Reseller users belong to admin

The reseller was not present when the users were restored, or ownership was not preserved by the import run. Create or import reseller accounts first and map users to them. Verify package limits after reassignment rather than assuming cPanel packages translate exactly into DirectAdmin packages.

A custom cron job no longer works

Inspect absolute paths. A command that references /home/USERNAME/public_html, cPanel's PHP binary, EasyApache paths or a removed script must be changed for the DirectAdmin server. Run the command manually as the account user and capture errors before returning it to cron.

What to Do After the Migration

Secure the DirectAdmin server

Change temporary migration credentials, remove temporary SSH keys, restrict administrator access and enable two-factor authentication. Confirm that the provider firewall and server firewall allow only the services you intend to expose. Review DirectAdmin's Brute Force Monitor, mail limits and update settings.

Update DirectAdmin and the operating system

da update
dnf -y update

Schedule updates rather than running them blindly during peak customer traffic. Maintain a tested backup before significant panel, web-server, PHP or database changes.

Create off-server backups immediately

A migration archive is not a long-term backup system. Configure regular DirectAdmin account backups and copy them to a separate server or storage service. Test an individual account restore before trusting the schedule. The VPS, its snapshots and backups should not all depend on one physical platform or one set of administrator credentials.

Monitor for at least several days

Watch website errors, mail queues, disk growth, CPU usage and failed login activity. Compare customer reports with server logs. Some problems only appear when a weekly cron runs, a mailbox receives a large attachment or a payment gateway sends its next callback.

Keep the old cPanel service until rollback is no longer needed

Do not cancel the old hosting immediately after the DNS change. Keep it isolated from new content changes, but available long enough to recover overlooked data and collect late email. Once you are satisfied, download final archives, remove sensitive data according to your retention policy and cancel the old service deliberately.

cPanel to DirectAdmin Command Reference

These commands bring the main root-level workflow together. Replace all placeholders and run each command on the named server. Read the detailed sections above before using them on production.

On the cPanel source: package one account

mkdir -p /home/user_backups
/usr/local/cpanel/scripts/pkgacct USERNAME /home/user_backups
ls -lh /home/user_backups/cpmove-USERNAME.tar.gz

On the cPanel source: transfer one account

rsync -avt --progress \
  /home/user_backups/cpmove-USERNAME.tar.gz \
  root@NEW_SERVER_IP:/home/admin/

On the DirectAdmin destination: convert one account

mkdir -p /home/admin/converted_user_backup
/usr/local/directadmin/shared/cpanel_to_da/cpanel_to_da.sh \
  /home/admin/cpmove-USERNAME.tar.gz \
  /home/admin/converted_user_backup/
chown -R admin:admin /home/admin/converted_user_backup

On the cPanel source: package every account

mkdir -p /home/all_backups
for userfile in /var/cpanel/users/*; do
  user="${userfile##*/}"
  /usr/local/cpanel/scripts/pkgacct "${user}" /home/all_backups || exit 1
done

Transfer all archives and set ownership

# Run on cPanel:
rsync -avt --progress /home/all_backups/ \
  root@NEW_SERVER_IP:/home/admin/all_backups/

# Run on DirectAdmin:
chown -R admin:admin /home/admin/all_backups

Test a domain against the new IP

curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/

Check DNS after cutover

dig +short A example.com
dig +short MX example.com
dig +short TXT example.com

Use the commands as a framework, not as an unattended one-click migration. Account ownership, filenames, SSH ports, firewall rules, reseller relationships and software requirements vary between servers.