cPanel Price Increases: Your Real Options in 2026

Every time cPanel adjusts its pricing, my inbox fills with the same message: “what do we do now?” The panic is understandable and the reaction is usually wrong. People either migrate everything in a weekend and spend six months fixing what broke, or they do nothing and absorb the cost until the margin on their shared plans quietly goes to zero.

I am deliberately not quoting figures. cPanel’s pricing has changed several times and anything I write will be stale before you read it, so check the current numbers on cPanel’s own pricing page, against your real account count rather than your plan name. The structure does not change, and the structure is what should drive the decision.

The structural problem

cPanel licensing is tiered by account count: an entry tier for a handful of accounts, then tiers above it that charge per account as you grow. Your licence cost tracks how many cPanel accounts exist on the server, not how much revenue they produce.

That is fine if you sell VPS or dedicated hosting, where each server holds a few high-value accounts. It is brutal if you sell shared hosting, whose whole model is packing a lot of low-margin accounts onto one machine. The per-account cost lands hardest where the per-account revenue is smallest.

Work out your own number first: licence cost divided by billable accounts on that server, against average monthly revenue per account. If the licence is a rounding error, stop reading. If it is double digits as a percentage of plan price, keep going.

Option A: stay on cPanel and reduce the pressure

The cheapest migration is the one you do not do.

Start by auditing for dead accounts. Every shared server I have looked at carries suspended accounts nobody cancelled, staging copies of live sites and internal test accounts. All of them count towards the tier.

# Every account, with suspension state and last login
for u in $(ls -1 /var/cpanel/users); do
  susp="active"
  [ -f "/var/cpanel/suspended/$u" ] && susp="SUSPENDED"
  printf '%-18s %-10s %s\n' "$u" "$susp" \
    "$(lastlog -u "$u" 2>/dev/null | tail -1 | awk '{print $4,$5,$6,$9}')"
done | sort -k2

Cross-check that against WHMCS for accounts with no active billing relationship. Terminating twenty zombie accounts can drop you a tier.

Consolidate next, and right-size the tier while you are there. Two half-empty servers each carrying a licence cost more than one properly sized server, though consolidating raises your blast radius, so only do it where you have tested restores. Tiers are stepped: sit three accounts over a boundary and moving those three elsewhere beats paying for the next tier all year.

Then ask whether every server needs cPanel at all. Your build server, your staging box, the VPS running one Laravel app for one client: none of those need a panel. That is the biggest saving most people overlook.

If you stay, make the servers earn their keep. A tuned cPanel box safely holds more accounts than a default one, and density decides whether the licence maths works. The walkthrough in securing a fresh cPanel server covers the tuning that gets you there.

Option B: move to DirectAdmin

DirectAdmin is the closest structural match to cPanel and the most common destination I migrate people to. Its tiers are far friendlier at high account counts, which is where cPanel hurts most. You also get a panel that uses less RAM and CPU, CustomBuild for compiling your own stack, and a reseller/user hierarchy close enough that your support team retrains in a day.

What you lose, honestly:

• Softaculous, Installatron, JetBackup, LiteSpeed and WHMCS all support DirectAdmin, but the long tail of niche plugins and tutorials is written for cPanel. Customers search “how do I do X in cPanel” and land on instructions that do not match.
• The Evolution skin is capable but different. Expect a month of tickets.
• A few cPanel-specific features have no exact analogue, so audit anything unusual you rely on before you commit.

The migration gotchas are specific, and they are why DirectAdmin moves get a bad reputation from people who tried once, unprepared:

• The cPanel importer renames every database to a username_ prefix. Your wp-config.php is now wrong, and so is anything else still referencing the old name. On a server with hundreds of WordPress sites that is a scripted find-and-replace.
• The archive must be named cpmove-<user>.tar.gz. A backup-*.tar.gz file is not recognised as a cPanel move file, and the failure looks like the importer ignoring you.
• A missing or 0 MAXADDON value in /var/cpanel/users/<user> (and in the archive’s copy at cp/<user>) silently skips addon domain creation on restore. No error appears. The addon domains are just not there, and you find out when a customer calls.
• Dovecot mdbox mailboxes have to be converted to maildir before the cPanel export, via doveadm sync/dsync, or the mail does not come across usefully.

