cPanel migration checklist: Virtualmin, Plesk and email

1. Record what the account actually runs

List every primary domain, addon domain, subdomain and alias. For each website, record its document root, PHP version and extensions, database engine and version, scheduled jobs, redirects and storage use. Note anything outside the account: object storage, CDN rules, payment callbacks, transactional email and third-party DNS.

For mail, count mailboxes and storage, then record aliases, forwarders, catch-all behaviour and mailing lists. Ask users whether they keep local-only mail in a desktop application; a server transfer cannot copy messages that only exist on a laptop.

Build a simple acceptance sheet before starting. Each row should have an owner, a check, the expected result and a place to record the result. “Homepage opens” is one check. “A new order appears once and the confirmation arrives” is another.

2. Migrating cPanel to Virtualmin

Virtualmin can import a cPanel backup through Migrate Virtual Server. Its command-line equivalent is migrate-domain, with the source backup and cPanel selected as the source type. Follow the Virtualmin migration reference for the options supported by your version.

Use a full account backup and inspect the import report. A file-only archive or a database export is not the same input. Start with one representative account on a prepared destination before attempting a batch.

Account structure needs attention. Virtualmin uses virtual servers, sub-servers and aliases; these are not interchangeable with every cPanel label. Compare the resulting domain ownership and document roots with your inventory, using Virtualmin’s terminology guide where needed.

After import, test PHP handlers, database users, scheduled jobs, permissions and mail authentication. A completed import does not establish that the application works under its new runtime.

3. Migrating cPanel to Plesk

Install Plesk Migrator on the destination, choose cPanel as the source and supply the source server connection details. The normal Linux server migration requires privileged source access. Check Plesk’s interface migration instructions before promising this route to someone with only a shared hosting login.

Prepare the destination services and licence first. Review pre-migration warnings, migrate a pilot account, then use Plesk’s post-migration checks alongside your application checks. The importer can transfer hosted content, but destination PHP handlers, firewall policy and other server configuration still need attention. See what Plesk Migrator transfers.

Read the current cPanel migration limitations, especially where databases or mail authentication differ. If you lack the required access, agree a website and mailbox import plan with the hosting provider instead of discovering the restriction during cutover.

4. Move email without abandoning new messages

A mailbox count is not enough. Compare folders, sample messages, attachments and message dates. Test logging in, sending to an external address and receiving a reply. Recreate forwarders and check that each intended sender is authorised by the destination email setup.

If moving email separately, Plesk’s mail import supports copying from existing mail servers. An IMAP-based copy concerns server-held messages; contacts, calendars, rules and local archives need their own checks. Confirm the chosen tool’s behaviour before running it repeatedly.

Keep both mail services available during the DNS transition and perform a final reconciliation for mail arriving at the old server. Tell users about any new server names or password changes. Do not retire the source while new messages are still arriving there.

Check MX records, SPF, DKIM and DMARC for the actual sending services. If you manage the new mail server, also check reverse DNS with its provider. Our plain-English email authentication guide explains what each record does.

5. Test the destination before switching traffic

Use a hosts-file override or a suitable preview method to reach the new server while public DNS still points to the old one. Verify which server receives the request; otherwise you may accidentally test the original site.

Check HTTPS, redirects, images, downloads and important landing pages.
Test logins, password resets and form delivery with controlled test data.
For stores or memberships, use the payment provider’s test mode and confirm subscriptions and callbacks follow the intended route.
Check background jobs, queues and scheduled tasks. Avoid running duplicate billing or notification jobs on two live copies.
Test a backup and restore on the destination, including the data needed to run the application.

Keep a record of warnings and failures. Give each unresolved item an owner and a decision: fix before launch, accept explicitly, or stop the move.

6. Plan the final sync, DNS change and rollback

Lower relevant DNS TTLs far enough in advance for the previous values to expire. Record the original A, AAAA, MX and any changed service records. Moving the website does not automatically require moving nameservers or email.

For a site that accepts orders, uploads or comments, agree a brief write freeze or a tested final sync strategy. Copying last week’s database and changing DNS will lose the intervening changes. Decide which system is authoritative during the switch and prevent writes to an abandoned copy.

Define the rollback trigger and the person who can call it. Changing DNS back is only part of rollback: new orders, uploads and email created on the destination must be reconciled. Never overwrite the newer data with an old backup just to get the homepage back.

After cutover, repeat the acceptance sheet from an external connection, watch both servers and verify scheduled jobs. Keep the old service until the agreed observation period and data reconciliation are complete. Then remove temporary access and migration archives, and document the new setup.

7. What determines the migration quote?

The number of accounts is only one input. Mailbox volume, old application versions, custom DNS, unavailable credentials, large databases and the allowed interruption window can matter more.

For a useful quote, send the current and destination panels, approximate site and mailbox counts, storage, access level and any hard deadline. Mention stores, subscriptions and other systems that keep changing while you move them. Share credentials through an agreed secure method after scope is agreed.

OpsHelp quotes hosting panel migrations separately after reviewing the move. A low-cost maintenance plan does not include an unscoped migration. Hosting providers can also discuss batched migration and ongoing support.