10 mistakes to avoid when migrating from cPanel to Plesk without losing email and DNS

Anyone who manages servers for a living knows that a panel migration is never just "copy and paste". Between cPanel and Plesk, the licensing model, the tools, and above all the order in which DNS, email and databases need to be moved all change. Getting the sequence wrong means bouncing emails or DNS zones disappearing for hours. Here are the points where people trip up most often.

1. Not checking the licensing model before quoting

Plesk is licensed per server, with pricing options for virtual or physical servers (VPS or dedicated), and according to the official Plesk FAQ, Plesk also offers multiple editions, all licensed based on the number of domains on that server. Anyone coming from cPanel needs to know that cPanel has recently increased its prices and now licenses per individual cPanel account, meaning the cost of hosting multiple accounts on cPanel is going up. The practical upshot: on a server with dozens of low-traffic accounts, Plesk can end up cheaper because the limit is on domains managed, not on active accounts. According to the official price list checked on 6 October 2026 at plesk.com/pricing, the Web Pro Edition VPS licence costs €18.29/month (30 domains) and the Web Host Edition VPS costs €31.38/month (unlimited domains); Plesk also notes that a new pricing structure comes into effect from 1 January 2026, applying to renewals after that date — check the exact amount on the price list at the time of purchase.

2. Assuming you can migrate "domain by domain"

A classic mistake made by those used to moving cPanel accounts one at a time. With Plesk Migrator, you cannot choose to migrate individual domains. Only subscriptions can be selected for migration, and they are migrated together with all associated domains. If a client has 5 domains under the same cPanel account, in Plesk they all arrive together or not at all.

3. Ignoring what the tool does NOT transfer

Reseller and client accounts with no domains are not transferred. Plesk's service settings — installed PHP handlers, Fail2Ban settings, ModSecurity settings, firewall settings and more — are not transferred. These need to be rebuilt manually on the destination server before traffic is moved, otherwise the new server starts out without basic protections in place.

4. Not checking the source cPanel version

Plesk Migrator supports migration from the following source platforms: Plesk 8.6 and later (Linux and Windows), cPanel 11.5 and later, as well as Confixx 3.3, Helm 3.2, Plesk Expand 2.3.2 and DirectAdmin 1.51 (custom migration from Ubuntu 10.x only). On older versions the tool is not guaranteed to work.

5. Starting the migration without preparation

The process must be started from the Plesk side: migration is launched from the Plesk administration panel on the destination server, via Tools & Settings > Migration & Transfer Manager > Start a New Migration. From there you move on to cPanel and enter the source server's IP address, the SSH port (22 by default), and the root login and password for the source server.

6. Not knowing you can resume where you left off

You can always come back to this page to resume from where you left off or to start a new migration process: useful if the first attempt fails due to an SSH timeout or a full disk on the source server.

7. Forgetting the TTL of DNS zones

In the configuration files for command-line migration there is a zones-ttl parameter, corresponding to the time in seconds that the migration tool sets as the SOA minimum TTL and refresh interval on the new DNS server. If not specified, the default value is assumed: 120 seconds. A TTL that's too low or too high on the new server, left at default without being reviewed, can extend propagation time or multiply query traffic during the cutover.

8. Doing the DNS cutover before verifying mail and databases on the new server

The correct sequence is: first migrate the data (files, mail, databases) with Plesk Migrator, verify that mail is arriving correctly on the new server using a test domain, and only afterwards lower the TTL and move the public DNS records. Reversing the order — pointing DNS first and only then discovering that IMAP isn't responding — means lost email for the duration of the propagation period.

9. Not planning the migration window

The official documentation recommends that if the source server is overloaded or has limited resources, it's best to schedule the migration outside working hours wherever possible. This is especially true for large databases, where the transfer can saturate the source server's I/O and CPU.

10. Skipping pre-migration checks

Plesk Migrator includes pre- and post-migration checks, error reporting features, and allows you to resynchronise data between the old and new server after migration. Ignoring the warnings shown during the "Prepare Migration" stage in order to save time is the most common way to end up with half-migrated subscriptions.

---

In short: before touching a single DNS record, check the licence and the source version, launch the subscription migration with Plesk Migrator, manually check mail and databases on the new server, and only at the end lower the TTL and move the public DNS. The tool does the heavy lifting, but the order of operations remains the responsibility of whoever manages the server.