The first three are covered in cPanel to DirectAdmin migration gotchas, and the addon domain trap has its own writeup.

Option C: move to Plesk

Plesk is what people reach for when Windows is in the picture, or when the client base is more agency than shared hosting.

Strengths: genuine Windows Server support, which nobody else here offers seriously, a cleaner developer story with Git integration and per-site Node/Python/PHP versions, and a UI non-technical clients tend to find friendlier. The WordPress Toolkit is good.

Weaknesses: Plesk’s own licensing is also tiered, by domain count, so if your problem is “too many accounts” Plesk may not solve it. Resource usage is higher than DirectAdmin. And the Plesk Migrator, the tool you will use to pull accounts in, has failure modes worth knowing before you schedule the work: MySQL over sockets rather than TCP, SSH key authentication, MariaDB 11.4 compatibility. Those are written up in Plesk Migrator failures.

Plesk is the right call for a Windows requirement or an agency workflow. It is rarely the right call purely as a cost play for a shared hosting operator.

Option D: drop the panel entirely

Two shapes here. Free panels such as CyberPanel and CloudPanel give you a web UI, site provisioning, Let’s Encrypt and backups at zero licence cost. Or plain LEMP with a control layer: Ansible for provisioning, Certbot for certificates, restic or Borg for backups, Netdata for monitoring.

Right for anyone running a small number of applications they control, for teams with a real sysadmin and their configuration in version control, and for agencies who deploy from Git and never let clients near the server.

Wrong for, and I say this every month:

• Resellers, above all. Your product is a per-client control panel. Take it away and you no longer have a product. Customers need to add a mailbox at 11pm without opening a ticket.
• Teams with no sysadmin capacity. Everything the panel did (mail, DNS, certificate renewal, backups, PHP versions, quotas) is still work. You have not removed it, you have moved it onto someone. If that someone does not exist, you have scheduled an outage.
• Anyone whose billing automation depends on the panel. WHMCS provisioning modules for the free panels are thinner than the cPanel and DirectAdmin ones.

Self-hosting mail also means owning deliverability: SPF, DKIM, DMARC, PTR records, blocklist monitoring. Most people dropping a panel should move mail to a dedicated provider.

Decision table

Your situation	What I would do
A handful of accounts, licence is a rounding error	Stay on cPanel. Audit for dead accounts and move on.
Shared hosting, hundreds of low-value accounts, margin gone	Move to DirectAdmin. Closest match, best per-account cost.
VPS/dedicated provider, few high-value accounts per server	Stay on cPanel. Customers expect it and the cost is proportionate.
Windows sites in the mix, or an agency client base	Plesk. The only serious Windows answer here.
Single application server, one tenant, no client logins	Drop the panel. CloudPanel or plain LEMP.
Internal or build boxes carrying a cPanel licence	Remove the licence today. Easiest saving available.
Reseller business, or no sysadmin on the team	Keep a panel. Panel-free costs more in incidents than it saves.

If you decide to move

Do not migrate everything at once. Move one server, run it for a month, and count the support tickets. That number is your real migration cost, and nobody estimates it. Better still, put every new signup on the new panel while existing customers stay put, so the old server’s account count falls through churn. And confirm you have root SSH on the source before you promise a date: WHM’s Transfer Tool requires it, and without it you are down to per-account cpmove archives.

FAQ

Is DirectAdmin actually cheaper, or does it just look cheaper?

At high account counts, genuinely cheaper, because the tiering is far less aggressive per account. On a server with few accounts the difference will not cover the migration effort. Do the arithmetic on your real account counts.

Will my customers notice if I switch panels?

Yes. The interface changes, and any tutorial or plugin that assumes cPanel will not match. Budget for a ticket spike, write short guides for the five things customers actually do, and tell them beforehand.

Should I just move everything to a cloud platform instead?

Only if you are also solving mail separately. Application platforms manage the web stack and generally do not host email at all, which is a bigger change than a panel switch. That trap is covered in what happens to your email on RunCloud or Cloudways.

Where this fits

Picking the destination is the easy half. The hard half is moving hundreds of accounts without losing addon domains, mail or database connections, which is exactly the cross-panel migration work I do. If you would rather stay put and squeeze more out of the servers you have, server management covers the tuning side.