# Coming from cPanel

> Two ways to leave cPanel: install CorePanel on a new server and import the accounts across, or transform the cPanel server itself into a CorePanel server in place. What each one costs, what it risks, and how to choose.

Source: https://www.corepanel.net/docs/from-cpanel/
Last updated: 2026-09-03
Part of the CorePanel documentation — https://www.corepanel.net/docs

---

There are two ways to move a cPanel server to CorePanel, and they are genuinely
different operations — not two buttons for the same thing. One copies the accounts onto
a **second machine**; the other converts **the machine you already have**.

![The two routes from cPanel to CorePanel: importing accounts onto a new server, which copies data between two machines and switches DNS, versus transforming the existing server in place, which keeps the same disk, the same IP and the same uids](https://www.corepanel.net/_astro/from-cpanel-routes.COEgyR2u.svg)

Whichever you pick, start the same way: run the
[migration check](https://www.corepanel.net/docs/migration-check) on the cPanel server. It is read-only, takes
seconds, and its inventory and findings are the same ones both routes act on.

## Route 1 — A new server, accounts imported across

**Available today.** You install CorePanel on a **fresh server**, then
[import the accounts](https://www.corepanel.net/docs/cpanel-import) from the live cPanel/WHM over SSH — or from a
staged `cpmove` archive. Each account is recreated natively: files, mail, databases, DNS,
cron and certificates, with the original passwords preserved wherever the hash scheme
allows.

What makes this route comfortable is what it does **not** touch: the cPanel server is
read from and never modified. It keeps serving throughout, so:

- You can import one account, verify it, and leave the rest for another day.
- Backing out is doing nothing at all — the source is still live and still authoritative.
- Imports are idempotent: re-running resumes what is missing instead of duplicating it.

What it costs:

- **A second server**, and both of them running until you are done.
- **Time proportional to the data.** Everything is copied over the network.
- **A new IP**, so the domains have to be repointed. CorePanel can do that per account as
  each import finishes — it logs into the source server, still authoritative at that
  moment, and repoints the A records that pointed at the old address. Domains whose DNS
  lives elsewhere are flagged and left alone for you to change.

Start at [Getting Started](https://www.corepanel.net/docs/getting-started) to stand the new server up, then
[Importing cPanel accounts](https://www.corepanel.net/docs/cpanel-import).

## Route 2 — The same server, transformed in place

**Available today.** The cPanel server *becomes* a CorePanel server. Nothing is copied
anywhere: home directories, Maildirs and the MySQL data directory are adopted where they
already are, with the same uids, on the same disk, behind the same IP address.

That single property is what changes the arithmetic:

- **No second server**, and no bill for running two.
- **No DNS propagation window** — the address does not change, so delegation is untouched.
- **The downtime does not scale with the data.** It is the time it takes to stop one set
  of daemons and start another, whether the server holds 20 GB or 2 TB. On the server we
  timed — 45 accounts, 51 domains — that was **28 seconds**.

What it costs:

- It is **the same machine**, so backing out is a step you run rather than a thing you
  refrain from doing. cPanel is disabled and kept installed for as long as you want the
  way back, and because the data was never copied, mail and database writes made after
  the switch survive a rollback. The reversal gives back a **whole** cPanel — including
  mail, FTP and DNS, whose cPanel packages are reinstalled and whose configuration cPanel
  rebuilds itself — and it stops rather than discard anything created in CorePanel that
  cPanel would have no record of, such as a mailbox added after the switch.
- The server must already run **RHEL 8–10** or a rebuild (AlmaLinux, Rocky). The check
  says so plainly if it does not.

Start with the read-only [migration check](https://www.corepanel.net/docs/migration-check), which inventories the
server, scores it and lists exactly what needs attention — then follow
[Transforming a cPanel server](https://www.corepanel.net/docs/cpanel-transform), a guided command that walks the
whole thing one stage at a time. The tool is in beta; what changed in each release is in
the [Transform changelog](https://www.corepanel.net/docs/transform-changelog), and there is a summary of the whole
route at [CorePanel Transform](https://www.corepanel.net/transform).

## Choosing

| | Route 1 — import onto a new server | Route 2 — transform in place |
|---|---|---|
| **Available** | Now | Now |
| **Servers needed** | Two, briefly | One |
| **Data** | Copied over the network | Adopted where it is, never moved |
| **Downtime** | Per account, as you switch each one over | One window for the whole server — 28 s measured on 45 accounts |
| **Scales with data size** | Yes | No |
| **IP address** | New — domains are repointed | Unchanged |
| **Backing out** | Do nothing; the source never changed | A rollback step, with the window held open — cPanel comes back whole, mail and DNS included |
| **Good when** | You want to move gradually and verify as you go, or the source OS is not supported | The server is large, the IP matters, or a second machine is not worth it |

If you can run a second server, Route 1 is the gentler of the two: nothing about the
source changes, so the worst outcome is a wasted afternoon. Route 2 is the better
operation for a big, busy server — one window, no copying, same address — and it keeps a
way back to cPanel open for as long as you want it. Either way, run the
[check](https://www.corepanel.net/docs/migration-check) first: it costs nothing and it tells you where your server
stands.