Migration Center
Migrate from cPanel, one account at a time.
Migration Center moves accounts from a live cPanel/WHM server to a PlusPanel server: sites, databases, email and DNS. Your cPanel server keeps serving until each domain's cutover, and nothing on it is changed or deleted. Free in every edition, Free included.
Live: Migration Center passed its drill on real infrastructure on 2026-10-26, a cPanel & WHM server with seven accounts moved to our demo server (182 checks passed).
Three rules it never breaks
Your cPanel server stays untouched
Every operation on the source is read-only. Nothing is written there and nothing is ever deleted, rollback and cleanup included. The one exception is opt-in: if you allow it, the source's own DNS zone is edited at cutover and reverted at rollback.
Data goes server to server
Your new PlusPanel server pulls files, databases and mail directly from the cPanel server. Our control plane orchestrates and keeps the reports and check results; it never carries a file, a database or a message.
Free, in every edition
Migration Center is free and unlimited in Free, Pro and Enterprise. The accounts it creates count toward your edition and plan like any other, and the pre-flight report tells you up front when one does not fit.
Three ways in
Pick the access the source owner is comfortable with. Credentials are kept encrypted in your organization's vault, sealed for the destination server for each job, never logged, and destroyed when the migration ends.
WHM API token (recommended)
A token created in WHM. Files, databases and mail are read through the WHM and cPanel APIs; database dumps are generated on the fly, so no file is written on the source.
Root SSH
Key (preferred) or password. Only read-only commands run, each one built from a closed list, never free-form shell: files over SFTP, databases with a consistent mysqldump.
cpmove archives
A cPanel full backup (cpmove-<user>.tar.gz) made by the source owner, given as an HTTPS link or an S3 presigned link, or uploaded from your browser straight to object storage. The source is not contacted at all.
Confirm the source before anything is read
The first probe shows the SSH host key or the WHM certificate fingerprint. You compare it with the one the source owner reads on the server and confirm it; only then does the migration go on. No trust on first use: a fingerprint that changes later stops every step.
How an account moves
A migration is one source, one destination server and the accounts you pick, in waves: a few accounts first, then the rest. Account by account is a migration with one account. Each wave starts when the previous one is done, runs a set number of accounts in parallel (2 by default), can be held to maintenance windows, and pauses on the first failure.
- 01Connect and confirm. Add the source, confirm its fingerprint, and pick the accounts from the list the probe returns.
- 02Pre-flight report. Each account is analysed: sizes, PHP version and extensions, databases, mailboxes, DNS, a time estimate, whether it fits your plan and edition, and the list of what will not be migrated. Download it as Markdown or PDF. It is the contract: anything it does not list as migrated is not.
- 03Pre-sync. The account, its sites, databases, mailboxes, DNS zones and cron jobs are created on the new server, then files, databases and mail are copied while the source keeps serving. Run it again whenever you like: each run moves only what changed. Bandwidth is capped (40 MiB/s by default, adjustable) to leave the source's customers headroom.
- 04Verify. Pages are compared (status, title, size), along with table row counts, file counts, bytes and sampled checksums, and message counts per mailbox. A red check blocks the cutover; an amber one must be acknowledged with a reason. Test the sites yourself before DNS changes, with the hosts-file line shown on the account page (or a preview address, where one is configured). You are notified when the account is ready for cutover.
- 05Cutover, per domain. In a maintenance window or when you click: a final delta sync, the TLS certificates, the DNS switch for each domain and a last mail sync, then the same checks again plus a test message in and out.
- 06Mail catch-up. Messages that still reach the old server while DNS propagates are copied over during the 48 hours after the cutover.
- 07Rollback for 14 days. One action points DNS back to the source, which kept serving all along: the records in the PlusPanel zone are flipped back, the source zone is reverted (if you allowed edits), or you get the exact records to change at your DNS provider. The PlusPanel account stays until you remove it; mail delivered to it after the cutover stays there, and the account page tells you how many messages.
- 08Clean finish. When the rollback window closes the account is finalized; when the last one is, the migration completes and the source credentials are destroyed. Revoke the WHM token or the SSH key on the source, and decommission the old server when you are ready. PlusPanel never deletes anything there.
Three ways to switch DNS
Chosen per domain. Propagation is watched until the domain's authoritative servers and three public resolvers answer with the new addresses.
PlusPanel nameservers (recommended)
The zone is prepared on PlusPanel's DNS with the records already pointing to the new server. At cutover you change the nameservers at your registrar; we show the instructions and watch the delegation.
External DNS
DNS stays where it is. You get the exact records to change; lower their TTL to 300 seconds a day before.
The source's DNS (opt-in)
If the cPanel server also hosts the domain's DNS and you explicitly allow it, the source zone's TTLs are lowered to 300 seconds during pre-sync, the records are switched at cutover and reverted at rollback. It is the only change Migration Center can make on the source: off by default and recorded in the audit log.
What moves, and where it lands
| On cPanel | On PlusPanel |
|---|---|
| Account (user, main domain, disk usage) | An account on the plan you choose; the quota proposed is the source usage + 20% |
| Main, addon and subdomain document roots | One PHP site each, with its files and permissions; parked and www. names become aliases; old absolute paths (/home/<user>/public_html) keep working |
| MySQL/MariaDB databases, users and grants | A MariaDB service for the account with the same database and user names, password hashes kept; DB_HOST=localhost keeps working |
| PHP version and extensions | Apache with PHP-FPM, .htaccess kept; versions below 8.1 move to 8.1 with a warning, missing extensions listed |
| .htaccess, php.ini, .user.ini | Kept; cPanel handler blocks removed, php_value/php_flag moved to .user.ini, unsupported directives listed |
| Cron jobs | Account cron jobs running in the site's container; @reboot entries and commands outside the migrated paths listed |
| SSL certificates | The current certificate imported so HTTPS works before the cutover; AutoSSL/Let's Encrypt ones switch to automatic renewal afterwards, commercial ones stay as imported |
| Mail domains and mailboxes | Same quotas; passwords kept, because cPanel's SHA-512-crypt hashes are imported as they are |
| Forwarders and autoresponders | Aliases, forwards and autoresponders |
| Mail (maildir) | Imported, then kept in sync with incremental deltas until the cutover and for 48 hours after |
| DNS zones | PlusPanel DNS zones with the records mapped to the new server; DKIM replaced by the new mail domain's key |
| Main FTP login | The account's SFTP user, if you select it, with a new password |
| Redirects, hotlink protection, IP blocks | Kept: they live in .htaccess |
What is not migrated
Listed per account in every pre-flight report, so nothing disappears silently:
- Ruby, Node.js and Python (Passenger) applications
- PostgreSQL databases
- Mailman mailing lists
- Additional FTP accounts
- Email filters and spam settings
- Web Disk
- cPanel API tokens
- AWStats and raw access logs
- Softaculous metadata
- Directory-privacy password files outside the document roots
- Files outside every document root (listed with their size)
- MySQL users with caching_sha2_password or other non-native hashes: they get a new password, written into wp-config.php for WordPress sites and listed otherwise
Known limits
- FTP and SFTP passwords are not carried over: the main FTP login becomes an SFTP user with a new password. Mailbox and database passwords are kept.
- Sources at GA: cPanel/WHM, live or from cpmove archives. Plesk and DirectAdmin come later.
- PHP below 8.1 is not offered: those sites move to PHP 8.1, and the pre-flight report warns you first.
Migration questions
Is my cPanel server modified?
No. Access is read-only, and nothing is written or deleted on it at any step, rollback and cleanup included. The one exception is the source's DNS zone, and only if you explicitly allow it for a migration (it is off by default).
How long does a migration take?
It depends on the amount of data and on the bandwidth between the two servers; each account's pre-flight report gives an estimate. The bulk of the copying happens during pre-sync, while the source keeps serving, so the cutover moves only what changed since the last sync and then waits for DNS to propagate.
Will my customers need new passwords?
Not for email or databases: mailbox and MySQL password hashes are carried over (except MySQL users with non-native hashes, which the report lists). The SFTP login is new: FTP passwords are not carried over.
What if something goes wrong after the cutover?
Roll back within 14 days: DNS points to the source again, and the source kept serving all along. The PlusPanel account is kept until you remove it.
Does migration cost extra?
No. Migration Center is free in every edition, Free included. The accounts it creates count toward your edition's limits, for example the domains and mailboxes of Free.
Can my customers follow their own migration?
If you choose so: a migration can be made visible to each account's client, who then sees the progress of their own account.
PlusPanel vs cPanel: pricing, architecture and a TCO calculator →