DirectAdmin Account Migration Checklist for Fresh VPS Launches

Use this checklist before you move a live account

DirectAdmin account migration goes better when you treat it like a release, not a file copy. You want files, databases, mail, and DNS moved in a controlled order so the site stays live while you verify the new VPS.

If you are choosing the destination first, a Hostperl VPS gives you room to stage the new panel, test the cutover, and keep the old server online until everything checks out. For teams moving client sites, that overlap usually matters more than raw specs.

This guide assumes you already have a working DirectAdmin server or are about to build one. It covers the migration steps support teams use when they want low risk, clean DNS, and a quick rollback path.

ssh root@203.0.113.10

Run that on your local computer. 203.0.113.10 is a reserved documentation example; replace it with the real public IP of your VPS. If your provider uses a non-root login, you can use ssh deploy@203.0.113.10 after the account exists.

Confirm the operating system and update the server

On the VPS as root, confirm the distribution before you install anything else. DirectAdmin uses different package paths on Debian and Rocky/AlmaLinux families, so do not guess.

cat /etc/os-release

You should see the OS name and version. Leave that terminal open. Next, update the base system so the migration starts on a patched server.

Ubuntu and Debian

apt update
apt -y upgrade
apt -y install curl wget rsync unzip ca-certificates sudo chrony

This refreshes package lists, installs pending updates, and adds the tools most migrations need. Afterward, check time sync so logs and SSL issuance line up correctly.

systemctl enable --now chrony
chronyc tracking

Successful output should show a running daemon and a normal time source.

AlmaLinux and Rocky Linux

dnf -y update
dnf -y install curl wget rsync unzip ca-certificates sudo chrony

Then enable time sync with the matching service name.

systemctl enable --now chronyd
chronyc tracking

On RHEL-compatible systems, the service is chronyd, not chrony.

Create a non-root admin before the migration

Do not do the rest of the work as root if you can avoid it. Create the admin account now, verify it, and keep the original root SSH session open until the new login works. If you want a reference walk-through, Hostperl also has a related guide on creating a non-root sudo user on Linux VPS.

Ubuntu and Debian

adduser deploy
usermod -aG sudo deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh

Create the user, add it to the sudo group, and prepare SSH access. Now copy your public key from your local computer.

ssh-copy-id deploy@203.0.113.10

Replace 203.0.113.10 with the VPS IP. Then fix ownership and permissions on the server.

chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Open a second terminal on your local computer and test the new login.

ssh deploy@203.0.113.10
sudo -v

If sudo -v prompts for your password and returns without error, the account is ready.

AlmaLinux and Rocky Linux

useradd -m -s /bin/bash deploy
passwd deploy
usermod -aG wheel deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh

RHEL-compatible systems use the wheel group for sudo access. If you prefer key-only access, set the password once, then lock it later after confirming SSH works.

ssh-copy-id deploy@203.0.113.10
chown -R deploy:deploy /home/deploy/.ssh
chmod 600 /home/deploy/.ssh/authorized_keys

Now test the account from a second terminal and confirm sudo.

ssh deploy@203.0.113.10
sudo -v

Prepare DirectAdmin for the migration window

Before you move data, make sure the panel itself is reachable and that the firewall allows the ports you need. If you are still comparing panel choices for client work, this Hostperl article on choosing cPanel, Plesk, or DirectAdmin in 2026 helps explain where DirectAdmin fits for agencies and smaller support teams.

Typical DirectAdmin access uses port 2222, plus web and mail ports if the server will host email. Adjust for your environment, but do not close the SSH session you are using now.

Ubuntu and Debian with UFW

ufw allow OpenSSH
ufw allow 2222/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 25/tcp
ufw allow 587/tcp
ufw allow 993/tcp
ufw enable
ufw status verbose

This opens management, HTTP, HTTPS, and common mail ports. If you are not hosting mail on the new server, leave the mail rules out.

AlmaLinux and Rocky Linux with firewalld

systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --permanent --add-service=smtp
firewall-cmd --permanent --add-port=587/tcp
firewall-cmd --permanent --add-port=993/tcp
firewall-cmd --reload
firewall-cmd --list-all

On RHEL-compatible systems, use firewalld rather than UFW. If SELinux is enforcing, keep it that way unless the installer or your panel documentation asks for a change. Do not disable it just to save time.

Copy the account data in a controlled pass

For live migrations, a full panel backup is usually safer than piecemeal copying. That gives you one artifact to verify, one restore path, and one record if the customer later asks what changed. If you need a zero-downtime process for the move itself, Hostperl’s panel migration guide without downtime shows the timing strategy that pairs well with this checklist.

From the source server, generate the DirectAdmin backup using the panel or its backup tools, then copy it to the new server. If you are migrating a large account, use rsync for the final delta after the first copy completes.

