How to Move from cPanel to Plesk Without Downtime

Check the migration path before you touch the server

If you want to move from cPanel to Plesk without downtime, start with one question: what actually has to move? Most hosting migrations are bigger than website files. You may also need mailboxes, DNS records, cron jobs, SSL certificates, databases, and the small settings people only remember after launch.

This guide is for hosting customers, agencies, and site owners doing a live move. If you are shifting a site off shared hosting or onto a Hostperl VPS, the safest approach is to prepare the new Plesk server first, test it with a temporary hostname, and switch DNS only after everything looks right. If you need extra room for the transfer, a Hostperl VPS gives you a clean place to stage the move before cutover.

Before you begin, build a checklist for each service:

• Web files: WordPress, custom apps, images, uploads, and hidden files such as .htaccess.
• Databases: MySQL or MariaDB dumps, usernames, and passwords.
• Email: mailboxes, forwarding rules, autoresponders, and DNS records.
• DNS: A, AAAA, MX, TXT, and CNAME records.
• SSL: current certificates, renewal dates, and any wildcard coverage.

If you are still deciding whether the destination should be cPanel, Plesk, or something lighter for client work, Hostperl’s control panel selection guide is a useful read before you schedule the move.

Prepare the new Plesk server first

Do not wait until cutover day to install software. Get the destination server ready while the cPanel site is still live. That gives you time to catch mail and DNS issues without pressure.

On the new server, confirm these basics:

1. Plesk is installed and fully updated.
2. The PHP version matches the site’s needs.
3. MariaDB or MySQL is available at the required version.
4. Webmail, SSL, and mail services are enabled if you are moving email too.
5. Firewall rules allow SSH, HTTP, HTTPS, SMTP, IMAP, and POP3 as needed.

If you are moving from a busy shared account to a VPS, do a quick sizing check first. A small brochure site may run fine on modest resources, but a WooCommerce store, membership site, or client portal needs more memory and CPU headroom. Hostperl’s migration checklist for VPS and dedicated server moves covers the questions that prevent most undersizing mistakes.

Then create the destination subscription or domain in Plesk, but leave public DNS alone for now. For a clean test, use a hosts file entry on your own computer or a temporary subdomain such as staging.example.com.

Export the site from cPanel in a controlled order

The cleanest way to move from cPanel to Plesk without downtime is to transfer in layers. Files first. Database second. Email and DNS last.

In cPanel, package the site data carefully. For WordPress, download the full public_html directory and export the database from phpMyAdmin. For a custom PHP site, copy the application code, configuration files, and uploads directory. Keep a note of file ownership and any custom cron jobs.

Use this order:

1. Back up files through cPanel Backup, File Manager, or an account archive.
2. Export databases with phpMyAdmin or a database dump tool.
3. List email accounts and passwords if mail is moving.
4. Record DNS settings from the zone editor.
5. Capture SSL details if you use a custom certificate.

For WordPress sites, keep the database dump and wp-config.php together. Many migration problems come from a mismatch between the database name, username, and password, not from the move itself.

If you are moving a busy site, read Hostperl’s hosting migration checklist alongside this guide. It helps you plan the order of operations so the final DNS change is the only visible cutover.

Import into Plesk and fix the common mismatches

Once the files are on the Plesk server, place them in the correct document root. Plesk usually uses a path like /var/www/vhosts/example.com/httpdocs. That is different from cPanel’s public_html, so check the location before assuming the site is broken.

Restore the database, then edit the application config so it points to the new database name, user, and password. On WordPress, update wp-config.php. On Laravel, adjust .env. On older PHP sites, check any hard-coded database credentials in config files.

Typical issues at this stage include:

• Wrong document root: the site loads a default page instead of your app.
• PHP version mismatch: older code fails on PHP 8.3, or newer code fails on older settings.
• Permission problems: uploads cannot be written, or cache files are denied.
• Missing extensions: image processing, mbstring, intl, or ionCube are not enabled.

Test in the browser first, not the terminal. Open the site through a temporary hosts-file override and walk through the homepage, login page, checkout flow, and contact form. If the site depends on email, send a test message and confirm delivery on both sides.

