Migration
adminbolt team19 min read

What Happens to Your Data When You Cancel a cPanel License?

What Happens to Your Data When You Cancel a cPanel License?

You've decided to cancel your cPanel license. Maybe the cost is getting steep. Maybe you're migrating to another panel. Maybe you're consolidating servers. Either way, one question keeps you up at night: where does my data go?

The short answer: your data does NOT disappear when you cancel cPanel. The license terminates the software's ability to run, but your files, databases, email, and DNS zones stay right there on the disk. That said, extracting and migrating that data without an active cPanel interface requires technical know-how-and doing it wrong can cost you hours of downtime.

This guide walks you through what actually happens during license cancellation, where your data lives, how to safely export it, and how to import it into another control panel. Whether you're stepping away from cPanel gracefully or migrating to a competitor, you'll find the roadmap here.

License Termination: What Actually Happens

When a cPanel license expires or you cancel it, the control panel software stops running-not your data. Here's the technical sequence:

Day your license ends:

  • cPanel daemons (cpconfd, tailwatchd, and related services) stop responding to license validation
  • The WHM interface becomes inaccessible or throws license errors
  • File Manager, email clients configured through cPanel, and API calls begin failing
  • Your server keeps running; kernel, filesystem, databases, mail services, and web servers continue operating

What persists:

  • All user home directories remain on disk (/home/username/)
  • MySQL/MariaDB data files stay in /var/lib/mysql/
  • Mail spools in /var/spool/mail/ and Maildir structures
  • DNS zone files in /var/named/
  • SSL/TLS certificates in the expected directories
  • Cron jobs, IP allocation, and system configs remain intact

