cPanel to CyberPanel without the downtime

Search for a cPanel to CyberPanel migration and you’ll get the same answer seven times: generate a full cPanel backup, upload the tarball, run the auto-import, done. CyberPanel’s own knowledge base says it, Bobcares says it in four steps, and there are three YouTube videos of someone doing it on an empty test box.

All of that is correct. It’s also the easy 20% of the job, and it’s the part that doesn’t take a site offline.

We’ve moved somewhere north of 60 accounts off cPanel onto CyberPanel over the last two years, mostly for people whose licence renewal came in higher than their server. Here’s what the importer doesn’t carry across, and how the cutover actually gets sequenced so nobody’s mail bounces.

Assume the importer gets files and databases, and nothing else

The auto-import in CyberPanel 1.8.5 and later reads a standard cPanel backup and restores the document root, the databases, and in recent builds the email accounts. That part works and it’s genuinely convenient.

What we have had to rebuild by hand, every time:

• Cron jobs. They live in the cPanel backup but the importer doesn’t install them. If a store runs a stock sync every fifteen minutes, nobody notices until inventory drifts on day three.
• Per-domain PHP version. cPanel’s MultiPHP settings don’t map onto CyberPanel’s LSPHP versions. A site pinned to 7.4 on the old box lands on whatever the new box defaults to, and if that’s 8.2 an older plugin will fatal.
• Email filters, forwarders and autoresponders. Accounts come over, rules mostly don’t. The forwarder that routes invoices to accounting is the one you’ll hear about.
• MySQL users and grants. You’ll get the databases and the primary user. Secondary users that a reporting tool or a staging site connects with tend to vanish.
• SSL. Certificates don’t transfer usefully. Issue fresh Let’s Encrypt certs on the new box, which you can only complete after DNS points at it, so plan for a short window where HTTPS is new.
• Addon and parked domain mappings. The files arrive; the mapping of which domain serves which folder frequently doesn’t.
• Custom php.ini overrides, extra extensions, IP blocks and hotlink rules.

One more that catches people: OpenLiteSpeed reads .htaccess, so most rewrite rules survive. Directives that depend on specific Apache modules don’t always behave the same way, and any caching plugin config from the old box should be thrown away rather than migrated, because LSCache is the reason you’re on this panel. If you’re standing up the destination server from scratch, our notes on a fresh CyberPanel install cover the baseline we build to before any data arrives.

The cutover is a DNS problem, not a file problem

Nothing above causes downtime. Downtime comes from the half hour where half the internet thinks your site lives on the old IP and half thinks it lives on the new one, while both boxes accept writes.

The sequence we use:

Two days out. Look up the current TTL on the A records. If it’s 14400, that’s four hours, and any resolver that cached it will keep the old answer for four hours after you change anything. Drop the TTL to 300. Then wait at least one full old-TTL period before you touch anything else, or the low value hasn’t propagated and you’ve gained nothing.

One day out. Run the import onto the new box. Fix the list above. Test everything through a hosts file entry on your own machine, pointing the domain at the new IP while the world still sees the old one. Load the checkout, submit a form, trigger a password reset. This is where you find the missing PHP extension, not after the switch.

Cutover. Put the old site into read-only or maintenance mode if it takes orders. Do a final rsync of uploads and a final database dump, import both. For a 2GB site that delta pass takes us about ten minutes. Then change the A records.

The next few hours. With a 300 second TTL, most resolvers follow within five to fifteen minutes. Some ignore you. Keep the old server running and watch its access log: when it goes quiet for an hour, the stragglers are done.

Day seven. Only now decommission the old box. Mail is the reason for the wait.

Mail is the part that actually breaks

Files are idempotent. You can rsync them twice and nothing bad happens. Mail isn’t, and mail is where we’ve seen every genuine data loss on these migrations.

Between the moment you flip DNS and the moment the last resolver catches up, mail is being delivered to both servers. Messages landing on the old box after your final sync will sit there and never appear on the new one unless you go and get them.

So after the MX change settles, run an imapsync delta pass from old to new for every mailbox. It’ll skip what’s already there and pull only the strays. Run it again 24 hours later. It takes minutes and it’s the difference between a clean migration and a client discovering in March that they never received a January invoice.

The other thing to check is that the new IP isn’t carrying someone else’s reputation. A recycled VPS address can arrive pre-listed. Send a test to a Gmail and an Outlook address before you tell anyone the migration is finished, and re-check SPF, DKIM and DMARC against the new sending setup. We’ve written up what a correct SPF, DKIM and DMARC configuration looks like if any of that needs rebuilding.

Know what abort looks like

Up until the DNS change, rollback is free: the old server is still live and untouched. That’s the whole reason for the read-only window rather than a dual-write period.

After the DNS change, rollback means pointing the records back and accepting that anything written to the new box in the interim has to be carried back by hand. Which is survivable for a brochure site and genuinely painful for a store.

Our rule is that if the new box hasn’t served correctly for a full hour under real traffic, we revert rather than debug in production. The TTL is already low, so going back costs the same five minutes going forward did.

When we tell people not to bother

If you’re running one WordPress site and a mailbox, moving panels to save a licence fee isn’t worth the afternoon. Stay put.

If the old server has been compromised at some point and nobody is certain it was fully cleaned, don’t migrate it. You’ll carry the problem across intact. Build clean on the new box and move content deliberately.

And if you haven’t decided between the two panels yet, this post is the wrong one. Start with the comparison between CyberPanel and cPanel, then come back.

What it takes

A single site with one mailbox is half a day including the waiting. A 40 account reseller box is two to three days spread over a week, because the TTL and mail settling steps can’t be compressed.

We do these as part of our CyberPanel support work, which starts at $160/mo, and we’ll quote a one-off migration on the account count rather than by the hour. Either way you get the pre-cutover checklist and the old box kept warm for a week.

The panel change itself is boring. Everything above is what you’re paying for.