How to Migrate from cPanel to Another Hosting Panel: Step-by-Step

Introduction

cPanel dominance in shared hosting has eroded. Rising costs, resource consumption, and licensing friction push operators toward modern alternatives: DirectAdmin, Plesk, HestiaCP, CloudPanel, or Adminbolt. A cPanel exit is not a migration-it's infrastructure surgery. Done poorly, you lose mail, kill DNS, orphan sites, and trigger mass customer escalations. Done right, accounts land on new hardware with zero downtime and zero data loss.

This playbook covers the five-phase migration framework every operator follows:

1. Pre-migration audit - inventory every account asset (domains, mail, SSL, databases, WHMCS integration, custom modules).
2. Parallel infrastructure build - new server, destination panel, security hardening, baseline validation.
3. Account migration - files, databases, mail, DNS records, SSL certificates transferred per panel type.
4. DNS cutover - TTL reduction, A/AAAA records flipped, MX records updated, propagation monitored.
5. Post-migration validation - HTTP, HTTPS, mail send/receive, DKIM/SPF/DMARC verification, login tests, rollback trigger.

This is not theoretical. Real migrations at scale demand templates, rollback playbooks, and operator discipline. Let's build them.

Pre-Migration Audit Checklist

Never start a migration without an audit.

Before touching new infrastructure, answer these questions for every account:

• Domain count - How many domains does this account own? Are any addon, parked, or subdomains? Are any expired?
• Hosting root locations - Where are DocumentRoots? /home/cpuser/public_html? Multiple directories? Symlinks?
• Email configuration - How many mailboxes? Are they Maildir or mbox format? What size? Are there forwarders, catch-all addresses, mail filters?
• Databases - MySQL or MariaDB? How many databases per account? What's the largest? Any special collations, custom engines?
• SSL certificates - Self-signed, cPanel-issued, Let's Encrypt, or third-party? Are they wildcard? Multi-domain (SAN)?
• Custom modules / PECL extensions - Are any sites using ioncube, suhosin, or deprecated PHP extensions?
• Cron jobs - How many per account? What do they execute? Are they critical?
• DNS configuration - Custom nameservers or cPanel defaults? Secondary DNS configured? Any DNSSEC?
• WHMCS integration - Is this account provisioned via WHMCS? What provisioning module? Reseller or end-user?
• Backup retention - Are automated backups stored on-server or remote? How many rotations?

Audit tool: Write a WHM API query to export account metadata:

whmapi1 listaccts | grep -E "user|domain|email" > /tmp/audit.txt

For details, loop each account:

whmapi1 getacct user=cpuser | jq '.' > /tmp/account-cpuser.json

Dump databases:

find /var/lib/mysql -maxdepth 1 -type d | sort | wc -l

Count Maildir entries:

du -sh /home/cpuser/mail/ 2>/dev/null | awk '{print $1}'

Store audit results in a spreadsheet. You'll reference this 50 times during cutover.

Choosing Your Destination Panel

Each panel targets different operators and workloads. Pick based on account density, budget, and feature lock-in.

cPanel-to-cPanel transfers (control reference)

If you're migrating to another cPanel operator, your job is simpler: use cPanel Remote MySQL or backup transfer mechanisms. Account structure, database naming, mail paths all remain identical. Risk: still-rising licensing costs. Use only if staying in the cPanel ecosystem short-term.

DirectAdmin

• Per-account, per-reseller licensing; flat per-server options available.
• Built-in cPanel importer (da_transfer tool) handles accounts, databases, mail, SSL without manual rsync.
• Web-based admin panel; lightweight, low memory footprint.
• Strong in shared hosting; weak in advanced multi-tenant workflows.
• Migration path: DA's importer tool handles 70% of work; manual validation handles the rest.

Plesk

• Per-subscription licensing; higher absolute cost for large fleets.
• Plesk Migrator (free plugin) automates cPanel→Plesk transfers via SSH or API.
• Ext-rich ecosystem (extensions for staging, security, backups).
• Windows + Linux support; common in managed WordPress hosting.
• Migration path: Install Plesk Migrator on source cPanel, point to destination Plesk, run migration per account.

HestiaCP

