WHM Account Setup and Migration Checklist for 2026

What this WHM account setup tutorial covers

WHM account setup is the cleanest way to bring a new reseller, agency, or managed customer onto a server without leaving DNS, mail, or backup ownership ambiguous. This tutorial walks through a production-safe migration on Debian-backed infrastructure, including the server-side checks you need to validate access, create the account, move data, verify mail handling, and confirm the account still works after a reboot.

This guide is written for Hostperl customers who need a support-friendly handoff, not a lab demo. If you are sizing the platform first, a Hostperl VPS gives you the isolation you need for account separation, while shared and managed plans suit smaller sites with less administrative work.

If you are planning a wider move, this workflow pairs well with Shared hosting migration checklist for a clean 2026 move and Shared hosting support response times in 2026. Account setup only helps if the migration and handoff are documented clearly.

What you need before you start

• A fresh Debian 12 or Debian 13 server with root SSH access.
• WHM/cPanel licenses already activated on the server.
• A second terminal on your local computer for verification.
• The source account details if you are migrating an existing customer.
• A domain name, for example example.com, and the target server hostname server.example.com.

Open a terminal on your local computer and connect first.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the real public IP assigned to your server. If your provider uses a non-root initial login, use that account first, then elevate with sudo.

On the VPS as root, confirm the operating system before you touch packages or firewall rules.

cat /etc/os-release

You should see Debian 12 or Debian 13 details. This procedure is written for Debian-family hosts because the selected track is Debian and WHM/cPanel deployment is commonly managed on a supported RHEL-compatible control plane, while customer-facing admin work still benefits from Debian-style account operations and network checks during the same migration window. If your WHM server itself is not Debian-based, keep the account workflow but use the vendor-supported package and service commands for that platform.

Set a safe hostname, time sync, and admin user

Even when WHM handles the accounts, you still want a stable server identity, accurate time sync, and a non-root admin session for routine work. These steps cut down on support confusion after a migration.

On the VPS as root, set the hostname to the public name you intend to keep.

hostnamectl set-hostname server.example.com

Replace server.example.com with your real host name. Then confirm it.

hostnamectl status

Next, install and enable time sync. Debian 12 and 13 use systemd-timesyncd by default on many builds, but installing chrony keeps time drift low during migrations.

apt update
apt install -y chrony
systemctl enable --now chrony
chronyc tracking

Successful output should show synchronization data and a reachable source. If time is wrong, mail and TLS checks often fail later.

Create a non-root administrator called deploy for day-two account work and keep the original root session open until login is verified.

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

Use your existing root public-key setup if you have one. If you do not, copy only the key you trust. The permissions matter: SSH will ignore overly open files.

On your local computer, open a second terminal and test the new account.

ssh deploy@203.0.113.10

After login, confirm sudo access.

sudo -v
whoami
pwd

You should see deploy as the user and a successful sudo prompt. Keep the root session open until this works. If you lose access, stop here and fix SSH before continuing.

Create the WHM account with the right limits

In Hostperl support work, the most common account issue is not the migration itself. It is the wrong resource profile. A customer who gets too little disk or too much mail allowance usually ends up with a second ticket.

Use WHM to create the account with the correct domain, package, and contact email. If you prefer CLI-driven automation, cPanel/WHM provides whmapi1. Run this on the VPS as root after confirming the license is active.

whmapi1 createacct username=client01 domain=example.com contactemail=admin@example.com plan=default

Replace client01, example.com, and the contact email with the customer’s real details. You should receive a JSON response showing status: 1 and the new account metadata. If the plan name differs on your server, list plans first with:

whmapi1 listpkgs

For a new reseller or agency, the account should stay isolated from other customer sites. That keeps troubleshooting straightforward when you later move mail routing or restore from backup. Hostperl’s shared hosting limits and upgrade triggers in 2026 guide is useful if you need a quick decision on when a customer has outgrown shared hosting and needs a WHM-managed environment.

Migrate data without breaking mail or DNS

A clean account migration is more than copying files. You need the document root, database, email boxes, and DNS records aligned before cutover. If the source server is still live, lower the DNS TTL 24 hours before moving traffic.

On the source server or backup staging host, export the web files and database. The exact database name varies by site, so confirm it first.

mysql -e "SHOW DATABASES;"
mysqldump -u root -p example_db > example_db.sql
tar -czf site-files.tar.gz /home/exampleuser/public_html

Replace example_db and the file path with the real site values. Then transfer the archives to the WHM server.

scp site-files.tar.gz example_db.sql root@203.0.113.10:/root/

On the VPS as root, restore the web files into the new account’s home directory and import the database.

tar -xzf /root/site-files.tar.gz -C /home/client01/public_html
chown -R client01:client01 /home/client01/public_html
mysql -u root -p example_db < /root/example_db.sql

If the application uses a different document root, point it to the cPanel account’s actual web root. Then update the app’s config file with the new database credentials created in WHM.

For email, verify that mailboxes exist and that MX points to the new server if you are handling mail locally. Customers moving from shared hosting often miss this step. The migration may finish cleanly, but mail still lands on the old host.

Lock down SSH, firewall, and account access

Do not tighten access until you have verified the new admin login. After that, you can remove password logins and restrict SSH to keys. Debian uses nftables or UFW depending on your baseline; WHM environments often sit behind provider firewalls, so only apply local rules you can keep documented.