Move email without losing messages

Email is where many migrations go wrong. Website visitors can live with a brief cache delay. Customers will notice missing invoices, support requests, or mailbox data immediately.

Before the DNS switch, recreate mailboxes in Plesk with the same addresses and, if possible, the same passwords. Then lower the DNS TTL for MX and related records to 300 seconds at least a day before cutover. That shortens the wait before new records take effect.

For the mail transfer itself, copy the old mailbox contents using IMAP sync or a migration tool if you have large volumes. After that, send a test message from an external account and confirm these points:

• The message lands in the right inbox.
• SPF includes the new server.
• DKIM is signing correctly.
• DMARC is not rejecting valid mail.

If your mail setup needs a refresher, Hostperl’s email deliverability checklist is a practical companion piece. For panel-specific setup, the cPanel email hosting guide explains the records and mailbox settings you should mirror on the new server.

If you are not confident about mail cutover, keep the old MX records live for a short overlap and monitor both servers. That is safer than switching too early and discovering a mailbox sync gap afterward.

Switch DNS only after the new site passes tests

The final cutover is mostly a DNS task. Update the domain’s A or AAAA record to point to the Plesk server, then confirm the MX and SPF records point where they should. If you use Cloudflare or another DNS provider, update both the dashboard and the underlying zone file if your workflow requires it.

Check these items during the first hour after the change:

1. The homepage loads over HTTPS.
2. Forms submit and send mail.
3. Admin logins work.
4. Image uploads save correctly.
5. Old URLs redirect if the site uses redirects.

DNS propagation is usually faster than people expect, but some networks still cache records longer than the advertised TTL. That is why you should keep both servers available during the transition window. Hostperl’s DNS propagation guide explains what to expect while traffic moves between the old cPanel host and the new Plesk server.

Do not disable the old account immediately. Leave it active long enough to catch stragglers, especially if email is part of the migration. A 48-hour overlap is often enough for smaller sites. Larger businesses may need longer, depending on mail volume and regional caching.

Lock down the new server after the cutover

Once traffic is stable, spend ten minutes on housekeeping. This is the part most teams skip because the site is already live again. That is a mistake.

Start with security basics. Confirm the firewall is active, SSH uses key-based access where possible, and the panel admin password is changed from any temporary value. Then make sure automatic backups are enabled and stored off-server. If you are on Ubuntu, Hostperl’s UFW firewall setup is a helpful reference for tightening the basics without making the server hard to manage.

Next, verify performance settings:

• PHP-FPM is enabled for PHP sites.
• Opcode cache is active.
• Unneeded mailboxes or old accounts are removed.
• Log rotation is enabled so disk space does not fill quietly.

If the move exposed slow pages, check the web root for oversized images, old plugins, and unnecessary redirects before you blame the server. On many sites, a simple image cleanup and the right caching policy matter more than another CPU core.

Quick verification checklist

• Site opens on the new Plesk server with the correct SSL certificate.
• Database-driven pages load without errors.
• All mailbox accounts receive and send mail.
• DNS records match the new hosting setup.
• Backups are scheduled and stored away from the live server.
• Old cPanel hosting remains online long enough to catch missed traffic.

FAQ

How long does it take to move from cPanel to Plesk without downtime?
A small site may take a few hours if DNS is already planned. Larger sites with email can take a full day because testing and mailbox sync matter more than the file copy.

Should I move email at the same time as the website?
Only if you can test it properly. For many customers, a phased move is safer: website first, then email after DNS and deliverability checks pass.

Will my WordPress site need changes after migration?
Usually only the database connection details and file paths. Sometimes you also need to clear cache plugins or update the site URL if the temporary hostname was used for testing.

Is Plesk easier than cPanel for migrations?
Plesk is often easier for staged hosting moves because its structure is clear and the panel tools are straightforward. The best choice still depends on your comfort level and how your site is built.

What if I only have one live site and cannot risk downtime?
Use a temporary test hostname, lower DNS TTL in advance, and keep the old host online during the overlap. If the site is business-critical, move it to a Hostperl VPS first so you can test safely before final cutover.