rsync -avh --progress /home/admin/admin_backup/ deploy@203.0.113.10:/home/deploy/

Replace the source path with the real backup location on the old server. Successful output should show transferred files and a clean exit.

On the destination server, confirm the archive exists before you import anything.

ls -lh /home/deploy/

You should see the backup file with a sensible size. If the file is missing or tiny, stop and recopy it.

Restore the account and check the core services

Import the account through DirectAdmin’s backup restore path, then check the pieces that usually break first: file ownership, PHP handler, database credentials, and the site document root. DirectAdmin accounts often fail because the files arrived correctly, but the web config did not.

After the restore, verify that the web server and database services are running. The exact service names depend on the stack you selected during installation.

Ubuntu and Debian

systemctl status nginx apache2 php*-fpm mariadb --no-pager

Use the service names that actually exist on your server. A green active (running) line is the sign you want.

AlmaLinux and Rocky Linux

systemctl status nginx httpd php-fpm mariadb --no-pager

On these systems, Apache is usually httpd. If you use OpenLiteSpeed, check that service name instead.

For databases, use the same careful approach. If the account uses MySQL or MariaDB, confirm the server responds and that the imported database exists.

mysql -u root -p -e "SHOW DATABASES;"

You should see the restored database name in the output. If the panel uses PostgreSQL for a specific app, run the matching service check and database list for that engine.

Move DNS, SSL, and mail in the right order

DNS should change only after the restored account responds correctly on the new VPS. Lower the TTL on the old records first if you still have time, then switch the A record and, if needed, the AAAA record. For domain operations and IP planning, Hostperl’s IP address rental page is useful when a migration needs a clean dedicated IP for mail or client separation.

Once the site resolves to the new server, issue or renew the certificate. For DirectAdmin setups using Let’s Encrypt, verify the certificate chain from the browser and from the shell.

curl -I https://example.com

Replace example.com with the migrated domain. A successful response should show HTTP/2 200, 301, or another valid site response, not a certificate error.

If the account includes email, update SPF, DKIM, and DMARC after the move. That avoids the common support ticket where web traffic is fine but mail starts landing in spam. Hostperl’s email deliverability guide explains the record set in practical terms.

Lock down the new VPS after cutover

Do not disable root login until the deploy account works from a second terminal and the panel is stable. After that, reduce risk by tightening SSH and adding intrusion protection. Hostperl’s SSH, UFW, and Fail2Ban tutorial is a good companion if you want a fuller hardening pass.

On Ubuntu and Debian, you can check logs with journalctl -u fail2ban once Fail2Ban is installed. On AlmaLinux and Rocky Linux, the same command works if you use the distro package. If you later narrow SSH access, add the new firewall rule first, test it, and only then remove the old one.

Also run a malware and file-integrity scan if the source server had a history you do not fully trust. That is standard support practice for customer sites, especially when the original environment was unmanaged.

Final verification from the server and your browser

Finish with checks that prove the move survived the most common failure points: service startup, port listening, DNS, and page load.

ss -tulpn | grep -E ':(80|443|2222)\b'
journalctl -u directadmin -n 50 --no-pager
systemctl is-enabled directadmin

You want to see DirectAdmin listening on its expected port, recent logs without errors, and the service enabled at boot.

From your local computer, confirm the site resolves and the HTTPS certificate responds normally.

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

The DNS result should point to the new VPS, and the HTTPS request should return a valid web response. If the site is WordPress, log in once and save permalinks to flush the rewrite rules.

Troubleshooting the most common migration failures

• Panel login fails after restore: Run systemctl status directadmin --no-pager and check /var/log/directadmin/error.log. If the service is down, start it with systemctl restart directadmin.
• Site shows the old server: Run dig +short example.com. If it still points to the old IP, update the DNS record and wait for TTL to expire.
• SSL warning after DNS cutover: Run curl -Iv https://example.com. If the certificate is wrong, reissue it inside DirectAdmin and confirm port 443 is open.
• Email lands in spam: Check SPF, DKIM, and DMARC records, then review the SMTP banner and mail logs before sending a new test message.

FAQ

Can I migrate a DirectAdmin account without changing the domain?

Yes. Keep the domain active, restore the account on the new VPS, test it on the temporary hostname or hosts-file override, and switch DNS only after you confirm the site works.

Should I move mail at the same time as the website?

Only if you have time to verify SPF, DKIM, DMARC, and mailbox access. Otherwise, move the website first and schedule mail after the DNS cutover is stable.

What is the safest rollback plan?

Keep the source account intact, keep DNS TTL low, and do not decommission the old server until the new VPS passes browser, database, and mail tests.

Do I need a dedicated IP for DirectAdmin?

Not always, but it can help with mail separation, SSL clarity, and customer isolation. That is one reason many hosting teams prefer a fresh VPS with clean network settings.