Lost the .com: Move to .net on DirectAdmin Without Data Loss

I had a client who let their .com domain expire past the grace period. By the time they noticed, it had already ended up with domain squatters. I checked the DNS, and it was pointing to someone else's parking page. Buying it back at auction would cost more than several years of hosting combined. The client decided to let it go and registered the same name under .net instead.

The task that landed on my desk was this: the entire site — files, mail, and databases — was on DirectAdmin under the old .com domain. How could I move it to .net without losing a single file and with as little downtime as possible? I am writing up the method I actually used in case anyone runs into the same situation.

My initial plan (which did not work)

My first plan was to add the .net domain to the existing account and gradually move everything over — but this account's package had a limit of 1 domain. DA gave me a short reply:

Cannot Create Another Domain

I could have changed the package, but when I dug into DA's API, I found a better option — DA has a domain rename command that moves everything in one go, called CMD_CHANGE_DOMAIN.

CMD_CHANGE_DOMAIN — rename the entire domain

How to call the API as the user (run as root on the server):

# สร้าง login URL ชั่วคราวของ user นั้น
directadmin api-url --user=cafeuser
# ได้ URL แบบ https://cafeuser:<loginkey>@server.example.com:2222

Then send the rename request:

URL='https://cafeuser:[email protected]:2222'
curl -sk "$URL/CMD_CHANGE_DOMAIN" \
  --data 'old_domain=oldcafe.com&new_domain=oldcafe.net'
# ตอบ: successfully changed

What CMD_CHANGE_DOMAIN moves — I verified each item after running it:

• The docroot /home/cafeuser/domains/oldcafe.com was moved to oldcafe.net, with every file intact
• A DNS zone was created at /etc/bind/oldcafe.net.db with the same records
• Mail at /etc/virtual/oldcafe.com was moved to oldcafe.net, with all mailboxes intact
• The nginx/apache vhosts were rewritten
• Databases were unaffected because DB names are tied to the user, not the domain

What does "not" happen automatically — 4 more steps

1. Rewrite the httpd config + reload — after renaming, the site sometimes serves the server's default page instead. Force a rewrite to be sure:

cd /usr/local/directadmin
echo 'action=rewrite&value=httpd&user=cafeuser' >> data/task.queue
./dataskq d
nginx -s reload

2. Request a new SSL cert — the old cert is for .com; its name does not change with the domain. The browser will immediately report a certificate mismatch. Wait until the .net DNS points to our server first (HTTP-01 validation must be able to reach it), then request the cert:

/usr/local/directadmin/scripts/letsencrypt.sh request 'oldcafe.net,www.oldcafe.net' 4096

This script updates cert.combined and handles the reload itself.

3. Fix hardcoded links in the site files — old static sites often have absolute URLs like http://oldcafe.com/... embedded everywhere. Back up first, then run sed:

cd /home/cafeuser/domains/oldcafe.net
tar czf /root/oldcafe-pre-sed-$(date +%F).tgz public_html
grep -rl 'oldcafe\.com' public_html --include='*.html' | \
  xargs sed -i 's/oldcafe\.com/oldcafe.net/g'

4. Update the billing system — if a billing system has the domain name on record, update it there too. Otherwise, the next invoice will list the dead domain.

A verification trap — do not trust results from 127.0.0.1

I spent quite a while on this one. I checked the cert with curl from the server itself, pointing to 127.0.0.1 — and kept getting the wrong cert. I thought something was broken. In fact, the request was reaching the default vhost because SNI did not match. Always test through the public IP:

# แบบนี้ถึงจะเห็นของจริง (203.0.113.10 = IP เซิร์ฟเวอร์)
curl -s --resolve oldcafe.net:443:203.0.113.10 \
  -o /dev/null -w '%{http_code} ssl_verify=%{ssl_verify_result}\n' \
  https://oldcafe.net/
# ต้องได้ 200 ssl_verify=0

openssl s_client -connect 203.0.113.10:443 -servername oldcafe.net </dev/null 2>/dev/null \
  | openssl x509 -noout -subject

Summary

1. If the domain is taken, there is no need to move to a new account — CMD_CHANGE_DOMAIN renames the whole thing, including all files, mail, and DNS
2. The command runs immediately, with no undo — think before sending it
3. 4 follow-up tasks do not happen automatically: rewrite httpd, get a new cert, sed the links, update billing
4. Verify only through the public IP; do not trust results from 127.0.0.1

After finishing this job, I went through and enabled auto-renew for every domain I manage. If you have not enabled it yet, take care of it when you can. If I missed anything in the explanation or made a typo, I will come back and fix it later.