Short answer: Build the new DirectAdmin server first, lower DNS TTLs a day ahead, then create admin-level backups of every user with da admin-backup (or Admin Tools > Admin Backup/Transfer), copy /home/admin/admin_backups/ to the new server with rsync, and restore them with the IP set to the new server’s address. Finish with a final rsync of mail and site files, switch DNS or nameservers, and let Let’s Encrypt re-issue certificates on the new box.
Applies to DirectAdmin 1.712 on AlmaLinux 9.8 (tested)
We ran the backup and CLI commands on our lab server (AlmaLinux 9.8, DirectAdmin 1.712) on 6 October 2026. The restore, rsync and DNS cut-over steps are checked against the official DirectAdmin documentation (linked below); we did not restore onto a second lab server.
Table of Contents
Plan the move before you touch a backup
A DirectAdmin to DirectAdmin move is the easiest panel migration there is, because both ends speak the same backup format. Most problems come from what sits around the accounts: IP addresses, nameservers, custom templates and mail that arrives while you copy. Check these first.
- Licence: the new server needs its own DirectAdmin licence. DirectAdmin says you can ask for a temporary migration licence through a ticket (legacy licences excepted).
- Same software choices: install the same web server, PHP versions and MariaDB major version as the old box. Copy
/usr/local/directadmin/custombuild/options.confas a reference, and if you use acustombuild/custom/folder, sync it before the first build. - Templates: copy
/usr/local/directadmin/data/templates/custom/so custom vhost, DNS and email templates survive. - DNS: note whether domains use your own nameservers (ns1/ns2 on this server), a DNS cluster, or an outside DNS host. That decides how you cut over.
- Usernames: if you raised
max_usernameindirectadmin.confon the old server, raise it on the new one too, or long usernames fail to restore. - Free space: the backups land in
/home/admin/admin_backups/on both servers, so you need room for the archives as well as the restored data.
Lower the TTL of every zone at least a day before the move. DirectAdmin’s own migration notes suggest doing it at least four hours before you create the backups; longer is safer because resolvers cache the old TTL until it expires.
Create admin-level backups with da admin-backup
In DirectAdmin 1.712 the backup is a subcommand of the da binary. It takes only two options, as da admin-backup --help shows on our lab server:
da admin-backup --help
# --destination= Backup destination
# --user= User to backup (multiple)Back up every user into the default admin backup folder, or name users one by one for a staged move:
# all users you list, into the standard folder
da admin-backup --destination=/home/admin/admin_backups --user=bob --user=alice
# list users first if you have many
ls /usr/local/directadmin/data/users/On our lab server a backup of one user with three WordPress sites took about four seconds. The command queues a normal DirectAdmin backup task and prints it, which is useful when you want to repeat it from task.queue later:
2026/10/06 01:00:50 info executing task task=action=backup&append_to_path=nothing&database_data_aware=yes&email_data_aware=yes&local_path=%2Froot%2Fsrvs-lab%2Ftest-hostB%2Fda-backup&owner=admin&select0=admin&type=admin&value=multiple&when=now&where=local
2026/10/06 01:00:54 info finished task duration=3.939410198s ...With zstd=1 in the DirectAdmin config (the default on our 1.712 lab) the archives end in .tar.zst. Normal users are written as user.<owner>.<username>.tar.zst; the admin account itself came out as admin.root.admin.tar.zst. Inside the archive you find a backup/ folder with user.conf, one folder per domain (DNS zone, email accounts, certificates, domain.ip_list), the database dumps (*.sql) and home.tar.zst with the files.
Back up resellers before their users, and restore them first. A user restored before its reseller ends up owned by the wrong account. You can fix ownership later with /usr/local/directadmin/scripts/move_user_to_reseller.sh 'user' 'old reseller' 'new reseller', but it is easier to get the order right.
The GUI route does the same thing: Admin Tools > Admin Backup/Transfer, select users, choose All Data, and save locally. For very large accounts use the split approach below instead.
Copy the backups to the new server
DirectAdmin’s built-in remote destination is FTP (and FTPS). For a one-off server move, rsync over SSH is simpler and resumable. Run it from the old server:
rsync -av --progress /home/admin/admin_backups/ root@203.0.113.10:/home/admin/admin_backups/
ssh root@203.0.113.10 'chown -R admin:admin /home/admin/admin_backups' Large accounts: skip the files, sync them separately
If some users have tens of gigabytes in domains/ or mail, untick Domains Directory and E-mail Data in the backup, restore the small archive, then pull the data straight across. DirectAdmin documents this pattern; run it on the new server:
rsync -ave 'ssh -p 22' 192.0.2.20:/home/bob/domains/ /home/bob/domains/
rsync -ave 'ssh -p 22' 192.0.2.20:/home/bob/imap/ /home/bob/imap/Here 192.0.2.20 is the old server. Repeat these rsyncs right before the DNS switch so only the last changes travel.
Restore and map IP addresses
Restore through Admin Tools > Admin Backup/Transfer > Restore on the new server. The important choice is the IP: use the IP from the backup only works if the new server owns the same address. On a new host you almost always want select IP and pick the new shared IP. The same restore can be queued from the shell; this is the documented task.queue format with ip_choice=select:
echo "action=restore&ip_choice=select&ip=203.0.113.10&local_path=%2Fhome%2Fadmin%2Fadmin_backups&owner=admin&select0=user%2Eadmin%2Ebob%2Etar%2Ezst&type=admin&value=multiple&when=now&where=local" >> /usr/local/directadmin/data/task.queue
# run the queue now instead of waiting for the cron
da taskqUse ip_choice=file only when the restored IP really exists on the new server. Add select1=, select2= and so on for more archives in one task. Check the result under the Message System; failed restores are reported there.
Swapping IPs after a restore
If accounts were restored with the old IP by mistake, DirectAdmin ships a script that rewrites IPs in its data files. Its usage line on our lab server is:
/usr/local/directadmin/scripts/ipswap.sh <oldip> <newip> [<file>]
# changes are logged to /var/log/directadmin/ipswap.logTake a copy of /usr/local/directadmin/data/ before you run it, then rewrite the web server configs with da build rewrite_confs.
Mail and databases that change during the move
Between the backup and the DNS switch, new mail keeps arriving on the old server and sites keep writing to their databases. Pick one of these approaches:
- Short freeze: block inbound port 25 on the old server during the final copy so mail queues at the sender, which retries for days. DirectAdmin’s documentation suggests exactly this.
- Final rsync: repeat the
imap/anddomains/rsyncs right before you switch DNS. - Final database copy: for busy shops or forums, put the site in maintenance mode, dump the database on the old server and import it on the new one, then switch.
# old server: dump one database
mariadb-dump --single-transaction --quick bob_wp > /root/bob_wp.sql
rsync -av /root/bob_wp.sql root@203.0.113.10:/root/
# new server: import over the restored copy
mariadb bob_wp < /root/bob_wp.sqlCut over DNS and re-issue SSL
How you switch depends on who answers DNS for the domains:
| DNS setup | Cut-over step |
|---|---|
| Your own nameservers on the old server | Point the ns1/ns2 glue records (at the registrar) to the new IPs, or keep the old box answering with the new A records until the glue change spreads. |
| DirectAdmin DNS cluster | Add the new server to the cluster, check zones replicate, then remove the old one. Disable the cluster “Domain Check” during restore, as DirectAdmin advises. |
| External DNS (Cloudflare, registrar) | Change the A/AAAA records (and MX targets if they point at the server) to the new IP. |
Let’s Encrypt certificates restored from the backup keep working until they expire, but renewals need HTTP validation to reach the new server. After DNS points to the new box, request or renew per domain in SSL Certificates, or let the renewal cron do it. The server hostname certificate is separate; after it is issued, push it to Exim, Dovecot and the panel with da build sync_server_cert.
Check that it worked
- Compare user lists:
ls /usr/local/directadmin/data/users/ | wc -lon both servers. - Browse each site with a hosts-file entry before the DNS switch, and check the PHP version per domain.
- Log in to webmail as a test mailbox and send mail in both directions after the switch.
- Check that DNS answers from the new server:
dig +short example.com @203.0.113.10. - Watch
/var/log/exim/mainlogon the old server for a few days; anything still arriving there points to a stale DNS cache or a hard-coded IP. - Keep the old server running, untouched, for at least a week.
Common problems
- Restore says the user already exists: a test restore left the account behind. Remove it on the new server (after checking you are on the right box) and restore again.
- Sites show the default page: the account was restored with an IP the server does not have. Fix it with
ipswap.shor Modify User, thenda build rewrite_confs. - Wrong owner: users were restored before their reseller. Use
move_user_to_reseller.sh. - Roundcube contacts missing: check
skip_roundcube_in_backupsinda config; it must be 0 on the old server. - .tar.zst will not restore: the new server needs zstd support (zstd=1); our 1.712 lab had it on by default.
Official documentation: DirectAdmin: Full DirectAdmin migration · DirectAdmin: Migrating accounts · DirectAdmin: Backup / Restore / Migration · DirectAdmin: DA scripts explained
Related: DirectAdmin da CLI: update, build, config-set and More · DirectAdmin Backups S3: Reliable Admin, Reseller and User Backups · DirectAdmin DNS Clustering: Reliable Multi-Server Setup · Install DirectAdmin on AlmaLinux 9/10 and Debian 13: 2026 Guide · DNS Propagation Checker
See also: Migrate Plesk to cPanel (and cPanel to Plesk): Tools and Limits · Plesk AlmaLinux 10: Supported Version and What Is Missing · DirectAdmin CustomBuild Failed: Logs, Lock File, Re-run and Rollback · Restore a File, Database or Account from a DirectAdmin Backup (CLI, Tested) · Force HTTPS for a Domain in DirectAdmin (Tested on 1.712)
Frequently asked questions
Can DirectAdmin transfer accounts directly to another DirectAdmin server?
There is no live server-to-server transfer like cPanel’s Transfer Tool. You create backups, move them (FTP or rsync) and restore them on the new server.
Do I need a second DirectAdmin licence for the migration?
Yes, the new server needs its own licence. DirectAdmin offers temporary migration licences on request through a support ticket.
How do I keep the old IP addresses?
Only if the new server owns those IPs, for example when the provider moves the subnet. Otherwise restore with a selected IP and update DNS.
Will email be lost during the move?
Not if you either block port 25 on the old server during the final copy, or run a final rsync of the imap folders right before switching DNS.
Do SSL certificates move with the backup?
Yes, certificates and keys are in the backup, but renewals need DNS to point at the new server. Request or renew them after the switch.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- DirectAdmin 1.712 on AlmaLinux 9.8 (tested)
- Last full review
- Next review