DirectAdmin Migration Checklist for Clean VPS Cutovers

Start with the cutover plan, not the copy job

A clean DirectAdmin migration checklist keeps the move controlled: inventory the old server, copy accounts, verify mail and SSL, then switch DNS only after the new VPS passes checks. For site owners, agencies, and resellers, the difference between a calm migration and a pile of support tickets usually comes down to sequence. If you are moving to a new Hostperl VPS, keep the old server live until the new one has passed account, web, and mail tests. See Hostperl VPS hosting for a practical fit for panel workloads and staged migrations.

This guide assumes you are moving DirectAdmin content to a fresh VPS and want a repeatable process, not a one-off rescue. It is written for Ubuntu, Debian, AlmaLinux, and Rocky Linux servers, because those are the systems most teams inherit during panel moves in 2026.

Connect, identify the OS, and create a safer admin path

On your local computer, open your first SSH session:

ssh root@203.0.113.10

Here, 203.0.113.10 is a documentation example. Replace it with the real public IP assigned to your VPS. Keep this root session open until the new admin login works.

If your provider gave you a default non-root account, use that same IP instead:

ssh deploy@203.0.113.10

On the VPS as root, check the operating system before you install anything:

cat /etc/os-release

You should see whether the server is Ubuntu or Debian on one side, or AlmaLinux or Rocky Linux on the other. That decides whether you use apt or dnf, ufw or firewalld, and which service names you verify later.

Before a panel migration, create a sudo-capable administrator so routine work does not happen as root. If you already have one, skip to the SSH key test.

Ubuntu and Debian

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

Add your public key safely, then lock down permissions:

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

AlmaLinux and Rocky Linux

useradd -m -G wheel deploy
passwd deploy
mkdir -p /home/deploy/.ssh
chmod 700 /home/deploy/.ssh

Paste your SSH key into /home/deploy/.ssh/authorized_keys, then secure it:

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

On your local computer, open a second terminal and test the new login:

ssh deploy@203.0.113.10

Then confirm sudo works:

sudo -v
whoami

You should see deploy for whoami and no password error from sudo -v. Only after that should you consider tightening root login rules.

Build the migration inventory before you move data

A DirectAdmin move goes faster when you know exactly what exists on the old server. Capture the account list, website roots, mail domains, and any reseller structure before copying anything. If you keep a customer support note with these details, you also have a clean rollback record if a DNS change needs to be delayed.

On the source server, export the account and service inventory. The exact files vary by installation, but these commands help you locate the relevant data quickly:

cd /usr/local/directadmin
find data/users -maxdepth 2 -type f | head
find /home -maxdepth 2 -type d | head

Look for user data, domain configs, and home directories. For a reseller migration, note which accounts belong under which reseller so you do not flatten permissions during the copy.

If the move includes WordPress sites, staging clones, or a WooCommerce shop, review the destination path and cache layers before cutover. Hostperl’s guides on WordPress installation on a Hostperl VPS and staging to production migration are useful companions when panel moves include CMS work.

Copy accounts, then verify ownership and permissions

At this stage, the goal is not only to transfer files. You also need correct ownership, group membership, and panel-readable paths so DirectAdmin can manage the accounts after import. For a fresh VPS, make sure the destination has enough disk space before the copy starts.

On the source VPS as root, create a compressed backup of an account if you are moving one site at a time:

cd /home
 tar -czf /root/example-complete-account-backup.tar.gz exampleuser

Replace exampleuser with the actual DirectAdmin username. On a multi-account migration, repeat that for each active customer account. If the server is under load, do this during a quiet window so mail and uploads are not changing mid-archive.

On the destination VPS as root, restore the archive into the correct home directory:

cd /
tar -xzf /root/example-complete-account-backup.tar.gz

Then fix ownership:

chown -R exampleuser:exampleuser /home/exampleuser

On AlmaLinux and Rocky Linux, if SELinux is enforcing and the site does not load correctly after restore, check file contexts before you keep guessing:

restorecon -Rv /home/exampleuser

That often clears access issues after a direct file copy.

Install and test the panel services on the new VPS

For the panel itself, keep the installation and service checks aligned with the destination OS. If you are preparing a DirectAdmin migration into a fresh environment, do not mix package commands.

Ubuntu and Debian

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

AlmaLinux and Rocky Linux

dnf -y update
dnf -y install curl wget ca-certificates tar rsync unzip

After the panel files are in place, confirm the expected services are present. The names can vary a little by setup, but these are common checks:

systemctl status directadmin
systemctl status httpd
systemctl status nginx
systemctl status dovecot
systemctl status exim

