Migrating From cPanel to Plesk Without Downtime

Moving from cPanel to Plesk is usually driven by licensing cost, a preference for Plesk's interface, or a hosting provider standardizing on one panel. The migration itself is a well understood process, but doing it without downtime requires sequencing the work correctly rather than simply copying files across and switching DNS.

Plan the migration around DNS TTL, days in advance

The single most important step happens before any data moves. Lower the DNS TTL, time to live, for every domain being migrated to a short value, such as 300 seconds, at least 24 to 48 hours before the planned cutover.

dig example.com NS
dig example.com A

DNS resolvers around the internet cache records for however long the TTL specifies, so a record still set to a 24 hour TTL means some visitors keep resolving to the old server for up to a day after you switch, regardless of when you actually change the record. A short TTL set well in advance means the eventual cutover propagates within minutes instead of hours.

Set up the new Plesk server before touching the old one

Provision and fully configure the destination Plesk server first, with no live traffic depending on it yet. Install Plesk, apply the latest updates, and configure the base server security settings, firewall rules and any panel extensions you rely on, such as backup or security add-ons, before migrating any actual site data.

plesk installer --select-release-current --install-component panel

Confirm the new server's outbound mail, DNS resolution and basic connectivity work correctly in isolation before bringing customer data onto it.

Use Plesk Migrator for the account and configuration transfer

Plesk includes a purpose-built migration tool, Plesk Migrator, specifically designed to import accounts, domains, DNS zones, mail configuration and databases directly from a cPanel server. Install it from the Plesk Extensions catalog, then connect it to the source cPanel server using root or WHM API credentials.

The tool reads the cPanel server's account structure and presents a list of accounts to migrate, which lets you migrate in controlled batches rather than all accounts simultaneously, an important detail for keeping the process manageable and for testing the process on a small, low-risk account before committing the rest.

Migrate in batches, and verify each one before moving on

Rather than migrating every account in a single run, move a small batch, verify it fully, then continue. For each migrated account:

• Confirm the website loads correctly when accessed directly by IP or through a temporary hosts file entry, before DNS has switched.
• Confirm database connectivity and that the application, WordPress, a custom application or otherwise, functions correctly against the migrated database.
• Confirm mail account configuration, since mail settings and mailbox data require particular care during a panel migration and are a common source of post-migration support tickets.
• Compare file counts and key directory sizes between old and new to catch an incomplete transfer early.

Testing before DNS changes, using a local hosts file entry pointed at the new server's IP address, lets you verify a fully working site with zero risk to live traffic, since nothing public facing has changed yet.

Sequence the actual cutover

Once a batch is verified and confirmed working, the cutover itself is the low-risk part, provided the TTL groundwork was done in advance.

1. Do a final, incremental sync of any data that changed since the last full migration pass, particularly databases and mail, which change continuously.
2. Update DNS records to point to the new Plesk server.
3. Monitor both servers: watch the new server's logs for incoming traffic and errors, and watch the old server to confirm traffic is draining away as DNS propagates.
4. Keep the old server running and untouched for at least several days after cutover, since some resolvers and cached client configurations take longer than the TTL suggests to fully update.

Common issues to check for immediately after cutover

Mail deliverability is the most common post-migration issue, usually caused by SPF, DKIM or reverse DNS records not being updated to reflect the new server's IP address. Verify these explicitly rather than assuming mail configuration migrated cleanly:

dig txt example.com
dig txt _dmarc.example.com

File permission differences between cPanel's and Plesk's default ownership conventions can also cause application errors that were not present on the source server. Check the web server's error log on the new server specifically for permission-denied errors in the hours after cutover.

Decommissioning the old server

Once the new Plesk server has run cleanly for a full billing or monitoring cycle with no unresolved issues, and you have confirmed backups exist independently of the old server, the cPanel server can be safely decommissioned. Keep a final full backup of the old server's data for a reasonable retention period even after decommissioning, as a safety net against anything missed during verification.

iServerSupport provides Plesk server management including migrations from cPanel and other panels, planned and executed with the batch verification and DNS sequencing above, so the switch happens without a visible outage for your visitors or customers.