Plesk to cPanel Migration Tutorial (2026): Move a Hosting Server Without Losing Domains, Email, or SSL

Nobody switches control panels for fun. It's licensing costs, a reseller's growing client list, or a server refresh that finally forces the issue.

The steps in a Plesk to cPanel migration aren't hard on their own. But skip one and you'll hear about it — a missed DNS zone or an expired SSL cert turns into angry client emails fast.

This tutorial covers a full Plesk to cPanel migration: domain accounts, email, databases, and SSL. You'll move everything to a fresh cPanel/WHM server.

It assumes Plesk Obsidian on the source side and a current WHM build (11.128+) on the destination. Both should run on AlmaLinux 9 or Ubuntu 22.04/24.04.

Why Move From Plesk to cPanel

Plesk and cPanel solve the same problem differently. Plesk has a cleaner interface and native Windows support.

cPanel/WHM wins in reseller hosting. Its account packaging, plugin ecosystem, and familiarity among agencies make it the default choice for that market.

Common reasons admins make the switch:

• Reseller hosting demand — clients expect cPanel, not Plesk
• Consolidating licensing costs across multiple servers
• Standardizing on one panel for support staff training
• Moving from a Windows-based Plesk box to a Linux dedicated server

Building reseller packages on the new panel? Read the WHM account package setup tutorial first. Define your quotas and bandwidth limits before importing accounts, instead of inheriting whatever Plesk happened to have configured.

Step 1: Inventory What's on the Plesk Server

Before touching anything, build a full account inventory. SSH into the Plesk box and run:

plesk bin domain --list
plesk bin subscription --info example.com

Export it to a spreadsheet: domain names, disk usage, mail accounts, database names, and cron jobs per subscription.

Stock WHM has no built-in Plesk import tool. This manual mapping is what saves you from guessing later.

Check PHP versions per domain too:

plesk bin site --info example.com | grep -i php

cPanel handles this through EasyApache/MultiPHP Manager. Its version naming differs slightly from Plesk's PHP handler labels, so write down each domain's version now, while it's easy to find.

Step 2: Provision and Harden the New cPanel Server

Get the destination server running first. A HostMyCode managed VPS with WHM pre-licensed cuts out a chunk of the setup work — cPanel licensing and initial firewall rules come configured already.

Building it yourself instead? Run through the baseline hardening steps in the server hardening tutorial before installing WHM.

Install cPanel/WHM on AlmaLinux 9:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest
sh latest

Expect 20-40 minutes depending on server specs. Once WHM is up, set nameservers, the main IP, and a mail exchanger record before importing a single account.

Step 3: Export Domains and Content From Plesk

Plesk exports individual subscriptions as backup archives:

plesk bin pleskbackup domains-name example.com --output-file=/backups/example_com.tar

Run this for every domain on your list. With 40+ accounts, script the loop instead of doing it by hand:

for d in $(cat domains.txt); do
  plesk bin pleskbackup domains-name $d --output-file=/backups/${d}.tar
done

These archives are Plesk-format and won't restore directly into cPanel. What you actually need is the raw web content, databases, and mail data — not the Plesk metadata wrapper around them.

Extract each archive and pull httpdocs/, database dumps, and mail account lists out separately.

Step 4: Create Matching Accounts in WHM

In WHM, use Create a New Account for each domain, matching the package limits from your spreadsheet. Or automate it from the command line:

/scripts/wwwacct example.com exampleuser SomeStrongPass123 X 5000 500

Here X is the package name, followed by disk (MB) and bandwidth (MB) quotas.

Once the account shells exist, rsync the extracted httpdocs content into the new home directory:

rsync -avz /backups/extracted/example.com/httpdocs/ \
  root@newserver:/home/exampleuser/public_html/

Fix ownership right after — rsync as root leaves files owned by root instead of the cPanel user:

chown -R exampleuser:exampleuser /home/exampleuser/public_html

Step 5: Migrate Databases

Dump each MySQL/MariaDB database from Plesk:

mysqldump -u admin -p example_db > example_db.sql

Create the matching database and user in WHM's MySQL Databases tool, or via CLI:

mysql -e "CREATE DATABASE exampleuser_db;"
mysql -e "CREATE USER 'exampleuser_dbu'@'localhost' IDENTIFIED BY 'NewPass456';"
mysql -e "GRANT ALL ON exampleuser_db.* TO 'exampleuser_dbu'@'localhost';"

