Blog ·
ISPConfig migration: what the toolkit covers, and what it leaves you
ISPConfig migration means two different jobs. What the paid Migration Toolkit covers, what it explicitly does not, and the three things no toolkit moves.
By Provibr
"ISPConfig migration" is one phrase for two jobs that have almost nothing in common. One is moving into ISPConfig from another control panel, usually Plesk or cPanel, and usually because of what the licence costs. The other is moving an existing ISPConfig install onto new hardware. This page is mostly about the first, because that is the one with a product attached and the one where people get surprised.
Provibr connects to ISPConfig and to the panels people migrate away from, and a customer on either pays us the same. We have not run your migration and nothing here claims to have tested the toolkit; what is quoted below comes from ISPConfig's own page, with the date it was read.
The Migration Toolkit is a paid product from ISPConfig themselves
This is the first thing to get straight, because a lot of search results talk about it as if it shipped with the panel. It does not.
The ISPConfig Migration Toolkit imports data from ISPConfig 2, ISPConfig 3 through 3.3, Plesk 10 to 12.5, Confixx 3 and, with what it describes as beta support, cPanel, into an ISPConfig 3, 3.1, 3.2 or 3.3 single- or multi-server installation. It is sold at €79 excluding VAT, with a licence valid for one year that may be used on up to ten source servers an unlimited number of times, and that may not be shared.
The toolkit's stated requirements include PHP between 5.3 and 8.3 on the source server with MySQL, SOAP and SSL support, the ioncube loader, and postfix with courier or dovecot on the source. The page also states plainly that the Migration Tool cannot import client templates, although the client limits themselves do get imported.
Two of those details deserve more weight than their position on the page suggests.
"cPanel: beta" is not a small footnote when cPanel is your source. Beta means the vendor is telling you the outcome is less predictable than for Plesk, and the right response is to move one real account first and compare it field by field against the source before you commit to a date.
"cannot import client templates" is the sentence that decides how much manual work the migration is. The limits attached to each client come across; the templates do not, and those are the reusable definitions your product catalogue is made of. You rebuild those on the destination by hand, and then you own the job of keeping every migrated client's limits in step with the template you meant them to be on. That is the same shape as the packages problem in a cPanel-to-DirectAdmin move, and it lands in the same place: your product catalogue is not portable, only its consequences are.
What moves, and what stays yours
| Where it ends up | |
|---|---|
| Website files, databases, mail accounts | Handled by the toolkit, per its own description |
| Account names and passwords | Carried across, with conflict-resolution options |
| Client limits | Imported |
| Client templates | Not imported. Recreate on the destination |
| Your billing system's identifiers | Yours. See below |
| Anything that called the old panel's API | Yours. No equivalent exists by default |
| Monthly bandwidth counters | Reset by the server. The first month reads low on the new panel and high on the old one |
| Why anything currently suspended is suspended | Re-record it |
The three things no toolkit moves
These are the same three on every migration we have looked at, and they are the ones that cost time rather than money.
The identifiers. Your billing system, your provisioning scripts, your monitoring and your support tooling all identify a hosting account by something. If that something changes, the reference is dead, and on a panel switch it usually does change, because the two panels disagree about what an account even is. 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 identifier on the source panel, the identifier it will have on ISPConfig, 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.
The automation. Whatever provisions, suspends and bills your accounts is pointed at the old panel and has to be pointed somewhere else, usually while both are still live. That in-between period is the actual cost of the move: two logins, two ways of counting what you sold, and two sets of automation that have to agree about who is suspended. It is the reason a lot of hosts decide to migrate and then never start.
The support wave. Everything that behaved one way and now behaves another, arriving as tickets over the following fortnight. The largest single source of it is quotas: if the old server was not really enforcing the disk limits you configured, some accounts have grown past what you sold them, and they all hit the wall in the same week. We wrote that up with the measurements in the cPanel to DirectAdmin migration piece, and the mechanism is identical whatever the destination.
Do it in cohorts
The pattern that works is dull, and it is the only one that works.
- Point new orders at ISPConfig first. Nothing has to move for this, the destination 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 counters reset, the invoices go out and the mismatches show up.
Afterwards: running ISPConfig as a product you can sell
The migration ends. Selling on the new panel does not, and ISPConfig has one property that changes the shape of that job.
One ISPConfig install can drive several machines. Web, mail and DNS can live on different servers behind a single panel, and the panel decides which one a site lands on. That is genuinely useful and it means "which server is this account on" is ISPConfig's answer to give, not yours to track. It also means the identity of an account is the domain rather than a handle you picked, the same shape as Plesk and CloudPanel, and different from cPanel and DirectAdmin.
Provibr's ISPConfig integration is live. An agent inside your own network dials outward to us and talks to ISPConfig's remote API, so nothing is installed on the panel and no port faces the internet. Creating, suspending, resuming, repackaging, removing and importing accounts all work, and each account is one web server in your capacity regardless of which machine behind ISPConfig ends up running it. Existing accounts are left alone until you import them, which is what makes a panel that already has hundreds of sites on it something you adopt rather than rebuild.
Two honest notes about it. ISPConfig grants remote users permissions per function, so the credential the agent holds can be limited to exactly the calls we make and nothing beyond them. Take that option: it is one of the better permission models among the panels. And the usage graphs are best-effort by design: disk usage comes from a per-client call and is only populated once the panel's own monitoring job has run, so a fresh account can legitimately report nothing. We show nothing rather than a zero, because on a graph those two look identical and mean opposite things.
Read next
- How to sell web hosting with ISPConfig: what the panel already gives you, and what has to exist above it.
- Migrating from cPanel to DirectAdmin: the quota trap and five measured API traps, in full.
- The 2026 cPanel price increase: the arithmetic that starts most of these migrations.
- cPanel alternatives for hosting providers: the wider field, if ISPConfig is not the obvious destination.
- ISPConfig setup: the remote user, its permissions, the TLS fingerprint and importing accounts.
The Migration Toolkit's supported sources, price, licence terms and stated limitations were read from ispconfig.org on 1 September 2026 and are quoted with their source above. We have not run the toolkit and make no claim about the results of any migration. The behaviour of the ISPConfig remote API was measured while building the Provibr integration.
