Moving hosting customers off cPanel without them noticing

To migrate hosting customers from cPanel without them noticing, move their accounts in small waves, keep their passwords, switch DNS only after you have tested each account on the new server, and send short emails that tell them exactly what changes and what does not. Most customers notice only three things: a new panel address, mail apps that need a new server name, and anything that breaks on switch day. Plan for those three and the move stays quiet.

This article is about the customer side of a migration: the schedule, the emails and the per-account checks. For the technical steps of moving one account, see migrating from cPanel to a VPS; for moving every account of a server with one tool, see how to migrate an entire cPanel server.

What customers actually notice

Before writing a single email, list what will be different for a customer after the move. With a good importer most of the account comes across as it was. What usually changes:

What	On cPanel	After the move	Customer action needed?
Panel address	Usually port 2083 (cPanel ports)	Your new panel address, for ZoPanel usually ending in :8888	Update the bookmark
Panel password	Their password	Kept when the hash can be checked on the new server, otherwise reset	Only if reset
Website, files, databases	Running	Same content; database passwords kept or rewritten into the app config	No
Mailboxes and mail	IMAP/POP3	Same addresses, passwords and messages (Maildir)	Only if the mail server name changes
Webmail	Port 2096	Depends on the new panel; ZoPanel also uses port 2096 on the panel domain	Maybe a new bookmark
FTP accounts	name@domain	On ZoPanel, <account>_name	Update FTP clients
DNS	Your nameservers	Your nameservers, or the customer's own DNS	Only if they host DNS elsewhere

The ZoPanel column comes from the migration guide, which lists exactly what the importer carries over and what it does not, such as mailboxes in mdbox format or PostgreSQL databases.

The last row matters most. When you run the nameservers, you switch DNS for the customer and they do nothing. When a customer's domain uses Cloudflare or a registrar's DNS, they must change the A and MX records themselves, and those accounts need their own emails and their own wave.

Plan the waves

Do not move everything in one night. Group accounts so that problems show up early on accounts where they do little harm.

Wave	Accounts	When	Why
0	Your own sites and a test account	Week 1	Find importer notes and missing PHP extensions on yourself
1	Static and brochure sites, no mail	Week 1 to 2	Low risk, quick to check
2	Business sites with mailboxes	Week 2 to 3	Mail is where most complaints come from
3	Customers who host DNS elsewhere	Week 3	They must act, so they need more notice
4	Shops, booking sites, anything with constant orders	Week 4, quietest hours	Data written during the move must not be lost

Wave sizes depend on your team. A good rule is a number of accounts you can check by hand the same day, plus time to answer the tickets that follow. The DNS switch for a wave is the moment of risk, so do it at a time you will be awake for the next few hours.

Before wave 1

• Lower the TTL of every domain's A, AAAA and MX records, for example to 300 seconds, at least a day ahead. Resolvers cache a record for its TTL (RFC 1035), so the old value can stay in caches for the old TTL even after you change it.
• Match PHP versions. The importer reads cPanel's PHP version per account; install the same versions on the new server first.
• Set up the mail hostname and certificate on the new server, so mail apps do not see certificate warnings.
• Publish your support channel for the migration period, and tell your team which wave is moving when.

The customer emails

Three emails per wave are enough. Keep them short; long emails get skimmed and the one line that matters is missed. Replace the parts in brackets.

1. Notice, about a week ahead

Subject: Your hosting is moving to a new server on [date]

Hello [name],

On [date], between [time] and [time], we will move your hosting account [domain] to a new server. Your website, email and files move with it.

What you need to do: nothing, unless we write to you again. Your website address, email addresses and passwords stay the same.

After the move, you will manage your hosting at a new address: [new panel URL]. We will send it again when the move is done.

Please avoid big changes to your website (new plugins, large uploads) on [date]. If that date is a problem for you, reply to this email and we will move you in a later group.

[Your name], [Company]

For customers who host DNS elsewhere, add one paragraph with the exact records to change and when:

Your domain's DNS is managed outside our servers, at [provider]. On [date] after [time], please change these records, or forward this email to whoever manages your domain:

• A record for [domain] and www.[domain]: [new IP]
• MX record: [mail hostname], priority 10
• Update the SPF record to include [new IP]

We will check them from our side and confirm by email.

2. Reminder, the day before

Subject: Reminder: your hosting moves tomorrow

Hello [name], a reminder that [domain] moves to our new server tomorrow, [date], between [time] and [time]. Please avoid changes to your website during that time. You do not need to do anything else.