On the VPS as root, check whether SSH still accepts password logins before changing anything.

sshd -T | grep -i passwordauthentication

If it returns passwordauthentication yes, you can switch it off after confirming key login works. Edit the SSH daemon file carefully.

nano /etc/ssh/sshd_config

Set these lines exactly:

PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes

Save and exit, then test the syntax before reload.

sshd -t
systemctl reload ssh

Use a second terminal to confirm you can still log in with the key before closing the root session. If the SSH session drops, the open root terminal gives you a recovery path.

If your WHM host also needs a local firewall, allow SSH and the control panel ports first, then enable the firewall. For UFW on Debian:

apt install -y ufw
ufw allow 22/tcp
ufw allow 2087/tcp
ufw allow 2083/tcp
ufw enable
ufw status verbose

Replace the ports only if your panel uses non-default values. The expected output should list SSH and WHM/cPanel access as allowed.

Check the WHM account, web service, and mail path

After migration, test the account from the server side and from a client browser. You want to catch path or DNS issues before the customer does.

On the VPS as root, inspect the account details and listening services.

whmapi1 accountsummary user=client01
ss -tulpn | grep -E ':(80|443|2083|2087)\b'

You should see the account record and the panel/web ports in a listening state. If Apache or LiteSpeed is not responding, the service status will usually tell you why.

systemctl status httpd
journalctl -u httpd -n 50 --no-pager

On a Debian-backed web stack, the service name may differ if the application server is proxying to PHP-FPM. In that case, check the web server and PHP service names you actually use. The goal is simple: the account must answer on port 80 or 443 without errors.

From your local computer, test HTTP, then HTTPS.

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

Replace example.com with the real domain. A healthy response returns 200, 301, or 302 depending on your redirect policy. A certificate error usually means the DNS name does not yet point at the WHM server or the TLS certificate was issued for the wrong hostname.

Issue and repair TLS after the cutover

New account setups fail most often at certificate time because the domain still resolves elsewhere. Wait until A and AAAA records point to the new server, then request the certificate.

On the VPS as root, use AutoSSL or the certificate tool exposed by your panel. If you manage certificates manually, the pattern below shows the check first and the reload only after syntax validation.

curl -I https://example.com
openssl s_client -connect example.com:443 -servername example.com 

Look for the certificate subject and issuer. If the wrong certificate appears, renew or replace it inside WHM, then re-test. For mixed mail and web services, a valid certificate is part of the support handoff, not a nice extra.

Hostperl’s WordPress migration checklist for zero-downtime cutovers also helps if the account is hosting a WordPress site and you need to move it without a visible outage.

Backups, rollback, and restore test

Never close a migration without a rollback plan. Keep the old account intact until the new one has passed at least one functional test cycle and one mail delivery test.

On the VPS as root, create a backup snapshot or archive of the restored account before you make further changes.

tar -czf /root/client01-prechange-backup.tar.gz /home/client01 /var/lib/mysql/example_db

Store it off-server if possible. If you need to roll back, reverse the file and database restore, then point DNS back to the old host only after the old host is confirmed healthy.

A quick restore test is better than a theoretical backup. Restore the archive into a temporary path and confirm the files are readable.

mkdir -p /tmp/restore-test
tar -xzf /root/client01-prechange-backup.tar.gz -C /tmp/restore-test
find /tmp/restore-test -maxdepth 2 -type f | head

You should see site files and database dumps. If you do not, your backup is incomplete.

Common failures and the quickest checks

Account creation fails in WHM: Run whmapi1 listpkgs and confirm the package name exists. Then check disk space with df -h. If the server is full, clean old backups before retrying.

SSH lockout after hardening: Keep the original root terminal open. Run sshd -t before reload and use a second terminal to test login. If access fails, revert the SSH config file and reload again.

Site loads but mail does not: Check the domain’s MX record and the service state with systemctl status postfix or your panel’s mail stack. Wrong MX records usually mean the account migration is only half-finished.

HTTPS certificate mismatch: Confirm DNS propagation with dig example.com A +short and dig example.com AAAA +short. If the old IP still appears, wait before reissuing the certificate.

Final verification from server and client

On the VPS as root, confirm the account, services, and reboot persistence.

whmapi1 accountsummary user=client01
systemctl is-enabled ssh
systemctl is-active ssh
reboot

After the server returns, log in again from your local computer and confirm the site still answers:

ssh deploy@203.0.113.10
curl -I https://example.com

You should see SSH access restored, the host reachable after reboot, and the site returning the expected HTTP status. That is the standard a support team can hand to a customer without extra clarification.

FAQ

Should I disable root SSH before or after the migration?
After. Keep root access open until the new non-root login works, SSH syntax is validated, and the account passes browser and mail checks.

Do I need DNS changes before creating the WHM account?
No. Create the account first, move the data, then update A, AAAA, and MX records when the destination is ready.

What if the customer site uses WordPress?
Restore the files and database, update wp-config.php, and run a quick front-page and login test. If the move is zero-downtime, keep the old site online until the new one is confirmed.

What is the safest rollback path?
Keep the source account intact, preserve a full backup of the destination, and switch DNS back only after you verify the old host still serves the site cleanly.

Can Hostperl help with this migration?
Yes. Hostperl’s support team can help you choose the right hosting size, move the account, and confirm the post-cutover checks on a VPS or managed hosting plan.