How to migrate from Plesk to cPanel without losing mail

The reverse direction gets less press, but Plesk-to-cPanel migrations are common enough — hosts standardising a mixed fleet, agencies consolidating onto the panel their developers already know, or a buyout where the acquirer is a cPanel shop. The good news: WHM ships a first-party Transfer Tool that reads Plesk Onyx 17.x and Obsidian 18.x sources directly, no third-party migrator required. The bad news: it covers about 80 % of the work — the remaining 20 % is mail filters, Nginx behaviour, and database privileges that the tool silently drops on the floor.

This guide is the production playbook — the sequence we recommend for moving subscriptions from a live Plesk server onto a fresh cPanel & WHM node with under a minute of downtime per domain. If you haven't fully committed to the move yet, the cPanel vs Plesk in 2026 breakdown covers the licensing and feature trade-offs first.

Before you start

You need:

• A target cPanel & WHM server already provisioned — see installing cPanel on a VPS. The target's cPanel version must be equal to or newer than the source Plesk version's release date; transferring onto an old cPanel build is blocked.
• An active cPanel licence sized for the migrated account count. Activate it on the cPanel licence page before starting — the Transfer Tool refuses to create accounts beyond the licence cap.
• Root SSH on both servers, ideally on the default ports. If your Plesk box uses a non-standard SSH port, you can specify it in the Transfer Tool UI but cannot easily change it mid-run.
• Disk on the target equal to 1.4× the source data footprint. Transfer Tool stages archives in /home before extracting them.
• DNS TTLs lowered to 300 seconds at least 24 hours before any cutover window. This is the cheapest insurance there is and it cannot be applied retroactively.

Step 1 — Map subscriptions to cPanel accounts

Plesk's subscription model isn't identical to cPanel's account model. One subscription typically becomes one cPanel account, but the Transfer Tool needs hints when:

• Multiple subscriptions share a customer. cPanel doesn't have a customer-above-account layer outside resellers. Decide up front whether each subscription becomes its own unrelated account, or whether you'll create a reseller per Plesk customer and put their subscriptions under it.
• Subscriptions own multiple domains. Plesk treats the primary domain as the subscription name; secondary domains are add-ons. cPanel maps this cleanly — the primary becomes the account, secondaries become add-on domains — but if you've used Plesk's "additional services" sites with separate web roots, those don't map and need re-creation manually.
• Reseller plans exist on the source. Plesk resellers transfer as cPanel resellers, but the package definitions get translated by name; verify the resulting cPanel packages before opening the panel to customers.

Generate a subscription list on the source and decide the mapping before you start:

plesk bin subscription --list
plesk bin customer --list

Step 2 — Run the Transfer Tool pre-flight

From the destination WHM, go to Transfers → Transfer Tool, choose Plesk as the source type, and enter the source root credentials. The first scan is read-only — it inventories subscriptions, sizes, PHP versions, databases, and mail accounts, then shows you a report before any data moves.

# Equivalent CLI on the destination
whmapi1 start_transfer_session \
  source_type=plesk \
  source_host=plesk.example.com \
  source_user=root \
  source_authmethod=key \
  source_keypath=/root/.ssh/migration_key

Read every line of the resulting report. Things that always matter:

• PHP versions present on source but missing on target. EasyApache 4 needs every source PHP build installed before migration runs. If Plesk has 7.4, 8.1, and 8.3 serving live sites, install all three on the cPanel target via WHM → Software → EasyApache 4 before pulling accounts over.
• Custom PHP handlers. Plesk uses PHP-FPM per subscription by default; cPanel can match that with PHP-FPM pools but you must enable it per account on the destination — the tool sets the handler to whatever EasyApache's default is, which is usually suphp and will surprise you.
• Databases with non-standard collations. Plesk happily creates utf8mb4_unicode_520_ci databases; older cPanel/MariaDB combinations refuse them. Verify the target MariaDB version supports every collation the report lists.
• SSL certificates issued by Plesk's built-in Let's Encrypt. These transfer as PEM bundles but the renewal mechanism does not — you need to re-issue with AutoSSL on cPanel after cutover, before the original certs expire.

Step 3 — Migrate in batches, not one shot

Don't pull a 500-subscription server in a single Transfer Tool run. Twelve hours of opaque progress and any failure means starting over. Batches of 20-50 subscriptions sorted smallest-first are the right unit: small accounts shake out config issues cheaply, and the big mailboxes go last when the path is proven.

In the Transfer Tool UI, select the subscriptions for this batch, then choose Express Transfer if both servers are on the same LAN — it skips the intermediate archive step and streams data directly. If they're in different datacentres, use the standard mode; Express requires sub-millisecond inter-server latency to be faster.