If one of those services is inactive, check the logs before restarting it. This is faster than bouncing everything blindly during a migration window.

journalctl -u directadmin -n 50 --no-pager
journalctl -u httpd -n 50 --no-pager

For a Hostperl customer, this is usually the point where support asks for the exact service status output and recent log lines. That shortens the back-and-forth.

Open the firewall before you close the old path

Never remove the old access method until the new one has been tested. That means opening DirectAdmin, SSH, web, and mail ports on the new VPS first.

Ubuntu and Debian with UFW

ufw allow OpenSSH
ufw allow 80/tcp
ufw allow 443/tcp
ufw allow 2222/tcp
ufw enable
ufw status verbose

Use 2222 only if your panel or SSH setup actually uses it. Otherwise keep the port aligned with your current configuration.

AlmaLinux and Rocky Linux with firewalld

systemctl enable --now firewalld
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=http
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

If SSH has been moved to a custom port, add that port before you close the old one. Test the new connection in a second terminal first.

Move DNS, SSL, and email in the right order

DNS is the switch that makes the migration visible. Keep the old server online long enough for TTL changes to settle, then update A and AAAA records to point at the new VPS or dedicated server. If the move also involves a domain refresh or new nameserver setup, review DMARC, SPF, and DKIM for better email deliverability so mail does not fail after the cutover.

For SSL, verify that the certificate covers the exact hostnames in use. On the new server, run:

certbot certificates

If the certificate is missing or expired, renew it with the correct domain names before you switch traffic. Then reload the web server only after the configuration test passes.

nginx -t
systemctl reload nginx

or, if the site uses Apache:

apachectl configtest
systemctl reload httpd

Email deserves a separate check. Confirm the migrated mailboxes exist, then send a test message from an external account to the new server and back out again. If deliverability matters, compare SPF, DKIM, and DMARC records before and after the move.

Run the final verification from both sides

Do not declare the migration finished until you have tested the destination from the server and from a client device. That is how you catch mixed DNS caches, broken PHP handlers, or a service that is up but not actually answering requests.

On the VPS as root or as the non-root sudo user, check the panel and web stack:

systemctl is-active directadmin
systemctl is-active nginx
systemctl is-active httpd
ss -tulpn | grep -E ':(80|443|2222)\b'

Then test a web response locally:

curl -I http://127.0.0.1
curl -I https://example.com

On your local computer, confirm the public site resolves to the new IP and returns the expected page:

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

If the migrated site is WordPress or a store, log in and place a test order or submit a contact form. For panel moves, that functional smoke test matters more than a green service status. It shows the account behaves like a live customer site, not just a running daemon.

Troubleshooting the failures that show up most often

SSH works from the old server but not the new one. Check whether the firewall opened the right port:

ss -tulpn | grep ssh
ufw status verbose
firewall-cmd --list-ports

If the port is missing, add it, then test from a second terminal before touching the old server rules.

DirectAdmin loads, but domains return the wrong site. Check the virtual host files and DNS:

grep -R "example.com" /etc/httpd /etc/nginx /usr/local/directadmin/data 2>/dev/null | head -n 20
dig +short example.com

If the old IP still appears, the DNS change has not finished propagating or the record was updated in the wrong zone.

Mail is accepted but not delivered. Inspect mail logs and SPF/DKIM alignment:

journalctl -u exim -n 50 --no-pager
journalctl -u dovecot -n 50 --no-pager

Then compare the published DNS records with the server hostname and sending domain. A mismatch there is common after panel migrations.

The site fails after restore on AlmaLinux or Rocky Linux. Look for SELinux denials:

ausearch -m avc -ts recent
restorecon -Rv /home/exampleuser

If you see repeated denials, adjust the file context instead of disabling SELinux outright unless you are actively troubleshooting and can reverse the change later.

FAQ

How long should I keep the old DirectAdmin server online?
Keep it online until DNS has propagated, mail has been checked, and the new server passes a full site and login test. For most business moves, that means at least one verification window after cutover.

Can I migrate DirectAdmin accounts without changing IP addresses right away?
Yes. You can stage the new server, test it by hosts-file override or temporary hostname, then update DNS only after the destination is ready.

Do I need to change anything for WordPress sites?
Yes. Check PHP version, file ownership, cache plugins, and the site URL after import. Then test the admin login, a page load, and any checkout or form flow.

What is the most common cause of migration downtime?
DNS cutovers done before the new server is fully tested. The safer order is copy, verify, warm up services, then switch records.

Should I migrate mail with the website or separately?
If the domain uses the same server for mail and web, migrate both together and verify SPF, DKIM, and mailbox access before you announce the move complete.