• Open-source, single-license model; near-zero licensing cost.
• Lightweight, Bash and PHP-based architecture; JSON API.
• Minimal UI; designed for DevOps-aware operators.
• No built-in importer; requires manual account rebuild or community scripts.
• Migration path: Bash scripts to transfer home dirs, MySQL dumps, and mail; rebuild panel configs manually.

CloudPanel

• Modern, containerized architecture; Git-friendly deployments.
• No native multitenancy; better suited for agency/managed operations than dense reseller pools.
• Very low footprint (can run 500+ accounts on 2GB RAM).
• Migration path: Manual; rsync home dirs, MySQL restores, mail IMAP import.

Adminbolt

• Flat per-server pricing; no per-account overage.
• Modern web stack; full-featured REST API; built-in multi-server SSO.
• WHMCS-native integration; password sync without custom modules.
• Modern security posture: automatic SSL provisioning, firewalling, modern TLS defaults.
• Migration path: rsync-based account transfer, MySQL restoration, native WHMCS integration simplifies downstream provisioning module cuts.

Decision tree:

• Large shared hosting fleet, cost-sensitive → DirectAdmin (da_transfer).
• Managed WordPress, Windows servers → Plesk Migrator.
• Cost-zero, bare-metal control → HestiaCP + Bash.
• Modern ops, WHMCS native → Adminbolt.
• Simplicity, cPanel familiarity → stay with cPanel.

Parallel Infrastructure Build

Never migrate to a server you haven't validated.

Provision new hardware in parallel. Destination and source run side-by-side until cutover.

Step 1: Provision and baseline the new server

# Cloud provider: DigitalOcean, Linode, Vultr, AWS

# SSH in, harden
sudo apt update && sudo apt upgrade -y
sudo ufw default deny incoming
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

# Set hostname
sudo hostnamectl set-hostname panel-new.example.com

# Configure resolvers (not cPanel's; use Cloudflare/Quad9)
cat > /etc/resolv.conf <<EOF
nameserver 1.1.1.1
nameserver 1.0.0.1
EOF

# Disable swap if cloud-init enabled it
sudo swapoff -a
sudo sed -i '/swap/d' /etc/fstab

Step 2: Install destination panel

Example: DirectAdmin

cd /tmp
wget -O install.sh http://www.directadmin.com/setup.sh
chmod 755 install.sh
./install.sh
# Follow prompts; disable services you don't need (FTP, dovecot if migrating mail separately)

Example: Adminbolt

curl -fsSL https://install.adminbolt.com | bash
# Adminbolt installer handles dependencies, SSL init, firewall rules

Example: HestiaCP

curl https://raw.githubusercontent.com/hestiacp/hestiacp/master/install/hestia-install.sh | bash
# Installs Hestia stack; configure web, mail, DB backends post-install

Step 3: Security hardening

# SSH key-only auth
sudo sed -i 's/^#PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config
sudo sed -i 's/^PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

# Fail2ban
sudo apt install fail2ban -y
sudo systemctl enable fail2ban

# Firewall ruleset
sudo ufw allow 8443/tcp  # Panel UI
sudo ufw allow 465/tcp   # SMTPS
sudo ufw allow 993/tcp   # IMAPS
sudo ufw allow 3306/tcp from 10.0.0.0/8  # MySQL (internal only)

# Check open ports
sudo ss -tuln | grep LISTEN

Step 4: Validate baseline

# Can you access the panel UI?
curl -k https://panel-new.example.com:8443

# Can you create a test account?
# (Panel-specific; use GUI or API)

# Can you create a test database?
# (Panel-specific)

# Mail delivery?
echo "test" | sendmail -v test@panel-new.example.com

# DNS resolution?
nslookup panel-new.example.com

Do not proceed to account migration until baseline validation passes.

Account Migration Approaches

cPanel-to-DirectAdmin (da_transfer)

DirectAdmin's importer is the gold standard for cPanel migrations. It runs on the cPanel server and pulls accounts to DirectAdmin.

On the DirectAdmin server, enable SSH access for the cPanel server's IP:

# DirectAdmin: add cPanel server IP to transfer whitelist
# File: /usr/local/directadmin/conf/transfer.conf (or via UI)

On the cPanel server:

# Download and run da_transfer
cd /tmp
wget http://www.directadmin.com/da_transfer.tar.gz
tar xzf da_transfer.tar.gz
cd da_transfer