At this stage DNS still points at the Plesk server. Customers continue hitting Plesk normally. Nothing is cut over until Step 5.

Step 4 — Rebuild what Transfer Tool drops

Three classes of data don't survive the trip cleanly. Fix them on the cPanel side before DNS cutover, while customers are still on the live Plesk box.

Mail filters. Plesk uses Dovecot Sieve scripts; cPanel uses its own filter format backed by Exim. The tool converts simple rules — forwards, autoresponders, "move to folder" — but anything using vacation with custom intervals, pipe to a script, or per-header regex is silently dropped. The pre-flight report flags affected accounts. Open each one in WHM → List Accounts → cPanel and re-create the missing filters by hand.

Nginx-specific configuration. Plesk fronts Apache with Nginx by default and exposes a "Additional nginx directives" field per domain for rate limiting, custom caching, and header rewrites. cPanel runs Apache directly (or LiteSpeed if you've licensed it). Nginx directives don't translate — Apache equivalents need to be written into .htaccess or per-account include files under /etc/apache2/conf.d/userdata/std/2_4/<user>/<domain>/, then loaded with /scripts/rebuildhttpdconf.

Database users with non-standard privileges. Plesk grants every database user the standard CRUD set on the database it owns. If you've manually granted FILE, PROCESS, or cross-database privileges through phpMyAdmin, the tool transfers the user but not the extra grants. Audit critical applications (anything doing LOAD DATA INFILE, anything using federated tables) before flipping DNS.

Step 5 — DNS cutover and final sync

With TTLs already at 300 seconds, update the A and MX records to point at the cPanel server. The order that minimises mail loss:

1. Run a final Transfer Tool sync on the batch to pick up file and mail changes since the initial run. Transfer Tool's incremental mode (--incremental on the CLI, or the "Synchronise account changes" checkbox in the UI) only moves the delta and runs in minutes for most accounts.
2. Update DNS at the registrar or nameservers.
3. Wait for the TTL window to expire — five minutes plus your slowest resolver.
4. Keep Plesk's Postfix listening for 7 days as a catch-all. Set up SMTP forwarding on the source for any mail that still lands there, pointing it at the new cPanel MX.

For domains where you control the authoritative nameservers, switch the nameservers themselves rather than editing records, and pre-stage the cPanel zones via WHM → DNS Functions → Add a DNS Zone so they answer correctly the instant they're queried.

Step 6 — Decommission the source

After two weeks of zero hits in the Plesk access logs and no inbound mail on the source's Postfix, you can decommission. Keep a full Plesk backup for at least 90 days — there is always one customer who discovers a missing file three weeks after cutover, and restoring from a Plesk backup once the source server is gone is genuinely painful.

If you're winding down a Plesk licence mid-cycle, the credit you'll receive depends on your reseller — licence pro-rated billing explains how that math works on our side.

Common gotchas

SSL certificate chain order. Plesk concatenates the leaf, intermediate, and root in a specific order; cPanel's AutoSSL is stricter and rejects bundles where the chain order is wrong. After migration, re-run AutoSSL on every account to regenerate certificates from scratch rather than relying on the transferred bundles.

open_basedir differences. Plesk's default open_basedir is the vhost root plus /tmp. cPanel's default (with mod_ruid2 or PHP-FPM) is the user's home directory. Sites that read files from /var/www/vhosts/<domain>/private/ on Plesk will not find them at the same path on cPanel — file references using absolute Plesk paths need patching.

MariaDB version jumps. Plesk 18.0.55+ ships with MariaDB 10.6 by default; cPanel on AlmaLinux 9 commonly runs MariaDB 10.5 or 10.11. Sites using JSON_TABLE() or SYS_REFCURSOR-style features on the source will need a MariaDB upgrade on the target before they work. Decide the target MariaDB version before migration, not after.

DKIM keys. Plesk generates DKIM selectors named default._domainkey; cPanel uses default._domainkey too, but generates new keys per account on creation. The tool transfers the Plesk public key into the cPanel zone, but the private key needs to be re-imported on the cPanel side or you'll get DKIM signature failures for the first 24-48 hours after cutover. Easier path: let cPanel regenerate keys at account creation, then push new DNS records before flipping the live DNS.

Next steps

• Installing cPanel on a VPS — provision the destination server before starting any migration work
• WHM Transfer Tool deep dive — the same tool used here, covered from the cPanel-to-cPanel angle with more detail on Express Transfer and reseller hierarchy
• cPanel vs Plesk in 2026 — the licensing and feature comparison, if you're moving the rest of your fleet next