3. Done, and what changed

Subject: Your hosting has moved

Hello [name],

[domain] now runs on our new server. Your website and email work as before.

• New control panel: [new panel URL], with your existing username and password.
• Webmail: [webmail URL].
• Email apps (Outlook, phone): if your app asks for a server name, use [mail hostname], port 993 for IMAP and 587 for sending.
• FTP: your FTP username is now [new FTP username].

If anything looks different or does not work, reply to this email or [support link].

Only list the lines that apply to that customer. If their panel password was reset because its old format could not be carried over, say so here, and send the new password through your usual secure channel, not in this email.

Per-account checklist: DNS and mail

Check each account on the new server before you change DNS. Preview the site from your own computer by pointing the domain to the new IP in your hosts file.

Check	How	Pass when
Importer log reviewed	The task log of the import	Every note has been read and acted on
Home page and admin area	hosts file preview	No errors, no mixed content, logins work
Forms and outgoing mail from the site	Submit the contact form	Mail arrives and is not marked as spam
PHP error log	The site's logs	No new fatal errors
Mailbox sign-in	Webmail and one IMAP client	Old password works, folders are there
DNS records ready	Zone on the new server	A, AAAA, MX, SPF, DKIM and DMARC match the new server
Mail delivery check	ZoPanel Mail delivery check	MX, SPF, DKIM, DMARC, PTR and port 25 pass
Certificate	After DNS switches	Issued for the domain, no browser warning

Then switch DNS, and afterwards:

• Watch mail for a few days. Some senders cache old MX records. Keep the old server's mail running for at least a week and copy anything that lands there to the new mailboxes with an IMAP sync tool such as imapsync.
• Re-sync busy sites. For shops, either pause orders during the final copy, or move once as a rehearsal and again right before the switch, so no order written on the old server is lost.
• Keep the old server for a week or two. It is your rollback plan and the source for anything forgotten.

Doing it with ZoPanel

ZoPanel imports cPanel backups (cpmove-USER.tar.gz) and DirectAdmin backups. For a whole server, Migrate in → Move a whole server connects to the cPanel server over SSH, runs pkgacct there for each account you tick, and imports the accounts one after another, so you can move a wave at a time: tick only that wave's accounts. Accounts whose name already exists are skipped, so you can run it again for the next wave.

For each account, the importer carries over the websites, files, databases and their users, mailboxes with their messages, forwarders, autoresponders, cron jobs, DNS zones, FTP accounts and SSL certificates, and keeps passwords whenever their format can be checked on the new server. Everything it could not carry over appears as a note in the log with the reason. The source server is not changed, so DNS stays your switch (migration feature).

To be fair about the limits: ZoPanel does not import from CyberPanel, aaPanel or HestiaCP directly, it does not import PostgreSQL databases automatically, and its panel is different from cPanel, so customers who know cPanel well will need a short tour. A one-page guide helps; the customer guide is a good base for yours. cPanel's own Transfer Tool is the smoother path if you are only moving between two cPanel servers.

Conclusion

Customers notice a migration when something they rely on changes without warning. Move in waves, test every account before its DNS switches, keep passwords, and send three short emails that say exactly what to do, which for most customers is nothing. Keep the old server running until the mail has gone quiet.

To rehearse the whole process, install ZoPanel's Free plan on a spare VPS (3 hosting accounts, 10 websites, 10 databases, no time limit) and move wave 0 first.

Frequently asked questions

Will my hosting customers have downtime during the migration?

Usually not, if you test on the new server before changing DNS and lower the TTL a day ahead. During the switch, some visitors reach the old server and some the new one for a few minutes, and both serve the same site. Sites that take orders need a short pause or a final re-sync so nothing written on the old server is lost.

Do customers need new passwords after leaving cPanel?

Not usually. ZoPanel keeps panel, SFTP, mailbox and database passwords when their hash format can be checked on the new server. When it cannot, the import log tells you, and you set a new password and send it to the customer securely.

Should I tell customers I am changing control panel?

Yes, but keep it short and practical. Tell them the date, that their website, email and passwords stay the same, and the new panel address. Most customers care about what they must do, not which software you run.

How many accounts should I migrate per night?

As many as you can check by hand the same day and support the next morning. Start with a small wave of your own and low-risk accounts, then grow the waves once the first ones went quietly.

What about customers whose DNS is not on my servers?

They must change their A and MX records themselves, so put them in a separate wave, send them the exact records a week ahead, and confirm from your side when the records are correct. Until they change DNS, their site keeps running on the old server.