# Run migration for single account
./da_transfer cpuser 1.2.3.4 cpanel password

# Or batch migrate all accounts
for user in $(grep "^" /etc/userdomains | awk '{print $2}' | sort -u); do
  ./da_transfer $user 1.2.3.4 cpanel password
done

What da_transfer handles:

• Home directory (files, public_html, mail).
• MySQL databases and users.
• Email accounts and forwarders.
• SSL certificates.
• DNS zones (can skip if you're rebuilding).
• Cron jobs.

What it doesn't:

• WHMCS integration (you reconfigure after).
• Custom cPanel modules (rebuild on DirectAdmin).
• Reseller account hierarchies (rebuild per-reseller).

Validation post-transfer:

# Check DirectAdmin account exists
/usr/local/directadmin/scripts/query/list_users.sh | grep cpuser

# Check databases migrated
mysql -e "SHOW DATABASES;" | grep cpuser

# Check mail migrated
ls -la /home/cpuser/mail/

cPanel-to-Plesk (Plesk Migrator)

Plesk Migrator runs as a Plesk extension. It automates migration via SSH or local filesystem access.

On the Plesk destination server:

# Install Plesk Migrator extension
plesk ext install plesk-migrator

# Via Plesk UI: Tools & Settings → Migrations → Migrate Domains
# Fill in:
#   - Source: cPanel server IP
#   - SSH credentials or root password
#   - Account list to migrate

# Or via CLI (if Plesk provides CLI migrator):
plesk migration-manager --migrate-from cpanel --source 1.2.3.4 --credentials root:password

What Plesk Migrator handles:

• Domains and subdomains.
• Email accounts.
• MySQL databases.
• FTP/SFTP accounts.
• SSL certificates (re-issued by Plesk post-migration if self-signed).
• Cron jobs.

Validation post-migration:

plesk bin subscription --list | grep -E "domain|status"
plesk bin mail --list | grep cpuser

cPanel-to-HestiaCP (manual/community tools)

HestiaCP has no built-in importer. Migration requires Bash scripting or community tools (often unreliable). This is the most labor-intensive path.

Community tool option:

# hcpp (Hestia cPanel Importer) - unofficial, use at your own risk
# https://github.com/hestiacp/hestiacp/tree/master/install/upgrade/community

git clone https://github.com/hestiacp/hestiacp.git
cd hestiacp/install/upgrade/community
bash cpanel_import.sh cpuser

Manual migration (more reliable):

Step 1: Transfer home directory

# On cPanel server
rsync -avz --delete /home/cpuser/ root@hestia-new.example.com:/home/cpuser/

# On HestiaCP server, rebuild web permissions
chown -R cpuser:cpuser /home/cpuser
chmod 750 /home/cpuser
chmod 750 /home/cpuser/public_html

Step 2: Migrate databases

# On cPanel server, dump all databases for the account
mysqldump --all-databases -uroot -ppassword | gzip > /tmp/cpuser-databases.sql.gz

# Transfer
scp /tmp/cpuser-databases.sql.gz root@hestia-new.example.com:/tmp/

# On HestiaCP server, restore
gunzip < /tmp/cpuser-databases.sql.gz | mysql -uroot -ppassword

Step 3: Migrate mail (Maildir)

# cPanel usually stores mail as Maildir under /home/cpuser/mail/
# Transfer as-is; HestiaCP expects same path

rsync -avz /home/cpuser/mail/ root@hestia-new.example.com:/home/cpuser/mail/

# On HestiaCP, fix permissions
chown -R cpuser:cpuser /home/cpuser/mail

Step 4: Rebuild DNS zones

# Export zones from cPanel
for domain in $(grep "^" /etc/userdomains | grep cpuser | awk '{print $1}'); do
  whmapi1 dumpzone domain=$domain > /tmp/${domain}.zone
done

# On HestiaCP, import zones manually (HestiaCP has API or manual zonefile import)
# Or rebuild them via the HestiaCP UI

Step 5: Rebuild SSL certificates

# Let's Encrypt can re-issue after DNS cutover
# Or import existing certs if still valid

# If importing existing cert:
openssl x509 -in /etc/ssl/certs/cpanel.crt -noout -text
# Copy cert, key, CA bundle to HestiaCP SSL path

cPanel-to-Adminbolt (or any modern panel): rsync-based pattern

Adminbolt and similar modern panels follow this generic transfer pattern. Use this for Adminbolt, CloudPanel, or custom panels.

Step 1: Pre-transfer validation

# On cPanel, dump account metadata
whmapi1 getacct user=cpuser > /tmp/cpuser-metadata.json

Step 2: Transfer home directory

# On cPanel server
tar -czf /tmp/cpuser-home.tar.gz /home/cpuser/

# Transfer
scp /tmp/cpuser-home.tar.gz root@adminbolt-new.example.com:/tmp/

# On Adminbolt server, extract and set ownership
cd /home
tar -xzf /tmp/cpuser-home.tar.gz
chown -R cpuser:cpuser /home/cpuser
chmod 750 /home/cpuser
chmod 750 /home/cpuser/public_html

Step 3: Transfer databases

# On cPanel, dump account-specific databases
for db in $(mysql -uroot -ppassword -e "SHOW DATABASES;" | grep cpuser); do
  mysqldump -uroot -ppassword $db | gzip > /tmp/${db}.sql.gz
done

# Transfer
scp /tmp/cpuser-*.sql.gz root@adminbolt-new.example.com:/tmp/

# On Adminbolt, restore
for file in /tmp/cpuser-*.sql.gz; do
  gunzip < $file | mysql -uroot -ppassword
done

# Rebuild database users with matching privileges
# (Adminbolt can do this via API or UI)

Step 4: Transfer mail

# On cPanel
tar -czf /tmp/cpuser-mail.tar.gz /home/cpuser/mail/

# Transfer
scp /tmp/cpuser-mail.tar.gz root@adminbolt-new.example.com:/tmp/

# On Adminbolt, extract
cd /home/cpuser
tar -xzf /tmp/cpuser-mail.tar.gz
chown -R cpuser:mail /home/cpuser/mail
chmod 750 /home/cpuser/mail

Step 5: Rebuild DNS zones

# Export from cPanel
for domain in $(grep "^cpuser" /etc/userdomains | awk '{print $1}'); do
  whmapi1 dumpzone domain=$domain > /tmp/${domain}.zone
done

# On Adminbolt, import zones via API or UI
# Most modern panels provide bulk import tools

Step 6: SSL certificate transfer

# On cPanel, export certificates
for domain in $(list of domains); do
  cp /etc/ssl/certs/cpanel-${domain}.crt /tmp/
  cp /etc/ssl/private/cpanel-${domain}.key /tmp/
done

# Transfer and import on destination
# Or regenerate via Let's Encrypt post-cutover

Step 7: Rebuild account on destination panel

Once files and data are transferred, create the account in the destination panel and point DocumentRoot to transferred home dir.

# Example: Adminbolt API to create account
curl -X POST https://adminbolt.example.com/api/accounts \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "username": "cpuser",
    "domain": "cpuser.com",
    "password": "newpassword",
    "email": "admin@cpuser.com"
  }'

