cPanel & Plesk Server Migration Checklist (2026): The Complete Step-by-Step Guide
The migrations that go badly are not the ones with the hardest commands, they are the ones with the smallest forgotten steps. This is the checklist our engineers actually use every week, when moving customers onto WIPLON Linux Cloud and Managed Dedicated Servers.
01Why a checklist beats a tutorial
We have run more than a thousand server migrations in the last twenty years at WIPL. The pattern is always the same. Engineers know how to do the migration, the tools are well documented, the commands are simple. What goes wrong is rarely technical, it is procedural. Someone forgets to lower the DNS TTL the night before. Someone copies the database an hour before flipping DNS, so the last hour of orders ends up on the old server. Someone reissues SSL on the new IP but does not include the www SAN.
A checklist removes that class of mistake. It is the difference between a migration that finishes at 2 AM with a single coffee, and a migration that drags into the next day with a customer Slack channel full of red dots.
This guide covers cPanel and Plesk on Linux specifically, which is what about 90% of dedicated server estates in India and the AMEA region still run on. We have written it to match how a real migration actually unfolds, in four phases, with explicit checkboxes you can tick as you go.
02Before you start, the 10 prerequisites
If any of these are missing, stop and gather them first. Half of all failed migrations are failures of preparation, not execution.
- Root SSH access to the source server, plus the IP, hostname, and OS version confirmed
- Root SSH access to the destination server, with a fresh control panel install verified at the licence portal
- Inventory of every domain, subdomain, addon domain, parked domain, and email account on the source, exported to a spreadsheet
- List of every database, with its size and the application it backs (WordPress, Magento, WHMCS, custom, etc.)
- List of every scheduled cron job on the source server, with the user it runs as
- List of all SSL certificates, their type (Let’s Encrypt, RapidSSL, DigiCert, wildcard), and their expiry dates
- Free disk on the destination of at least 1.5x the data size on the source, with 5 GB headroom for working files
- A confirmed maintenance window, communicated to all stakeholders at least 72 hours in advance
- A signed-off rollback plan, so everyone knows what “abort” looks like at each phase
- Backup verification, a recent backup of the source you have actually restored somewhere, not just one you assume works
The two prerequisites people skip most often are number 5 (cron jobs) and number 10 (verified backup). Cron jobs are invisible from the panel UI most of the time, and they are the source of the most embarrassing post-migration bugs, billing scripts that quietly stop running, monitoring scripts that silently die. Always export them with crontab -l -u username for every account.
03Phase 1, Pre-migration prep (T-72 hours to T-1 hour)
This is the calm phase. You should be doing all of this before the actual data transfer starts, ideally 2 to 3 days in advance. Rushing this phase is the single most common cause of bad migrations.
Lower DNS TTLs early
Every DNS record on the domains you are migrating should have its TTL dropped to 300 seconds (5 minutes), at least 48 hours before cutover. This is the lever that lets you do near-zero downtime later. If you flip DNS while the TTL is still 14400 (4 hours), you will be looking at split traffic for half a day.
# Example, using cli53 or your DNS provider's API
# Drop TTL on A, AAAA, MX, CNAME records to 300 seconds
dig +short example.com
# Check propagation at https://dnschecker.org before proceeding- Lower TTL to 300s on every A, AAAA, MX, TXT, and CNAME record, 48+ hours before cutover
- Take a full filesystem backup of
/home(cPanel) or/var/www/vhosts(Plesk) and store it off the source server - Take a full
mysqldump --all-databases --routines --triggers --single-transactionand verify it restores cleanly on the destination - Snapshot the source server at the hypervisor level if available, this is your one-click rollback
- Install the matching control panel version on the destination, ideally the same major version as the source
- Allow the destination IP through the source firewall (CSF, ConfigServer, or
firewalld) on ports 22, 2087, 3306, and any custom rsync ports - If migrating to Plesk, disable SELinux on the destination during migration (re-enable carefully after)
- Run a dry test on one low-traffic domain, fully end to end, before the real migration window
04Phase 2A, cPanel to cPanel transfer
This is the cleanest of the three scenarios. cPanel ships with a first-party transfer tool, WHM > Transfer Tool, that handles accounts, mail, databases, DNS zones, and SSL in a single workflow.
Option 1, WHM Transfer Tool (recommended)
From WHM on the destination, go to Transfers & Account Importer > Transfer Tool, enter the source IP and root password, and let it scan. It returns a tree of accounts. Pick the ones you want, including their databases, mail, and DNS zones, then submit.
The tool runs /scripts/pkgacct on the source for each account, streams the archive over SSH, and runs /scripts/restorepkg on the destination. For 50 accounts under 500 GB total, expect 2 to 6 hours.
Option 2, Manual pkgacct (for selective control)
# On the source server
/scripts/pkgacct username /home/backup
# Creates /home/backup/cpmove-username.tar.gz
# Pull from destination
rsync -avzP root@source-ip:/home/backup/ /home/backup/
# Restore on destination
/scripts/restorepkg /home/backup/cpmove-username.tar.gz- Verify both servers are on the same major cPanel version, or destination is one version ahead
- Check destination has matching EasyApache 4 PHP versions and modules (ioncube, intl, mbstring, gd, imagick)
- Run the transfer with Express Transfer disabled for large accounts (it consumes more memory but is more reliable)
- Confirm that reseller accounts, packages, and feature lists came across, these are commonly missed
- Verify
/var/cpanel/users/entries match between source and destination after migration - Re-run
/scripts/upcp --forceon destination to make sure the new accounts integrate cleanly - Test webmail (Roundcube), incoming SMTP, IMAP, and outgoing relay for at least three random accounts
05Phase 2B, Plesk to Plesk transfer
Plesk’s native tool is called Plesk Migrator, available under Extensions in the Plesk panel on the destination. It works against Plesk, cPanel, and DirectAdmin sources, but Plesk-to-Plesk is where it shines.
Install and connect
# On destination Plesk
# Extensions > search "Plesk Migrator" > Install
# Or from CLI
plesk installer --select-release-current --install-component panel-migrator
# Test SSH from destination to source
ssh root@source-server-ipRun the migration
In the Plesk Migrator UI on the destination, select Start New Migration, source type Plesk, enter source credentials, click Prepare Migration. The tool builds a domain list and shows you any pre-flight issues, missing PHP versions, IP mismatches, mailbox size warnings.
- Confirm both servers are on the same Plesk major version (Obsidian 18.0.x), with the destination patched to the latest minor
- Install all PHP versions present on the source, before starting (
plesk installer --select-product-id plesk --show-components | grep php) - Make sure required Plesk extensions exist on the destination, WordPress Toolkit, Git, Docker, NodeJS, Ruby, depending on the source
- Pre-create any custom service plans on the destination, the migrator will assign domains to a default plan otherwise
- For large mailbox migrations, increase
migration.mail-rsync-timeoutinpanel.inion the destination - Keep the destination’s hostname and licence active and matching the panel licence at activation.plesk.com
- If migrating Plesk for Linux with Postfix, validate that the source uses Postfix (not qmail) before starting, qmail to Postfix needs manual mail dir conversion
06Phase 2C, cPanel to Plesk crossover
This is the most common cross-platform migration we do, and the one with the most footguns. The same Plesk Migrator extension handles it, but there are real differences in how cPanel and Plesk structure mail, vhosts, and PHP that you need to plan for.
Where cPanel and Plesk differ
| What | cPanel layout | Plesk layout |
|---|---|---|
| Webroot | /home/user/public_html | /var/www/vhosts/domain.com/httpdocs |
| Mail storage | /home/user/mail/domain.com | /var/qmail/mailnames/domain.com |
| PHP binary path | /usr/local/bin/php or EA-PHP at /opt/cpanel/ea-php74/... | /opt/plesk/php/7.4/bin/php |
| DB user mgmt | MySQL root via WHM | admin user via /etc/psa/.psa.shadow |
| FPM config | /etc/cpanel/ea4/... | /opt/plesk/php/X.Y/etc/php-fpm.d/ |
| SSL store | /var/cpanel/ssl/apache_tls/ | Stored in psa DB, retrievable via panel UI |
FPM socket version mismatch is the silent killer here. When you migrate a WHMCS or WordPress site from cPanel PHP 7.4 to Plesk, the Plesk UI may show PHP 7.4 assigned, while the actual FPM socket on disk is still being served by PHP 8.3. Always verify with ps aux | grep php-fpm and check the FPM config file lives under the correct /opt/plesk/php/X.Y/etc/php-fpm.d/ directory.
Migration command sequence (cPanel → Plesk)
# On destination Plesk, install migrator
plesk installer --select-release-current --install-component panel-migrator
# Create migrator config
mkdir -p /usr/local/psa/var/modules/panel-migrator/conf
cat > /usr/local/psa/var/modules/panel-migrator/conf/config.ini << 'EOF'
[GLOBAL]
source-type: cpanel
source-servers: cpanel
target-type: plesk
[plesk]
ip: DESTINATION_IP
os: unix
[cpanel]
ip: SOURCE_IP
os: unix
ssh-password: SOURCE_ROOT_PASSWORD
EOF
# Run pre-checks
/usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator prepare-migration
# Start the migration
/usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator migrate
# Validate after
/usr/local/psa/admin/sbin/modules/panel-migrator/plesk-migrator test-all- Strip cPanel-specific directives from every
.htaccessafter migration, specifically references to/var/cpanel/php/sessions/ea-php*andOptions +FollowSymLinks - Replace
Options +FollowSymLinkswithOptions +SymLinksIfOwnerMatchvia the domain’svhost_ssl.conf, Plesk blocks the former - Re-issue Let’s Encrypt or import RapidSSL/DigiCert certs manually from the cPanel SSL store (
/var/cpanel/ssl/apache_tls/domain.com/combined) - Recreate Mailman mailing lists manually if present, Plesk Migrator does not transfer them cleanly from cPanel
- For WHMCS sites, verify ionCube loader is enabled on the correct PHP version, and that no duplicate
00-ioncube-loader.inientries exist - Set
session.save_pathexplicitly per domain, otherwise sessions fall back to/tmpand WHMCS will log users out randomly - Manually translate cPanel email forwarders and autoresponders, Plesk uses different storage and the tool sometimes misses edge cases
- Recreate FTP users and reseller-style permissions, these do not always map 1:1
07Phase 3, DNS cutover the smart way
This is the moment of truth. Up to here, everything has been parallel work. The next 30 minutes decide whether your users notice anything at all.
The local hosts file trick
Before you change a single DNS record, test the migrated site from your own machine by pointing your /etc/hosts (or C:\Windows\System32\drivers\etc\hosts on Windows) at the new server IP:
# Add to /etc/hosts on your laptop
185.199.53.51 example.com
185.199.53.51 www.example.com
185.199.53.51 webmail.example.comBrowse the site, log in, place a test order, check SSL, check email send/receive. You are now testing against the new server while the rest of the world still hits the old one. Do not skip this.
The cutover sequence
- Put the source application(s) into a read-only or maintenance mode, where supported (WordPress maintenance plugin, WHMCS maintenance mode, Magento maintenance flag)
- Run a final incremental rsync of
/homeor/var/www/vhoststo catch any files changed since the bulk transfer - Run a final
mysqldumpof every database and restore on the destination, this is the only step you cannot do early - Switch the A record(s) of every domain to the new IP, MX records too if mail is moving
- Wait 5 to 10 minutes for the 300-second TTL to expire globally, monitor with
dnschecker.org - Keep the old server running, unchanged, for at least 7 days, this is your hot rollback
- Issue or import SSL certs on the new server before DNS flip, otherwise the first visitors after cutover hit a cert mismatch
- Add the new server’s IP to all transactional mail provider allowlists (SendGrid, Mailgun, AWS SES, Amazon SNS) and update SPF records
Keep both servers running databases for the first 24 hours, and run a one-way replication from new to old (yes, backwards). If you have to roll back, that backward replication means the old server is not stale. The number of times this has saved a customer at 3 AM is too high to count.
08Phase 4, Post-migration validation
The migration is “done” when monitoring agrees. Not before.
- Hit every domain in a browser via the new IP, confirm 200 OK, correct SSL, correct content
- Send and receive at least one test email from every mail account, including webmail and external clients (Outlook, Apple Mail)
- Verify all DNS records propagated globally (use
dig @8.8.8.8,dig @1.1.1.1, and Google DNS over HTTPS) - Confirm cron jobs are running on the new server, by checking each job’s log output within its next scheduled interval
- Validate every database has the expected table count and the latest record matches the source (count
tblclientsin WHMCS,wp_postsin WordPress,sales_orderin Magento, etc.) - Check Zabbix or your monitoring stack picks up the new server cleanly, with all critical services (httpd, mysql, postfix, dovecot, fail2ban) reporting up
- Verify rDNS / PTR record on the new IP matches the mail hostname (your mail provider will silently downgrade reputation if it does not)
- Run
mail-tester.comfrom a real account on the new server, score should be 9/10 or better - Confirm backups are running on the new server (Acronis, JetBackup, Plesk backup, R1Soft, whatever the stack is), with at least one successful backup completed in the new location
- Decommission plan, schedule the old server’s wipe-and-return for 7 to 14 days out, never the same day
09Common pitfalls we see every month
After running this checklist hundreds of times, these are the seven things that still trip up experienced engineers:
1. Forgotten DNS records
SPF, DKIM, DMARC, and CAA records are the most-forgotten part of any migration. Mail will technically work for days, then a major recipient (Gmail, Outlook 365) starts marking everything as spam. Export every record from the source DNS zone, every record, not just A and MX.
2. PHP version drift
The source ran PHP 7.4 with specific extensions. The destination has 7.4 installed but is missing php-intl or ioncube. The site loads, dashboards work, but checkout silently fails. Always diff php -m output between source and destination.
3. open_basedir restrictions
cPanel and Plesk both use open_basedir, but with different default paths. If your application reads from /tmp, writes to a custom log directory, or includes a cross-account library, it will break after migration. Check error_log on the new server for open_basedir restriction in effect warnings.
4. cron jobs running under the wrong user
cPanel crons run as the account user, Plesk crons can run as the domain’s system user or as root depending on how they were created. A backup script that wrote to /home/user/backup as user will fail on Plesk if the cron is now running as root, because root cannot write to a folder owned by psaserv without explicit chown.
5. WHMCS, WordPress, and Magento cache poisoning
All three applications cache the server URL, file paths, or database connection details in some form. After migration, clear every cache, wp cache flush, WHMCS template compile cache, Magento var/cache and var/page_cache. Do this before cutover, not after.
6. Mail loops on shared MX
If the source server is also a backup MX for the destination (or vice versa), or if both share a smart-host configuration, you can get into a mail loop after cutover. Always check postconf -n and main.cf for relay configuration on both ends before you flip MX.
7. License lock-in
cPanel licences are IP-locked. Plesk licences are bound to an activation code that recognises hostname and IP. Always confirm the new server has a fully active licence before migration starts, not at 11 PM on the night of cutover when cPanel’s licence portal is queued behind a 30-minute support response time.
10FAQ
How long does a cPanel or Plesk server migration take?
For a typical mid-sized dedicated server with 50 to 200 cPanel accounts or Plesk subscriptions, a planned migration takes between 4 and 24 hours. Data transfer time depends mostly on total disk usage, network speed between the source and destination data centres, and email volume. With a phased DNS cutover, actual customer-facing downtime can be brought close to zero.
Can I migrate from cPanel to Plesk without losing emails?
Yes. Both Plesk Migrator and a manual rsync-based approach preserve Maildir contents, mailbox passwords, autoresponders, and forwarders. The trick is to lower DNS TTL well in advance, do a final mail sync just before DNS cutover, and keep the old server live for 7 to 10 days as a fallback while MX records propagate.
Should I choose cPanel or Plesk for my new dedicated server?
Both are excellent. cPanel and WHM remain the de-facto standard for traditional Linux shared and reseller hosting in India and the AMEA region. Plesk has stronger native support for Windows workloads, WordPress Toolkit, and Docker. Pricing has shifted significantly since 2019, so for new servers we usually recommend Plesk for mixed Windows/Linux estates and cPanel for pure Linux shared hosting environments.
What is the safest way to test a migrated site before changing DNS?
Edit your local hosts file (Windows, C:\Windows\System32\drivers\etc\hosts, Linux/macOS, /etc/hosts) to point the migrated domain to the new server IP. You can then browse the site exactly as a real visitor would, validate SSL, test logins, payment flows, and admin areas without changing public DNS at all.
Do you offer managed migration as part of WIPLON plans?
Yes. Every WIPLON Linux Cloud and Managed Dedicated Server plan includes free expert migration from cPanel, Plesk, DirectAdmin, or a custom stack. Our team handles backups, transfer, SSL re-issuance, DNS cutover, and a 14-day stability monitoring window after go-live. The full migration is included at no extra cost, regardless of how many accounts or domains.
What about migrating sites running ionCube, like WHMCS?
ionCube needs explicit loader installation per PHP version on the destination. After migration, verify it is loaded with php -m | grep -i ioncube on the exact PHP version the site is bound to. Watch for duplicate loader entries, both Plesk and cPanel sometimes load ionCube via two different config files, causing intermittent fatal errors. Remove any duplicate zend_extension entries from php.ini if 00-ioncube-loader.ini is already present.
Can I do the migration myself without managed support?
Yes, absolutely, this guide covers everything you need. The reason most teams hand it to us is the 14-day post-migration window, the 2 AM call when something unexpected breaks, and the licence/IP coordination across data centres. If you have a strong sysadmin and a forgiving customer base, do it yourself. If you have customers who file tickets for a slow image load, get help.
Want to migrate your server without doing any of this?
Every WIPLON Linux Cloud and Managed Dedicated Server plan includes free expert migration, full SSL re-issuance, DNS cutover handling, and 14 days of stability monitoring after go-live. Our engineers run this checklist for you, on Linux servers across India, UAE, Singapore, and the US, starting at ₹4,699/mo.
Written by the WIPLON Engineering team, based on real migrations across cPanel and Plesk dedicated servers in India, UAE, Singapore, and US data centres. Last technical review, June 2026, against cPanel 124 and Plesk Obsidian 18.0.70.
