Move DirectAdmin accounts to a fresh server

This DirectAdmin migration checklist walks you through a fresh-server move in the right order: prepare the new dedicated server, create access, transfer accounts, verify services, then switch DNS after everything checks out. It is written for hosting teams, agencies, and server owners who need a controlled migration instead of a rushed cutover. If you are still choosing hardware, review How to Choose a Dedicated Server in 2026 and How to Compare Dedicated Server Options in 2026. For the standard DirectAdmin setup path on a new machine, see DirectAdmin Account Setup on a Fresh VPS. This guide stays focused on migration, verification, and rollback.

Focus keyword: DirectAdmin migration checklist

Before you move anything

Prerequisites

• A fresh dedicated server from HostNextra dedicated infrastructure with enough disk space for source accounts, backups, and temporary transfer files.
• Supported operating system: use the DirectAdmin-supported release you actually plan to run. If your provider image is not one of the supported systems you intend to use, stop and confirm compatibility before continuing.
• Root SSH access to both servers.
• A second local terminal for testing and a DNS dashboard where you can edit A, AAAA, MX, and TXT records.
• Example placeholders used below: NEW_SERVER_IP=203.0.113.10, SOURCE_SERVER_IP=198.51.100.20, ADMIN_USER=adminops, DOMAIN_NAME=example.com, DIRECTADMIN_PORT=2222.

What you will do

• Log in to the new server and confirm the operating system.
• Create a non-root sudo or wheel user and test SSH keys.
• Update packages, set time sync, and prepare firewall access for SSH, HTTP, HTTPS, and DirectAdmin.
• Check DirectAdmin service health and file ownership after the migration.
• Validate the site, mail, and control panel before changing nameservers or records.

Local computer: start the SSH session

ssh -p 2222 [email protected]

Replace 203.0.113.10 with your new server IP and 2222 only if your SSH service uses a custom port. Keep this root session open until the non-root login test succeeds.

VPS as root: identify the operating system

cat /etc/os-release

Look for the distribution name and version. This tells you which package manager, firewall tool, and privilege group to use in the next steps.

Build the new server access path

VPS as root on Ubuntu/Debian

apt update
apt -y upgrade
apt -y install sudo openssh-server ufw chrony rsync curl tar unzip

This refreshes packages and installs the SSH daemon, firewall tools, time sync, and transfer utilities. Confirm success by checking that no package errors were reported.

adduser adminops
usermod -aG sudo adminops
install -d -m 700 /home/adminops/.ssh
cp /root/.ssh/authorized_keys /home/adminops/.ssh/authorized_keys
chown -R adminops:adminops /home/adminops/.ssh
chmod 600 /home/adminops/.ssh/authorized_keys

Replace adminops with your preferred administrative account. If you do not already have a public key on root, copy your local public key into /home/adminops/.ssh/authorized_keys instead of reusing root keys. Ownership and permissions must stay strict, or SSH will ignore the file.

systemctl enable --now chrony
systemctl enable --now ssh
ufw allow OpenSSH
ufw allow 2222/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 2221/tcp
ufw enable
ufw status verbose

Open SSH, web, and DirectAdmin ports before you change any login settings. If your DirectAdmin service uses a different port, replace 2221 with that value. The status output should list the allowed ports.

VPS as root on AlmaLinux/Rocky Linux

dnf -y update
dnf -y install sudo openssh-server firewalld chrony rsync curl tar unzip
systemctl enable --now chronyd
systemctl enable --now sshd
systemctl enable --now firewalld

This updates the system and installs the standard tools used on RHEL-compatible systems. The SSH service is sshd here, not ssh.

useradd -m adminops
passwd adminops
usermod -aG wheel adminops
install -d -m 700 /home/adminops/.ssh
cp /root/.ssh/authorized_keys /home/adminops/.ssh/authorized_keys
chown -R adminops:adminops /home/adminops/.ssh
chmod 600 /home/adminops/.ssh/authorized_keys

Use wheel for sudo access on AlmaLinux and Rocky Linux. If you prefer key-based login only, keep the password step only long enough to test access, then disable password authentication later.

firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --permanent --add-port=443/tcp
firewall-cmd --permanent --add-port=2221/tcp
firewall-cmd --reload
firewall-cmd --list-all

The reload applies the rules. Confirm that SSH, web, and DirectAdmin ports are listed before you continue.

Local computer: open a second terminal and test the new account

ssh -p 2222 [email protected]

Log in with your key. If the login fails, stop and fix ownership, permissions, or key contents before locking anything down.

VPS as the named sudo user: test privilege escalation

sudo -v
sudo whoami

The first command checks that sudo works without error. The second should print root. Only after this passes should you consider disabling root SSH login or password authentication.

Prepare DirectAdmin and move the data

DirectAdmin migrations are safest when you transfer one account at a time, then verify each service. Use the panel's migration or backup tools if they are already part of your workflow, and keep a rollback copy on the source server until the new host is confirmed stable.

VPS as root: confirm DirectAdmin services

systemctl status directadmin --no-pager
ss -tulpn | grep -E ':(2221|80|443)\b'

