Migrating from cPanel to DirectAdmin

This is the most-taken route off cPanel, and it is taken for one reason: the licence stops growing with your customer count. cPanel Premier charges $0.49 per account per month above 100 accounts as of 1 January 2026; DirectAdmin Standard is $29 a month for unlimited accounts, read from directadmin.com on 21 August 2026. At a thousand accounts on one server that is $510.99 against $29.

The saving is easy to calculate. What follows is the part that is not: what actually has to happen, what does not survive the move, and the specific places where a first migration script quietly does the wrong thing.

Provibr supports both panels, and a customer on either pays us the same. We have no reason to talk you into this move, only to make it accurate if you make it.

What a migration actually consists of

Four things, and only the first has good tooling around it.

1. 01The data. Files, databases, mail, DNS zones. This is the part vendors write conversion tools for.
2. 02The identities. Usernames, domains, package names. These have to exist on the destination and they do not always survive unchanged.
3. 03The automation. Whatever provisions, suspends and bills your accounts is pointed at cPanel and has to be pointed somewhere else, usually while both panels are live.
4. 04The support wave. Everything that behaved one way and now behaves another, arriving as tickets over the following fortnight.

We have not run your data migration and we are not going to describe anyone's conversion tooling as though we had tested it. Points two, three and four are ours, because we measured both panels while building integrations against them.

The username rule will rename some of your customers

Both panels enforce a username shape, and they are not the same shape. The cPanel column was measured by creating accounts on WHM 11.136 until it refused; the DirectAdmin column is the rule its own API enforces.

The one that catches people is the minimum. A cPanel account can be one or two characters long; a DirectAdmin account cannot. If you have any of those, and long-lived hosts usually have a handful from the early days, they need a new name, which means the customer needs telling and every reference to the old name needs updating.

And there is a trap on the way out. WHM accepts a username with capitals, creates it in lowercase, and reports success without mentioning the change. So the account you think is called MyClient has been called myclient on the server since the day it was made. Whatever inventory you build for the migration has to be read from the server rather than from your own records, or a portion of it will not match anything.

What your billing system is storing is about to point at nothing

This is the part that gets underestimated, because it is invisible until the cutover.

Your billing system, your provisioning scripts, your monitoring and your support tooling all identify a hosting account by something. On cPanel that something is the username. After the move it is still a username, but if any of them were renamed, the reference is dead, and a dead reference in a dunning run does not throw an error. It suspends nothing.

Before you move a single account, produce one list with three columns: the cPanel username, the DirectAdmin username it will have, and the identifier your billing system holds. If those three do not agree for every row, the migration is not ready, regardless of how the data transfer went.

Five things measured on the two APIs that will break a first script

Everything here came out of writing integrations against running servers, and all five produce wrong results rather than errors.

Both panels report failure with HTTP 200. cPanel returns result: 0 inside a metadata object; DirectAdmin returns error=1 in the body. A script that checks the status code sees success for every failure on both sides of the move. cPanel has a third shape as well: a wrong or missing token comes back as HTTP 403 with a cpanelresult object and no metadata at all, so a parser that only knows metadata cannot tell a bad token from a broken server.

cPanel's "0" disk limit means unlimited, not zero. So do the strings "unlimited" and, for usage, "none". A migration script that reads the source quota as a number and writes it to the destination will create accounts with no disk space at all for every unlimited customer you have, and it will do it without a single warning.

cPanel's contact email can be the literal string "*unknown*". Same for a couple of the mail-rate fields. Copy it across unchecked and you have created accounts whose contact address is a placeholder, which you discover when the first suspension notice goes nowhere.

cPanel's account search is a substring match, not an exact one. Asking for provibrtest1 returned both provibrtest1 and provibrtest12345. If your migration verifies each account after moving it by searching the source panel for its name, you can confirm the wrong account and mark a customer as migrated who was not. Filter exactly on the username yourself.

A cPanel server with no accounts does not return an empty list. It omits the data key entirely. A script that treats a missing key as a failure will report your last, successfully emptied server as an error; a script that treats it as "no answer received" is worse, because on a live server that is the difference between "this account is gone" and "we could not tell".

On the DirectAdmin side there are two more worth knowing. Its usage listing lags creates and deletes by around three seconds, so a verification step that runs immediately after a create sees nothing and concludes the account was not made; use the authoritative account list instead. And the confirmation text for unsuspending an account literally reads "have been suspended", which matters precisely during a cutover, when suspending on one panel and unsuspending on the other are the two halves of every move.

What does not come across

Beyond the data itself:

The quota trap, and why it lands in week one

A cPanel server only enforces disk quotas when the filesystem the accounts live on carries quota support. Without it, WHM accepts the package, accepts the number, and enforces nothing. We measured exactly this on a running WHM 11.136 server: an account moved onto a package with a 2 GB quota kept reporting its limit as unlimited, and the per-account disk figures came back empty. Nothing failed and nothing was refused.

If that is the state of your fleet, every account has effectively been on unlimited disk for as long as that was true, and some of them will have grown well past what you sold them. Move to a panel that does enforce the quota you configured, and they all hit the wall in the same week.

Check this before you plan the migration, not during it. If quotas are not being enforced, you have a decision to make about the accounts that are over (raise them, contact them, or price them), and it is a much better decision to make in advance than in a ticket queue.

Provibr's connection test reports whether quotas are really being enforced on a cPanel server, next to the version and the account counts, which is a cheap way to find out. It is also why the platform reads an account's disk limit from the account rather than from the package: what the account reports is what is in force.

Do it in cohorts, and expect months

The pattern that works is dull and it is the only one that works.

Point new orders at DirectAdmin first. Nothing has to move for this, the destination panel gets exercised under real conditions, and you learn its behaviour on accounts nobody has depended on for years.

Then move the accounts with the worst licence-to-revenue ratio. Your cheapest plans, whose customers care least about the interface.

Then everything else, in batches you can support. A batch size where a bad afternoon is recoverable, which for most hosts is smaller than they first plan.

Keep the old panel until the last account is off it and one full billing cycle has passed. The month after a migration is when the counter resets, the invoices go out and the mismatches show up.

The months in the middle

For that whole stretch you are running two panels. Two logins, two ways of counting what you sold, two places to look when a customer calls, and two sets of automation that have to agree about who is suspended. That period is the actual cost of the move, and it is the reason a lot of hosts decide to migrate and then never start.

Provibr connects both panels to the same account. A cPanel account and a DirectAdmin account appear in the same server list, count towards the same capacity and land on the same monthly invoice, with the same suspend, resume, repackage and delete actions behind them. The agent dials outward from your own network, so neither server needs an inbound port opened and nothing is installed on either. Accounts you did not create through Provibr are left alone until you import them, so a panel that already has four hundred accounts on it becomes something you adopt rather than something you rebuild.

It does not move your data. It removes the reason to postpone moving it.

Read next

• DirectAdmin vs cPanel: the 2026 numbers: the cost curve per account and nine operational differences.
• The 2026 cPanel price increase: the arithmetic per fleet size and the four routes out.
• DirectAdmin setup: login keys, packages, web plans and importing accounts.

cPanel 2026 list prices are from public reporting of the announcement effective 1 January 2026; DirectAdmin prices were read from directadmin.com on 21 August 2026. Every API behaviour described here was measured against running cPanel and DirectAdmin servers while building the Provibr integrations. No claim is made about any vendor's data-conversion tooling, which we have not tested.