cPanel to Plesk Transfer Checklist for Hosting Customers

Start with the parts that break first

A cPanel to Plesk transfer checklist is really about keeping the site, mail, and DNS in sync while you move. Miss one piece, and the site may load while email fails or SSL stops matching the new server.

For most customers, the safest path is simple: prepare the destination first, then move data in stages. If you want a host-managed starting point, a Hostperl VPS gives you a clean target for testing before you switch live traffic.

This guide follows the way support teams usually handle transfers: inventory, copy, verify, cut over, then check for the small failures that turn into tickets.

What to confirm before you move anything

Before you open both panels, write down the basics for every site on the account. You need the domain list, PHP versions, database names, email accounts, cron jobs, and any SSL certificates already in use.

That inventory matters because cPanel and Plesk store some settings differently. A WordPress site may move cleanly while a custom PHP app breaks because the runtime version changed or the document root was mapped differently.

• List each domain and subdomain.
• Note the current PHP version for each site.
• Export or save database credentials.
• Record mailboxes, forwarders, and autoresponders.
• Check whether DNS is hosted at the registrar, Cloudflare, or the server.

If mail is part of the migration, compare it with our guide on email hosting on shared plans. The same checks help on larger accounts too, especially if you rely on IMAP folders or aliases.

Build the destination in Plesk first

Create the subscription or domain entry in Plesk before you copy files. Match the domain name exactly, choose the correct PHP handler, and turn on SSL support right away. If the old server used a different PHP release, install that version in Plesk so you can test without changing the app.

For a typical WordPress or PHP site, set the right document root and check file ownership after the upload. Plesk is strict about subscriptions, and that helps. It keeps one site from borrowing another site's permissions.

If you are still deciding which control panel fits the way you work, Hostperl's comparison of cPanel, Plesk, or DirectAdmin explains the operational differences in plain language.

Move files and databases in a controlled order

Move the website files first, then the databases, then the application config. That order makes troubleshooting easier because you can test the filesystem before you introduce database errors.

For a WordPress site, copy the wp-content directory, then import the database, then update wp-config.php with the new database name, user, and password. If you are migrating a custom app, check config files such as .env, config.php, or settings.php for old paths and hostnames.

A quick file check on the source server can save time later:

du -sh /home/USER/public_html
mysqldump -u DBUSER -p DBNAME > backup.sql

On the new server, restore the database and confirm that the application can connect before DNS changes. If you need a cleaner move path, our no-downtime site move guide covers the timing in more detail.

Check email before you switch DNS

Email usually causes more migration trouble than the website itself. Mailboxes can exist on the old server while DNS points somewhere else, which makes messages land in the wrong inbox or fail with authentication errors.

Create the same mailboxes in Plesk, then test IMAP access using the new server hostname before cutover. If you rely on SPF, DKIM, or DMARC, copy those DNS records carefully and keep the old mail server accepting messages until the final switch is done.

For customers who want a simple checklist, our SSL, DNS, and email setup checklist is a useful companion while you work through the transfer.

• Recreate all mailboxes and aliases in Plesk.
• Verify SPF, DKIM, and DMARC records.
• Test webmail login on the new server.
• Keep MX records unchanged until final switchover if needed.

Lower the DNS TTL before cutover

Set the TTL on the domain's A, MX, and related records to a low value a day before the switch. A value between 300 and 600 seconds is usually enough. That does not force every resolver to update instantly, but it does shorten the wait once you point traffic to the new server.

Then update the DNS zone either at the registrar or on the server that hosts DNS. If your DNS is managed elsewhere, make the change there instead of in Plesk. The most common mistake is editing the wrong zone file and assuming the update failed.

When you are unsure whether the domain still needs attention, Hostperl's shared hosting upgrade signals article gives a good benchmark for when a move to VPS or a stronger panel setup is justified.

Validate SSL, redirects, and the live site

Once DNS starts resolving to the new server, test HTTPS first. A valid certificate should match the domain and any common aliases such as www. If the site redirects from http to https, confirm that the redirect chain lands on the right hostname and does not loop.

Then open the main pages, login pages, contact forms, and any checkout flow. For WordPress, log in to the admin area and save permalinks once. That refresh often clears stale routing after a server move.

A simple validation order works well:

1. Open the homepage over HTTPS.
2. Check one deep page and one form.
3. Send and receive a test email.
4. Review error logs in Plesk for fresh entries.
5. Confirm the old server is no longer receiving traffic.

Watch for the common mismatch errors

The same few issues show up again and again during panel transfers. The site loads, but the database user was not updated. Mail works in webmail, but the MX record still points at the old server. The SSL certificate installed correctly, but the domain alias was missed. Each one is small on its own and annoying in combination.

If the application throws a blank page or 500 error after migration, compare the PHP version, extensions, and file ownership between the two panels. If email bounces, check whether the new server's IP reputation is clean and whether the hostname matches the PTR record.

For servers that need stronger mail reliability, our shared hosting vs VPS for email deliverability post explains why some moves are more about reputation than raw resources.

When a VPS makes the transfer easier

Some migrations are more than a panel change. If you are outgrowing shared hosting, or if the source account has too many sites and cron jobs, a VPS gives you a more predictable landing zone. You can match PHP versions, control mail routing, and keep the move isolated from other customers.

Hostperl's VPS vs dedicated servers guide helps if you are deciding whether the new setup should be a self-managed VPS or a dedicated machine. For most small agencies and business owners, a VPS is enough. Dedicated servers make more sense when traffic, mail volume, or storage growth is already steady and measurable.

Final checklist before you close the old account

Keep the old hosting live for a short overlap period. That gives you time to catch delayed DNS updates and any mailbox still pointed at the source server. Once logs are quiet and the site is stable, you can archive the old backups and close the account.

• Confirm the domain resolves to the new server from multiple locations.
• Test all mailboxes with send and receive checks.
• Review logs for 24 hours after cutover.
• Save the old backup set in a separate location.
• Document the new login details for future support requests.

If you are also setting up fresh mailboxes or new sites after the migration, Hostperl's new hosting site setup guide is a useful follow-up.

FAQ

Can I move from cPanel to Plesk without downtime?
Yes, if you lower TTL first, copy the site completely, and keep the old server available until DNS settles.

What should I test first after migration?
Test HTTPS, the homepage, one contact form, and email login. Those four checks catch most transfer problems quickly.

Do I need to move DNS at the same time?
Not always. You can keep DNS at the registrar or current provider and only change the A and MX records.

Why does email break even when the site works?
Mail uses different records and services than the website. SPF, DKIM, MX, and mailbox creation all need to match the new server.

Should I choose VPS or dedicated for a migration?
Choose VPS for most small to mid-size sites. Pick dedicated when traffic, mail load, or storage needs are already high and stable.