You are checking that DirectAdmin is running and listening on the expected ports. If the service name differs on your installation, replace it with the actual unit name shown by systemd.

VPS as root: create a transfer workspace

mkdir -p /root/migration/{backups,logs,checks}
chmod 700 /root/migration

This keeps migration archives and logs in one restricted directory. Do not store passwords or keys in world-readable paths.

VPS as root on the source server: create a backup archive

/usr/local/directadmin/scripts/backup create_user_backups adminops

Replace adminops with the account you are moving. If your environment uses a different DirectAdmin backup script or panel workflow, generate the account backup through that supported path and save the archive before copying it.

VPS as root on the source server: transfer the archive

rsync -avz /home/admin/admin_backups/ [email protected]:/root/migration/backups/

Adjust the source path to match where your backup files are written. This copies the archive to the new server without altering the source copy.

VPS as root on the new server: restore the account

/usr/local/directadmin/scripts/restore_user.sh /root/migration/backups/adminops.tar.gz

Use the exact backup filename you transferred. Watch the output for file ownership, mail, and database restore messages. If the script reports a missing archive or permission issue, stop and correct the path or file mode before retrying.

VPS as root: fix ownership if needed

/usr/local/directadmin/scripts/set_permissions.sh all

This repairs common ownership and mode problems after a restore. It is safe to run when you suspect files are owned by the wrong account.

VPS as root: review logs for restore errors

tail -n 50 /var/log/directadmin/error.log
tail -n 50 /var/log/directadmin/system.log

Look for database import failures, missing paths, or permission denials. Fix those before changing DNS.

Validate the site, mail, and rollback path

VPS as root: check web services and PHP processing

systemctl status nginx --no-pager
systemctl status httpd --no-pager
systemctl status lsws --no-pager

Only one of these may be installed in your stack. Run the command that matches your setup and confirm the web server is active. If you use PHP-FPM, also check the unit name for your PHP version.

VPS as root: confirm the site answers locally

curl -I http://127.0.0.1
curl -I http://203.0.113.10

You should receive a valid HTTP response. If you get a connection error, inspect the listening sockets and the web server logs before touching DNS.

VPS as root: test mail-related records and services

ss -tulpn | grep -E ':(25|465|587|110|143|993|995)\b'
grep -R "^hostname=\|^domain=\|^relayhost=" /etc/exim* /etc/postfix* 2>/dev/null

These checks help you confirm that mail services and basic routing settings are present. If your account sends mail, verify SPF, DKIM, and DMARC records in DNS before you cut over.

Local computer: test the public site before DNS changes

curl -I http://203.0.113.10

Use the new server IP directly. A good response here means the server is ready for a DNS switch.

Rollback procedure

1. Keep the source server backup untouched.
2. Lower DNS TTL before cutover if you have not already done so.
3. If the new server fails, restore the old nameservers or A records back to the source IP.
4. Investigate the new server logs, fix the issue, and repeat the restore on a fresh backup copy.

Post-cutover checks

systemctl is-enabled directadmin
systemctl status directadmin --no-pager
journalctl -u directadmin -n 50 --no-pager

These commands confirm the control panel starts on boot and that recent log entries are clean. Keep the old server powered on until DNS propagation settles and the new host is stable.

Helpful related reading

• Backup Verification on Ubuntu 26.04 and AlmaLinux 10
• Backup Testing Policy for Hosting Teams and VPS Owners
• cPanel vs Plesk vs DirectAdmin: How to Choose

Troubleshooting

SSH login fails for the new user

Run:

ls -ld /home/adminops /home/adminops/.ssh /home/adminops/.ssh/authorized_keys
stat -c '%a %U %G %n' /home/adminops /home/adminops/.ssh /home/adminops/.ssh/authorized_keys

Look for incorrect ownership or permissions. Fix them with chown -R adminops:adminops /home/adminops/.ssh and chmod 700 /home/adminops/.ssh, chmod 600 /home/adminops/.ssh/authorized_keys.

DirectAdmin does not start

Run:

systemctl status directadmin --no-pager
journalctl -u directadmin -n 100 --no-pager

Look for port conflicts, missing licenses, or file permission errors. Correct the underlying issue, then run systemctl restart directadmin.

Web traffic reaches the old site

Run:

dig +short example.com
curl -I http://example.com

If DNS still points to the old IP, update the records at your DNS provider and wait for propagation. If DNS is correct but the site is stale, clear cache layers such as a reverse proxy, browser cache, or application cache.

Frequently asked questions

Can I move email and websites in one pass?
Yes. The safer method is still to restore one account, test web and mail, then move the next account. That makes it easier to isolate failures.

Should I switch nameservers or only A records?
Use the method that matches your DNS setup. If the source and destination use the same nameservers, updating A, AAAA, MX, and TXT records is usually enough.

Do I need to disable the old server immediately?
No. Keep it available until you have verified the new host, mail flow, and any cron or backup jobs that must continue on the destination.

What is the final success signal?
Your control panel opens, the website loads from the new IP, mail queues are healthy, and the server survives a reboot with DirectAdmin still enabled.