Then import:

mysql exampleuser_db < example_db.sql

Update wp-config.php or the equivalent app config with the new database name, user, and password. cPanel prefixes database and user names with the account username by default, and this step gets missed constantly.

Check every site after import, not just the first one.

Step 6: Recreate Email Accounts

Plesk stores mail accounts differently from cPanel's Dovecot/Exim setup. There's no clean export/import path across panels.

Recreate each mailbox through Email Accounts in cPanel, or via API:

uapi Email add_pop email=support domain=example.com password=NewMailPass789 quota=1024

For existing mail history, use IMAP sync tools like imapsync to copy messages directly between old and new mail servers, skipping panel-specific export formats entirely:

imapsync --host1 plesk-server.com --user1 support@example.com --password1 OldPass \
  --host2 newserver.com --user2 support@example.com --password2 NewMailPass789

Run this per mailbox before cutover, then again right before the DNS switch to catch anything sent in between.

Deliverability issues after the move? The email deliverability troubleshooting tutorial covers SPF, DKIM, and DMARC checks specific to a fresh mail server.

Step 7: Reissue SSL Certificates

SSL certs from a Plesk installation don't transfer cleanly. The private keys are stored in Plesk's own format, and cPanel's AutoSSL won't recognize them.

Reissuing via Let's Encrypt once DNS points to the new server is the cleanest path — use AutoSSL or manual certbot.

Not ready to cut DNS over yet but want certs ready in advance? Follow the Let's Encrypt setup guide to issue certs against a temporary hosts file entry, then let AutoSSL take over renewals post-cutover.

Quick check after cutover:

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Step 8: Recreate Cron Jobs

Plesk cron entries live in each subscription's scheduled tasks panel. They don't export with the domain backup archive, so pull them manually:

plesk bin scheduler --list -domain example.com

Add equivalent entries in cPanel's Cron Jobs interface, or directly to the user's crontab:

crontab -u exampleuser -e

WordPress sites usually rely on wp-cron.php triggers here. Setting these up fresh, the cPanel cron job setup tutorial has the exact syntax for WordPress task scheduling without overloading shared hosting limits.

Step 9: DNS Cutover

Lower the TTL on all A records to 300 seconds at least 24 hours before cutover. Once every account, database, and mailbox checks out on the new IP via a hosts file override, update the actual DNS records.

echo "NEW_SERVER_IP example.com" | sudo tee -a /etc/hosts

Test the site through that override first. Confirm forms submit, WooCommerce checkout works, and admin logins succeed before touching the live zone.

For a broader cutover checklist including rollback steps, see the DNS migration tutorial.

Common Pitfalls to Check Before You Call It Done

• Wrong PHP version — set MultiPHP Manager to match what Plesk had per domain, or WordPress plugins break silently
• .htaccess rewrite differences — Plesk's Apache/Nginx directive placement doesn't always translate 1:1 to cPanel's structure
• Missing SPF/DKIM records — regenerate these in WHM's Email Deliverability tool for every domain, don't assume old DNS records still apply
• Orphaned cron jobs — confirm each recreated job actually fires by checking /var/log/cron
• File permission mismatches — run /scripts/fixquotas and recheck public_html ownership across all accounts

Keep the old Plesk server live and untouched for at least 7-10 days after cutover. It's your rollback path if something surfaces that testing missed — a broken contact form, a missing subdomain, an email account nobody remembered to inventory.

FAQ

Can I automate a Plesk to cPanel migration entirely?
Not fully. There's no native cross-panel import tool, so domain content and databases can be scripted, but email accounts, SSL certs, and cron jobs need manual recreation or targeted sync tools like imapsync.

Will my WordPress sites need reconfiguration after migration?
Usually just the database credentials in wp-config.php, plus confirming the PHP version and any server-level rewrite rules match what the site expects.

How long should I keep the old Plesk server running?
At least a week, ideally two. Keep DNS TTLs low during that window so you can roll back fast if something breaks post-cutover.

Do I need to buy new SSL certificates?
No, if you're using Let's Encrypt. Certs reissue for free once DNS points to the new server. Paid certs need re-issuance through the CA with updated CSRs generated on the new box.

What's the biggest reason migrations fail?
Incomplete inventory. Missing a subdomain, a cron job, or a mailbox during planning causes more support tickets than any actual technical migration step.