What breaks:

  • You can't create new accounts or manage existing ones through WHM/cPanel
  • Automated backups stop (if you were relying on cPanel's backup module)
  • DNS management through cPanel UI ends
  • Email account creation through cPanel ceases
  • Some system tools may refuse to start if they check licensing

The license is a management layer, not a data container. Your actual data is stored in standard Linux formats on the filesystem and in industry-standard databases.

The File System Layout: Where Everything Lives

Understanding the directory structure is essential for manual data extraction. Here's the canonical breakdown:

User Home Directories

/home/username/
├── public_html/          # Website files
├── mail/                 # Legacy mail (older systems)
├── .cagefs/              # CloudLinux jailing (if applicable)
├── .ssh/                 # SSH keys
├── .cpanel/              # cPanel-specific configs
└── .bashrc, .bash_profile, etc.

Every domain and addon domain gets a subdirectory structure under the main username.

MySQL/MariaDB

/var/lib/mysql/
├── mysql/               # System database (grants, users)
├── information_schema/
├── performance_schema/
└── [your_databases]/    # All customer databases

The actual .MYI, .MYD (MyISAM) or .ibd (InnoDB) files are here. As long as the datadir hasn't moved, you can copy these files wholesale or extract them via mysqldump.

Mail Storage

/var/spool/mail/         # Mbox-format mailboxes (legacy)
/home/username/mail/     # Maildir format (modern cPanel default)
/var/cpanel/*/           # cPanel account metadata

Maildir is the standard nowadays. Each email lives as an individual file in Maildir/new/, Maildir/cur/, and Maildir/tmp/ folders.

DNS Zones

/var/named/
├── named.conf           # Bind configuration
├── named.conf.default
├── zone.db.yourdomain.com
└── [all other zones as .db files]

Mail Server Configs

/etc/exim*/              # Mail transport (exim is cPanel's default)
/etc/dovecot/            # IMAP/POP3 server configs
/etc/postfix/            # Alternative MTA (if swapped in)

cPanel User Metadata

/var/cpanel/users/       # Account settings, contact info
/var/cpanel/userdata/    # Domain configs, addon domains
/var/cpanel/homedir.conf # Home directory assignments

The cpaccount Tarball: Your Portable Backup Format

When you run a full account backup in cPanel, it generates a cpaccount-[username].tar.gz file. This tarball is the Swiss Army knife for data migration. Understanding its structure is critical.

What's Inside a cpaccount Tarball

cpaccount-john.tar.gz
└── john/
    ├── homedir/                      # Full /home/john/ contents
    │   ├── public_html/
    │   ├── public_ftp/
    │   └── .cpanel/
    ├── mysql/                        # MySQL databases
    │   ├── dbname1.sql
    │   └── dbname2.sql
    ├── dns/                          # DNS zones
    │   ├── example.com.db
    │   └── subdomain.example.com.db
    ├── mail/                         # Mail accounts and settings
    │   ├── [email protected]
    │   └── autoresponders.yaml
    ├── ssl/                          # SSL certificates & keys
    │   ├── example.com.crt
    │   ├── example.com.key
    │   ├── example.com.csr
    │   └── example.com.cab
    ├── userdata/                     # Domain configs
    │   ├── example.com
    │   └── addon.example.com
    ├── cron/                         # Cron jobs
    ├── etc/                          # User-specific configs
    └── metadata.json/yaml            # Account metadata (quotas, features)

This is the ideal format for migration because it's self-contained and parseable by other panels. If you don't have a pre-made cpaccount tarball, you can manually create one from the raw filesystem components.

Extracting Data Without an Active cPanel/WHM License

If your license has already expired, you can't use WHM's backup interface. Time for manual work.

Step 1: SSH to the Server as Root

You need direct filesystem access. Open an SSH terminal as root (or use sudo):

ssh root@your-server-ip

Step 2: Create a Backup Directory

mkdir -p /backup/migration
cd /backup/migration

Step 3: Archive User Home Directories

For a single account:

tar -czf cpaccount-john.tar.gz /home/john/

For all accounts at once:

for user in $(ls /home/ | grep -v lost+found); do
  tar -czf cpaccount-${user}.tar.gz /home/${user}/
done

This captures website files, mail data (if in Maildir format), SSL certs, and configs.

Step 4: Dump MySQL Databases

If you still have MySQL/MariaDB running:

mysqldump --all-databases --single-transaction > all-databases.sql

Or per-database:

mysqldump -u root dbname > dbname.sql

If MySQL isn't running, you can copy the raw InnoDB files:

cp -r /var/lib/mysql /backup/migration/mysql-raw/

(Stop MySQL before copying raw files to avoid corruption.)

Step 5: Export DNS Zones

tar -czf dns-zones.tar.gz /var/named/

Or selectively:

cp /var/named/zone.db.yourdomain.com /backup/migration/

Step 6: Backup Mail Spools

If mail is still in mbox format (rarely, nowadays):

tar -czf mail-spools.tar.gz /var/spool/mail/

For Maildir (the modern default):

for user in $(ls /home/); do
  tar -czf cpaccount-${user}-maildir.tar.gz /home/${user}/mail/
done

Step 7: Compress and Download

tar -czf full-server-backup-$(date +%Y%m%d).tar.gz /backup/migration/

Then download via SCP, SFTP, or cloud storage.

Database Access Without WHM

If MySQL/MariaDB is still running (or you can start it), you can query and export data manually.

Check MySQL Status

systemctl status mysql
# or
systemctl status mariadb

Connect as root (no password, often)

mysql -u root

List Databases

SHOW DATABASES;

Dump a Specific Database

mysqldump -u root mydb > mydb.sql

Dump All with Privileges

mysqldump -u root --all-databases --add-drop-database > full-dump.sql

If you've forgotten the root password, you can reset it by stopping MySQL, starting it with --skip-grant-tables, and then updating the root password entry.

Mail Data Extraction: Maildir vs. Mbox

Mail format matters for migration compatibility.

Maildir Format (Modern Standard)

Maildir stores each email as an individual file. Location: /home/username/mail/. Structure:

mail/
├── new/          # Newly received, unread
├── cur/          # Read, processed
└── tmp/          # Temporary (usually empty)

Extraction: Simply tar the entire mail/ directory. It's portable across almost all panels and mail servers.

tar -czf john-maildir.tar.gz /home/john/mail/

Mbox Format (Legacy)

Mbox stores all emails in a single file per mailbox. Rarely used on modern cPanel installs.

cp /var/spool/mail/john /backup/john.mbox

Converting Mbox to Maildir: Most modern panels expect Maildir. Tools like mb2md.pl can convert:

perl mb2md.pl -s /var/spool/mail/john -d /backup/john-maildir/

DNS Records: Zone Files Persist

Your DNS zones are stored as plain-text Bind format files:

cat /var/named/zone.db.example.com

Contents look like:

$TTL 14400
@   IN SOA ns1.example.com. admin.example.com. (
            2026042801 ; Serial
            14400      ; Refresh
            3600       ; Retry
            604800     ; Expire
            3600 )     ; Minimum TTL
    IN NS  ns1.example.com.
    IN NS  ns2.example.com.
    IN A   203.0.113.1

www IN  A   203.0.113.1
mail IN A   203.0.113.2
ftp  IN CNAME example.com.

Export all zones:

tar -czf all-dns-zones.tar.gz /var/named/*.db

Most modern panels (DirectAdmin, Plesk, HestiaCP) can import these directly or with minimal reformatting.

SSL Certificates: Location and Format

cPanel stores SSL certs in multiple places. The canonical location is:

/home/username/.ssl/

Or:

/var/cpanel/ssl/

A complete SSL bundle includes:

  • Certificate (.crt): The public cert
  • Private Key (.key): Keep secret; needed for decryption
  • CA Bundle (.cab): Intermediate certs from the issuer
  • CSR (.csr): Certificate Signing Request (for renewal)

Extract all:

tar -czf user-ssl-certs.tar.gz /home/username/.ssl/

Verify a cert:

openssl x509 -in /home/username/.ssl/example.com.crt -text -noout

Most control panels accept standard PEM-format certs, so you can usually copy-paste or import them directly.

License Downgrade vs. Full Cancellation

These are different actions with different outcomes:

License Downgrade

  • Reduces features (e.g., from Pro to Solo)
  • Keeps the license active
  • cPanel/WHM continues running with reduced functionality
  • Full data access remains
  • You can still create accounts (up to the tier limit)
  • Best practice: Downgrade instead of canceling if you're keeping the server running.

Full Cancellation

  • License terminates completely
  • No WHM access after expiration
  • No automatic updates
  • Software stops responding to license checks
  • Data remains, but you lose the management interface
  • When to do it: Only if you're migrating away or decommissioning the server entirely.

Data Export Best Practices Before Canceling

The golden rule: Always export before you cancel. Once the license expires, manual extraction is messy. Here's the checklist:

Two Weeks Before Cancellation

  1. Verify you have current backups of all accounts (use WHM Backup module or cPanel's Account Backup).
  2. Download all cpaccount tarballs to safe storage:
    # In WHM, navigate to Backup > Full Backup
    # Or SSH: /home/cpsrvd/cpsrvd_backup_XXXX/cpaccount-*.tar.gz
    
  3. Test restore one account to another test server to confirm tarballs work.
  4. Export DNS zones as Bind-format files.
  5. Dump all MySQL databases:
    mysqldump --all-databases > all-databases-$(date +%Y%m%d).sql
    
  6. Verify SSL cert details (expiry dates, domains covered):
    openssl x509 -in cert.crt -text -noout | grep -A 2 "Subject Alternative Name"
    
  7. Document account metadata (quotas, feature limits, contact info) by exporting from WHM or noting manually.

One Week Before Cancellation

  1. Schedule any final data syncs if you're doing live migration.
  2. Notify all users that service will change or move.
  3. Store backups in multiple locations (local NAS, cloud storage like S3, encrypted USB).

After Cancellation

  1. Only then proceed with license termination.

Migrating Data Into Other Panels

You've extracted your data. Now where does it go? Here's how to import into popular alternatives:

DirectAdmin

DirectAdmin has a native cPanel import tool. If you have cpaccount tarballs:

  1. Copy the tarball to the DirectAdmin server:
    scp cpaccount-john.tar.gz root@newserver:/home/
    
  2. In DirectAdmin admin panel: Manage User → Import cPanel Backup
  3. Select the tarball; DirectAdmin auto-extracts and recreates the account.
  4. Verify DNS zones, email, databases, and website files.

DirectAdmin Import Advantages:

  • Native support for cpaccount format
  • Recreates account structure automatically
  • Handles UID/GID mapping
  • Imports MySQL databases into its own system

Plesk

Plesk has Plesk Migrator, which can consume cpaccount tarballs (with caveats).

  1. Install Plesk Migrator:
    /opt/psa/bin/pmm-ras --init
    
  2. Use the Plesk UI or CLI to point to your cpaccount files.
  3. Plesk reads the tarball and maps accounts to its own structure.
  4. Manual adjustments often needed for DNS, mail routing, and SSL.

Plesk Caveats:

  • Doesn't always interpret cPanel metadata perfectly
  • Domains may need re-pointing to new IPs
  • SSL certs import cleanly; mail servers need reconfiguration

HestiaCP

HestiaCP is open-source and budget-friendly. It lacks a native cPanel importer, but community tools exist:

  1. Extract cpaccount tarballs manually.
  2. Use a community script (e.g., cPanel2Hestia on GitHub).
  3. Recreate accounts via HestiaCP's API:
    v-add-user john john@example.com 'password' "John Doe" default
    
  4. Import domains, DNS, mail, databases individually via API or panel.

HestiaCP Notes:

  • Smaller team; less hand-holding
  • Highly scriptable (good for bulk imports)
  • Active community support on GitHub
  • Works well if you're comfortable with the Linux CLI

Other Panels (cPanel to cPanel)

If you're simply moving to a different cPanel server:

  1. Use WHM's account transfer feature (if both licenses are active).
  2. Or import the cpaccount tarball via Home → Backup → Restore an Account.

Seamless if both servers are cPanel/WHM.

Manual Import (Generic Approach)

If your destination panel has no importer:

  1. Recreate account structure:
    useradd -d /home/john -m john
    
  2. Copy home directory:
    tar -xzf cpaccount-john-homedir.tar.gz -C /home/
    chown -R john:john /home/john/
    
  3. Import databases via SQL dumps:
    mysql < cpaccount-john-databases.sql
    
  4. Import mail (if Maildir):
    tar -xzf cpaccount-john-maildir.tar.gz -C /home/john/
    chown -R john:john /home/john/mail/
    
  5. Copy DNS zone files to your new DNS server's zone directory.
  6. Import SSL certs via your panel's certificate manager.

This is labor-intensive but gives you full control.

Risk Mitigation for Orphaned Data

Extracting and migrating data manually introduces risks. Here's how to avoid common pitfalls:

UID/GID Mismatch

Problem: User account john might have UID 1001 on the old server and UID 1234 on the new one. File ownership breaks; web server can't read files.

Solution:

  • Before copying files, check UIDs on both servers:
    id john  # Old server
    id john  # New server
    
  • If they differ, either:
    • Recreate the account with the same UID on the new server, or
    • Use chown -R newuid:newgid /home/john/ to fix after copying.

MySQL Grant Mismatches

Problem: A database user dbuser@localhost doesn't exist on the new server, so connections fail.

Solution:

  • Export grants from the old server:
    mysqldump -u root mysql --tables user db host tables_priv columns_priv > mysql-grants.sql
    
  • Import into the new server:
    mysql -u root < mysql-grants.sql
    
  • Verify by connecting as the migrated user:
    mysql -u dbuser -p -e "SHOW DATABASES;"
    

Mail Format Incompatibilities

Problem: Old server uses mbox; new panel expects Maildir.

Solution:

  • Convert before migration (see earlier section).
  • Test email access on both IMAP and POP3 post-migration.
  • Check for mail loss or corruption in a test account first.

SSL Certificate Chain Breaks

Problem: You import the cert but not the CA bundle; browsers show warnings.

Solution:

  • Always export cert, key, and CA bundle together.
  • Verify chain integrity:
    openssl verify -CAfile cabundle.crt certificate.crt
    
  • If warnings persist, regenerate the cert with the full chain.

Forgotten Cron Jobs

Problem: Backup scripts, renewal tasks, or maintenance jobs stop running post-migration.

Solution:

  • List cron jobs before migration:
    crontab -l
    
  • Export and reimport:
    crontab -l > john-crontab.txt
    # On new server:
    crontab -i john-crontab.txt
    

DNS Propagation Delays

Problem: You import DNS zones, but old DNS servers still point to the old IP. Traffic splits.

Solution:

  • Lower TTL values on the old server 24 hours before migration.
  • Once ready, update DNS to the new IP.
  • Allow TTL window (typically 24-48 hours) for full propagation.
  • Monitor WHOIS and DNS checkers (dig, nslookup) to confirm.

Common Operator Mistakes When Canceling cPanel

Mistake #1: Canceling Without Backups

You assume cPanel has auto-backed everything up. It hasn't. You lose years of data.

Fix: Always run a full export before canceling. Use multiple backup copies.

Mistake #2: Ignoring License Expiry Warnings

cPanel sends you emails as expiry approaches. You delete them. License expires mid-support ticket.

Fix: Set calendar reminders 6 weeks out. Plan the migration in advance.

Mistake #3: Assuming Data Is Encrypted or Locked

Some operators think canceling a license "locks" the data for security. It doesn't. Data is wide open on disk.

Fix: Understand that the license is only for software access. Protect data via standard Linux permissions and encrypted backups.

Mistake #4: Migrating Without Testing

You export everything, import into the new panel, and only then discover mail isn't working or databases are corrupt.

Fix: Always test restore on a staging server first. Verify account by account before switching production.

Mistake #5: Keeping All Backups on the Same Server

You back everything up to /backup/ on the same cPanel server. Server dies; backups die with it.

Fix: Move backups off the server immediately. Use cloud storage, NAS, or a second server in a different location.

Mistake #6: Deleting Old Data Too Quickly

30 days after migration, you delete the old server. A user finds a file they need from 60 days ago.

Fix: Keep the old server running (or fully archived) for at least 90 days post-migration.

Mistake #7: Forgetting to Update DNS

You move the website to a new server but forget to update the DNS A record. Traffic still goes to the old IP.

Fix: Update DNS after confirming the new server is ready. Test with nslookup and curl.

Mistake #8: Losing SSL Private Keys

You export the public cert but misplace the private key (.key file). You can't use the certificate without it.

Fix: Always export and test cert+key pairs together. Store keys in an encrypted vault, not plaintext.

Frequently Asked Questions

Q: Can I cancel the license and still run the panel?

A: No. Without a valid license, cPanel/WHM daemons stop responding. The panel becomes inaccessible. However, the underlying services (Apache, Nginx, MySQL, Postfix, Dovecot, etc.) continue running. You can manage them directly via SSH and CLI tools.

Q: How long does data persist after cancellation?

A: Indefinitely, until you delete it or the hard drive fails. The filesystem has no "expiry" tied to the license. Your data is safe unless you actively remove it.

Q: Can I get the data back if I restart the license?

A: Yes. If you renew the cPanel license, the panel restarts, and all your data is accessible again through WHM/cPanel. No data is lost during a license pause.

Q: What if the server is in a remote data center and I have no SSH access?

A: Contact your hosting provider. You'll need either:

  • SSH terminal access, or
  • A pre-made backup downloaded while the license was active, or
  • The hosting provider to extract and ship the data to you.

Without SSH or backups, you're stuck.

Q: Do addon domains, subdomains, and parked domains get backed up?

A: Yes. All of them live under /home/username/ and are included in account backups and tarball exports. No special handling needed.

Q: What about DKIM, SPF, and DMARC records?

A: These are DNS records. They're stored in /var/named/zone.db.yourdomain.com and are included in DNS zone exports. They'll migrate with your DNS zones.

Q: Can I migrate just one account, not the whole server?

A: Absolutely. Extract just that account's cpaccount tarball and import it alone. Useful if you're consolidating multiple servers.

Q: Is there a way to migrate without downtime?

A: Yes, but it's complex. You'd set up the new panel, slowly migrate accounts while keeping the old server live, and use DNS weighting or a load balancer to split traffic. Most small ops just accept a short maintenance window (2-4 hours) instead.

Q: Will imported databases work immediately on the new panel?

A: If the new panel uses MySQL/MariaDB (most do), yes. If it uses PostgreSQL or a different database engine, you may need to convert or re-dump data into the new format.

Q: What's the difference between a backup and an export?

A: A backup is a point-in-time snapshot meant to restore the entire system. An export is a selective extract (specific account, database, or file set) meant for migration or archival. You'll do both.

Q: Can Adminbolt import cPanel data?

A: Adminbolt is a modern alternative panel. It can consume account data via standard formats (SQL dumps, Maildir folders, DNS zones) and can often directly import cpaccount tarballs or reconstruct accounts from exported components. Contact Adminbolt support for migration tooling specific to your setup.

Conclusion

Canceling a cPanel license doesn't erase your data-it just removes your management interface. Your files, databases, email, and DNS zones remain on the disk, safe and accessible via SSH and command-line tools. The key is planning ahead: export everything before you cancel, test restores on a staging environment, migrate methodically, and keep the old server online as a fallback for at least 90 days.

Whether you're moving to DirectAdmin, Plesk, HestiaCP, or another panel, the process is similar: tarball your accounts, dump your databases, export your DNS zones, and re-import them on the new platform. Automation tools like DirectAdmin's native importer or Plesk Migrator can streamline the work, but understanding the underlying filesystem and file formats ensures you never lose a file or miss a critical config.

Plan early, back up redundantly, test thoroughly, and you'll breeze through the transition. Rush it, and you'll spend weeks recovering from preventable mistakes. Choose wisely.


References & Further Reading


Last updated: April 2026

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.