# Symlink or set DocumentRoot to /home/cpuser/public_html

DNS Cutover Strategy

DNS cutover is the moment of truth. Do it wrong and mail doesn't route, sites go offline, DKIM fails.

Pre-cutover (48-72 hours before)

Step 1: Reduce TTL on source nameserver

# On cPanel, lower TTL on all A, AAAA, MX, TXT records to 300 seconds
# Via cPanel UI: Zone Editor → Edit Zone → Change TTL from 14400 to 300

# Or via API
whmapi1 modify_zone_record zone=example.com record='A' ttl=300 data=1.2.3.4

Step 2: Test destination nameserver

# Query new nameserver for all zones
dig @1.2.3.5 example.com +short  # 1.2.3.5 = new server IP

# Verify all records present (A, AAAA, MX, TXT)
dig @1.2.3.5 example.com ANY +short

Step 3: Set nameservers at registrar (don't flip yet)

Configure registrar nameservers to point to new server, but leave old ones active. Don't press save yet.

Cutover window (30-60 min)

Step 1: Verify final data sync

# On destination server, confirm latest account data
rsync -avz --delete /home/cpuser/ root@new-panel.example.com:/home/cpuser/ --dry-run
# Remove --dry-run when ready

# Confirm mail migrated
du -sh /home/cpuser/mail/

# Confirm databases restored
mysql -e "SHOW DATABASES;" | grep cpuser

Step 2: Flip authoritative nameservers

At registrar, change nameservers to destination server. TTL is already lowered; propagation is fast.

# On destination server, verify zone is serving
dig @1.2.3.5 example.com A +short
# Should return destination IP (1.2.3.5)

Step 3: Monitor propagation

# Check from multiple geolocations
for ns in 8.8.8.8 1.1.1.1 208.67.222.222; do
  echo "=== Querying $ns ==="
  dig @$ns example.com A +short
done

# Wait for all resolvers to return new IP (usually 5-30 min)

Step 4: Enable destination MX records

# Verify MX records on destination
dig @1.2.3.5 example.com MX

# If using LMTP/Postfix on destination, confirm mail server is running
systemctl status postfix
systemctl status dovecot

Post-cutover (30-60 min)

Step 1: Monitor mail delivery

# Send test email from external account to migrated domain
echo "test" | mail -s "cutover test" test@example.com

# Check destination mail server logs
tail -f /var/log/mail.log | grep example.com

# Confirm delivery in mailbox

Step 2: Validate HTTP/HTTPS

# Test web connectivity
curl -I http://example.com
curl -I https://example.com

# Check SSL chain
openssl s_client -connect example.com:443 -showcerts < /dev/null

Step 3: Test login / cron execution

# SSH into account (if SSH enabled)
ssh cpuser@example.com

# Verify cron jobs are scheduled
crontab -l

# Trigger a cron job manually to confirm

Rollback (if needed)

If cutover fails:

# At registrar, flip nameservers back to old server
# TTL is low; propagation should occur within 5 min

# Old server continues serving from old IP
# New server can be fixed offline without traffic impact

Email Migration

Mail is the most fragile migration component. Timing, authentication, and filtering matter.

Maildir vs mbox format

cPanel typically uses Maildir (one file per email). Most modern panels also use Maildir.

# Confirm cPanel format
ls -la /home/cpuser/mail/example.com/user/
# Maildir: new/, cur/, tmp/ directories
# mbox: single file named after domain

# If mbox, convert to Maildir
# (Most panels do this automatically; check destination panel docs)

IMAP-based transfer (for parallel cutover)

If you want to transfer mail without downtime:

Option 1: IMAPSync

# Install on intermediate server or destination
apt install imapsync perl -y

# Sync mailbox by mailbox
imapsync \
  --host1 cpanel.example.com \
  --user1 user@example.com \
  --password1 oldpass \
  --host2 newpanel.example.com \
  --user2 user@example.com \
  --password2 newpass \
  --syncinternaldates

Option 2: Dovecot migration

If both panels run Dovecot:

# On destination, configure sync tool
dsync -u user@example.com mirror \
  ssh -L cpanel.example.com \
  /home/cpuser/mail/example.com/user/

DKIM, SPF, DMARC re-setup

Mail authentication must be re-keyed on destination server.

On cPanel (export keys):

# Locate DKIM keys
ls -la /var/cpanel/domain_keys/

# Copy key material for each domain
cat /var/cpanel/domain_keys/cpanel.example.com.key
cat /var/cpanel/domain_keys/cpanel.example.com.public

On destination:

# Re-generate DKIM keys for new server
# (Most panels do this automatically; check destination UI)

# Update SPF record
# Old: v=spf1 include:cpanel.example.com ~all
# New: v=spf1 include:newpanel.example.com ~all

# Update DMARC policy
# _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

# Test SPF/DKIM
dig example.com TXT | grep v=spf1
dig default._domainkey.example.com TXT  # DKIM record

# Use mail-tester.com or similar to validate auth chain

Timing: Repoint SPF/DMARC TXT records immediately after DNS cutover. DKIM records (which include the public key) are regenerated on destination; update them after new server is active.

SSL Re-issuance

SSL certificates are tied to the server that issued them (especially Let's Encrypt).

Let's Encrypt re-issue (post-cutover)

Most modern panels auto-renew Let's Encrypt certs. On cutover:

# On destination panel, trigger re-issue for all domains
# (Adminbolt, HestiaCP, DirectAdmin, Plesk all have renewal commands)

# Manual renewal example (certbot):
certbot renew --force-renewal

Third-party certificates (manual import)

If the customer owns a third-party cert:

# Export from cPanel
cp /etc/ssl/certs/example.com.crt /tmp/
cp /etc/ssl/private/example.com.key /tmp/
cp /etc/ssl/certs/example.com-bundle.crt /tmp/

# Transfer to destination
scp /tmp/example.com* root@new-panel.example.com:/tmp/

# Import on destination via panel UI or API

Self-signed certs (replace immediately)

If cPanel generated self-signed certs, replace them on destination:

# On destination, issue Let's Encrypt cert
certbot certonly --webroot -w /home/cpuser/public_html \
  -d example.com -d www.example.com

# Or use destination panel's auto-issuance feature

Database Migration

Large databases require special handling.

Small databases (<500MB)

# Dump on source
mysqldump -uroot -ppassword cpuser_db > /tmp/cpuser_db.sql

# Transfer
scp /tmp/cpuser_db.sql root@new-panel.example.com:/tmp/

# Restore on destination
mysql -uroot -ppassword < /tmp/cpuser_db.sql

Large databases (>1GB)

Use compression and streaming:

# On source
mysqldump -uroot -ppassword \
  --single-transaction \
  --quick \
  --lock-tables=false \
  cpuser_db | gzip > /tmp/cpuser_db.sql.gz

# Transfer (via rsync for resume capability)
rsync -avz --progress /tmp/cpuser_db.sql.gz root@new-panel.example.com:/tmp/

# On destination, restore with progress
pv /tmp/cpuser_db.sql.gz | gunzip | mysql -uroot -ppassword

Database user privileges

cPanel often creates database users with names like cpuser_dbuser. Ensure same username/password exists on destination:

# On destination, create user
mysql -uroot -ppassword -e "CREATE USER 'cpuser_dbuser'@'localhost' IDENTIFIED BY 'password';"
mysql -uroot -ppassword -e "GRANT ALL PRIVILEGES ON cpuser_db.* TO 'cpuser_dbuser'@'localhost';"
mysql -uroot -ppassword -e "FLUSH PRIVILEGES;"

WHMCS Module Switch

If using WHMCS to provision accounts, reconfigure the provisioning module post-migration.

Step 1: Update provisioning module

In WHMCS Setup → Products/Services → Configurable Options:

1. Select the product for the destination panel type.
2. Change Provisioning Module from cPanel to DirectAdmin, Plesk, Adminbolt, or custom.
3. Test module with a test account.

Step 2: Password sync

Many WHMCS modules support automatic password sync:

# On destination panel, enable API for WHMCS
# (Panel-specific; check destination docs)

# In WHMCS, run manual sync for existing accounts:
WHMCS CLI: whmcs-cli admin:sync-accounts --module=newpanel

Step 3: Resynchronize existing accounts

# In WHMCS, for each migrated account:
#   Admin Area → Clients → Select Client → Manage Products
#   Click gear icon → Resync Status (or Run Module Command)
#
# This pulls account status from new panel and updates WHMCS database

Custom Modules and Extensions

cPanel often runs custom modules (mod_security rules, custom quotas, billing hooks).

Inventory custom modules

# On cPanel, list installed modules
ls -la /usr/local/cpanel/base/installation/*/
rpm -qa | grep -i cpanel

# List WHM plugins
ls -la /usr/local/cpanel/whostmgr/docroot/cgi/addon_*

Rewrite for destination panel

Each destination panel has its own API and extension mechanism:

• DirectAdmin: Write to /usr/local/directadmin/plugins/ or use nameserver hooks.
• Plesk: Write to /var/www/vhosts/ or build Plesk Extension SDK plugins.
• HestiaCP: Use v-* CLI commands or JSON API.
• Adminbolt: Use REST API webhooks and custom scripts.

Migration strategy: Pause custom features during cutover. Post-migration, rewrite the most critical modules (billing sync, backup hooks, security rules) for the destination panel.

Validation Tests Post-Migration

Do not consider cutover complete until these tests pass:

HTTP/HTTPS connectivity

# Each migrated domain
for domain in example.com www.example.com; do
  echo "=== $domain ==="
  curl -I http://$domain | head -1
  curl -I https://$domain | head -1
  curl https://$domain 2>&1 | head -10
done

Mail send/receive

# Send email to migrated account
echo "test body" | mail -s "test" user@example.com

# Check receipt in mailbox
# (Log in via webmail or IMAP client)

# Send email from migrated account
# (Verify it doesn't bounce due to SPF/DKIM)

DNS lookup

# From external resolver
dig @8.8.8.8 example.com A
dig @8.8.8.8 example.com MX
dig @8.8.8.8 example.com TXT | grep -i dkim

Login tests

# FTP/SFTP login (if enabled)
sftp cpuser@example.com

# SSH login (if enabled)
ssh cpuser@example.com

# cPanel/Plesk/DirectAdmin/Adminbolt web UI login
# (Test admin account; test end-user account)

Cron execution

# Trigger a cron job manually
ssh cpuser@example.com '/path/to/backup.sh'

# Confirm cron log
tail -f /var/log/syslog | grep CRON

# Or in destination panel cron logs

Rollback Plan

Before cutover, document the rollback sequence.

Rollback decision tree

Within 1 hour of cutover: Revert DNS to old server. Low risk; all traffic restored quickly.

Within 24 hours: If databases or mail are corrupted, restore from source backups. Requires brief downtime.

Beyond 24 hours: Treat as data recovery issue; evaluate cost vs. full re-migration.

Execute rollback

# At registrar, change nameservers back to old server
# TTL is still 300; propagation within 5 minutes

# Confirm old server is serving
dig @old-server-ip example.com A

# Once old server is live, fix destination offline
# (Debug database corruption, mail delivery issues, etc.)

Post-rollback analysis

1. What broke?
2. Why didn't pre-cutover validation catch it?
3. What additional pre-cutover tests are needed?
4. Reschedule cutover with fixes.

Common Migration Mistakes

1. Migrating without pre-flight audit

Mistake: Assuming all accounts are identical. Fix: Audit every account. Account A has 5 databases; Account B has 50. Custom modules vary. Wildcard certs differ from SAN certs. Cost of skipping: Orphaned databases, broken apps, angry customers.

2. Not testing on destination before cutover

Mistake: Migrating to untested server. Fix: Create 3-5 test accounts. Run full validation (HTTP, mail, DNS, cron, login). Fix issues offline. Cost of skipping: Cutover failure; need to roll back; reputation damage.

3. Cutting over all accounts at once

Mistake: Migrating entire fleet in one window. Fix: Start with 5-10 low-risk accounts. Debug issues. Then do full migration in waves (20% per day). Keep old server running until 100% validation is done. Cost of skipping: One major issue breaks all accounts. Rollback chaos.

4. Forgetting DNS TTL reduction

Mistake: Cutting over DNS with TTL=14400. Fix: Lower TTL 48-72 hours before cutover. Propagation is instant when cutover happens. Cost of skipping: 4-hour convergence window; old resolvers return old IP; email bounces, sites unreachable.

5. Not re-keying DKIM/SPF/DMARC

Mistake: Not updating email authentication. Fix: Generate new DKIM keys on destination. Update SPF records. Test with mail-tester.com. Cost of skipping: Emails treated as spoofed; land in spam; customers complain.

6. Losing database privileges

Mistake: Restoring database but not recreating database user. Fix: Export database users and privileges from cPanel; recreate on destination with same username and password. Cost of skipping: Application can't connect to database; site returns error.

7. WHMCS integration forgotten

Mistake: Migrating accounts but not updating WHMCS provisioning module. Fix: Switch module immediately. Run resync for all accounts. Test password sync. Cost of skipping: Password resets fail; customer portal shows wrong status; suspension logic breaks.

8. Custom modules not ported

Mistake: Leaving custom cPanel plugins behind. Fix: Identify critical plugins. Rewrite or find equivalent on destination. Test extensively. Cost of skipping: Billing hooks don't fire; backup routines don't run; security policies don't apply.

9. Not backing up old server

Mistake: Deprovisioning old server immediately. Fix: Keep old server running for 7-30 days. Verify all accounts are truly working. Only then decommission. Cost of skipping: Customer reports corrupted account. Old data already deleted. Unrecoverable.

10. Skipping post-migration validation

Mistake: Declaring migration done without testing. Fix: Run the validation checklist (HTTP, mail, DNS, login, cron). Fix each failure before moving on. Cost of skipping: Hidden failures discovered by customers. Customer escalation, refunds, reputation loss.

Migration Timeline Templates

10-account fleet (shared hosting)

100-account fleet (managed hosting)

1000-account fleet (ISP / reseller network)

FAQ

Q: How do I minimize downtime during DNS cutover?

A: Reduce TTL 48-72 hours before cutover. On cutover day, validate destination is serving all zones and mail is working. Flip nameservers at registrar. Propagation should complete within 5-30 minutes. Keep old server running as fallback for 24 hours.

Q: Can I migrate accounts one at a time while keeping the old server live?

A: Yes. This is the safest approach. Migrate account A, validate HTTP/mail/DNS for 24-48 hours, then migrate account B. Keep old server running as fallback until all accounts are validated on destination. Cost: extended hardware rental for old server.

Q: What if a customer's SSL certificate is self-signed and expired?

A: Let's Encrypt can re-issue after DNS cutover. On destination server, use destination panel's auto-issuance or run certbot certonly manually. Expired self-signed certs are not usable; customer must accept a new cert or purchase third-party cert.

Q: How do I handle reseller accounts during migration?

A: Reseller account structure is hierarchical in cPanel. On migration, rebuild the reseller account first, then rebuild end-user accounts under that reseller. Test reseller's ability to manage end-user accounts on destination panel. WHMCS integration must account for reseller-level provisioning module.

Q: Can I migrate email without migrating everything else?

A: Yes. Use IMAPSync to transfer emails in parallel. DNS cutover triggers mail delivery to new server, but messages are already synced. This approach requires dual mail server setup and is complex; only use if downtime is critical.

Q: What about FTP/SFTP credentials?

A: Most modern panels auto-create SFTP access for the account user. FTP is legacy; deprecate it. Test SFTP login post-migration. If customer has FTP scripts, they need rewriting for SFTP.

Q: How do I handle custom PHP extensions (ioncube, etc.)?

A: Check if destination panel supports them. Most do not. If critical, request customer migrate to panel that supports it, or rewrite application to not depend on extension. If unavoidable, compile extension on destination panel (often unsupported; customer risk).

Q: Is Adminbolt a good migration destination?

A: Yes. Adminbolt's flat per-server pricing simplifies budgeting. Native WHMCS integration means zero custom module work. REST API is modern. No built-in cPanel importer, so plan rsync-based migration using the patterns in this guide. Security posture (automatic SSL, modern TLS, firewall defaults) is strong.

Q: How long should I keep the old server running post-migration?

A: Minimum 7 days. Ideal: 30 days. This window allows data recovery if corruption is discovered late. Only decommission after 100% of accounts are confirmed working and customers have tested thoroughly.

Q: What if a customer's website depends on a deprecated cPanel-specific feature?

A: Identify the feature early (in pre-audit). Evaluate: can it be ported to destination panel? Can it be removed? Can the application be rewritten? Work with customer to resolve pre-cutover. Do not migrate until dependency is addressed.

Conclusion

cPanel migration is a systems engineering discipline, not a one-off task. Success requires pre-flight audit, parallel infrastructure, tested account transfer, orchestrated DNS cutover, and 48-hour post-validation. Mistakes are costly: mail loss, DNS outages, broken logins, and customer escalations.

The five-phase framework (audit, build, migrate, cutover, validate) is operator-tested. Use it for any panel-to-panel migration. Customize timelines based on account density and risk tolerance. Always keep the old server live as a safety net.

Modern panels like Adminbolt simplify the destination choice via modern APIs, flat pricing, and native WHMCS integration. But the migration process itself-audit, data transfer, DNS orchestration, validation-remains constant.

Plan for three months minimum (large fleets). Start with test accounts. Batch cutover in waves. Measure twice, migrate once.

Summary

Choosing or replacing a hosting control panel is a multi-year decision. The right choice depends on your pricing model, automation needs, security stack, and growth trajectory - not on brand recognition alone.

If you want to evaluate a modern flat-fee panel without commitment, adminbolt.com offers a 30-day free trial with no credit card required. Questions, feedback, and migration discussions are welcome on Discord or the community forum.