Zero‑Downtime Migration Between Plesk and cPanel: The Calm, No‑Drama Runbook

The 02:00 Pager That Taught Me Zero‑Downtime Migrations

My pager screamed at 02:00 during a weekend maintenance we swore would be invisible. We had lowered TTLs, we had doubled instances, we had plans. And yet, five minutes after we flipped MX, my dashboard lit up: SMTP 421 spikes, p95 latency on web jumped from 220 ms to 630 ms, and the helpdesk’s queue doubled in three minutes. The root cause wasn’t dramatic—an old SPF record forgot to include the new outbound IP, DKIM selectors didn’t match, and AutoSSL rate‑limited itself right when a wildcard needed renewal. Classic. Fixable. Avoidable.

Here’s the thing: a platform migration is never just “copy files and move DNS.” Between Plesk and cPanel, the art is in sequencing. DNS without cache traps. Email without lost mail. SSL without that cold, quiet handshake failure at 03:00 that ruins your night. Today I’ll walk you through a step‑by‑step plan I’ve used in on‑call rotations and compliance audits to migrate between Plesk and cPanel with zero downtime for HTTP and zero lost mail. We’ll talk TTL tactics, dual‑delivery mail, ACME choices, and how to watch the right graphs so your error budget stays green. Ever had a canary fail while customers refresh your status page? This runbook prevents that.

Before You Touch DNS: Discovery, SLOs, and a Clear Exit Strategy

Every calm cutover starts like a blameless post‑mortem: with discovery, not heroics. I start by asking three questions. First, what’s the SLO? If we promise 99.9% monthly, our error budget is about 43 minutes. That’s the redline. Second, which workloads are most fragile—mail, dynamic PHP, or admin panels? Third, what’s the rollback in under five minutes, no approvals needed? If it isn’t reversible in five minutes, it isn’t ready.

Inventory is the next mile. On Plesk, list domains, subdomains, service domains, and mailboxes. Identify PHP versions per subscription, custom Apache directives, any Nginx proxy tweaks, and cron jobs. Tag databases by size and engine, note largest tables, and document backup windows so you don’t collide with snapshot jobs. Extract current DNS records, especially TXT. I keep a sanitized JSON of every zone so differences are visible in Git. On cPanel, prepare matching accounts, packages, and feature lists to avoid surprise resource limits.

Measure the baseline so you know when you’re regressing. Capture p50/p95 web latency, 5xx rates, SMTP 4xx/5xx counts, mail queue depth, and IMAP login times during normal traffic. You need numbers you can point to during the cutover. A single graph that says “we’re fine” beats ten hopeful messages in Slack.

DNS Without the Dunk Tank: TTL Tactics, Nameservers, and Cutover Flow

DNS is your air traffic control. Treat it with the same discipline you use for database schema changes. The plan has three parts: stage, publish, and drain. Stage means you prepare your future records on the new provider without delegating. Publish means you reduce TTLs and pre‑announce new endpoints. Drain means you move the apex and monitor, while keeping old endpoints alive long enough to catch stragglers.

Two days before cutover, lower TTLs for A/AAAA, CNAMEs, MX, and TXT that you intend to change to 300 seconds. Don’t touch nameserver records yet; registrar glue changes take longer and offer no benefit mid‑migration. If your current DNS host is Plesk and you’re moving to cPanel DNSOnly, replicate zones ahead of time and validate them by querying the new authoritative servers directly without delegation.

dig @new-auth-ns1.example.net example.com A +nocmd +noall +answer
 dig @new-auth-ns1.example.net www.example.com CNAME +noall +answer
 dig @new-auth-ns1.example.net example.com MX +noall +answer

While we’re here, assure yourself that the old and new zones match where they should. I like a simple diff from exported BIND zone files. Watch out for stray AAAA records that point to deprecated IPv6 ranges; IPv6 can be silent but deadly if forgotten.

On cutover day, change the A/AAAA for the web endpoints first. Keep the Plesk web still serving and healthy; we’re not powering anything down. Validate from multiple vantage points. A good quick‑and‑dirty check is to curl from a few cloud regions:

curl -sS -o /dev/null -w "%{remote_ip} %{http_code} %{time_total}n" https://www.example.com

If you see both Plesk and cPanel IPs during the 5–15 minutes after cutover, that’s fine. Your goal is a flat 200 status, p95 latency within 20% of baseline, and zero increase in 5xx. If you have a CDN in front, purge caches with a stagger, not a bomb—start with low‑traffic paths, then the homepage, then the whole zone if needed.

Nameserver delegation moves last, and only if you’re changing DNS providers. When you do, update at the registrar, then watch for traffic shift by querying public resolvers with +trace. If you aren’t changing DNS providers, skip this and keep life simple.

dig +trace example.com | sed -n '1,200p'

Email Moves That Don’t Lose Mail: SPF, DKIM, DMARC, and Queue Drains

Email is where migrations go to die if you treat it like web. The secrets: publish before you send, accept mail on both sides, and drain slowly. First, add the new outbound IPs to SPF before you switch anything. If your current record is tight, extend it a week early so reputation builds. Keep it under the 10‑lookup limit; consolidate where possible. Second, decide DKIM strategy. If your brand lives in strict DMARC, copy the existing DKIM keys to cPanel using the same selectors, or pre‑publish a new selector alongside the old and rotate later. Third, set DMARC to quarantine or none during the week of migration if you expect alignment churn.

# SPF sanity checks
 dig TXT example.com +short | tr -d '"'
 spfquery --scope mfrom --identity [email protected] --ip 203.0.113.25

For inbound, run both MTAs in parallel for a short window. Publish two MX records: the new cPanel host with the lowest preference (smallest number), and the old Plesk host as a slightly higher preference. Many senders will pick the best preference first, but failover keeps safety nets intact. I also like an explicit SMTP proxy or transport map for internal routes while things settle.

# Check queues during cutover
 postqueue -p | tail -n +2 | awk '{print $5}' | sort | uniq -c | sort -nr
 exim -bpr | exiqsumm | head

To move mailboxes without user pain, I rely on imapsync in two passes: a long pre‑sync days before, and a short delta sync during cutover. Throttle so you don’t murder disks. If you have 2 TB mail stores, segment by department or domain to keep charts predictable.

imapsync 
  --host1 mail.plesk.example.com --user1 alice --password1 'oldpass' 
  --host2 mail.cpanel.example.com --user2 alice --password2 'newpass' 
  --ssl1 --ssl2 --authmech1 LOGIN --authmech2 LOGIN 
  --automap --skipsize --nofoldersizes --useheader 'Message-Id' 
  --addheader --regextrans2 's,Sent,Sent Items,' 
  --regextrans2 's,INBOX.Drafts,Drafts,'

During the flip, point IMAP/SMTP hostnames (mail.example.com) to the new host while keeping the old host reachable by a temporary name. Keep both SMTP daemons accepting mail for at least 24 hours. Watch TLS: STARTTLS should present a valid SAN for mail.example.com. Verify quickly:

openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com < /dev/null | grep -E "subject=|issuer=|Verify"

Finally, deliverability doesn’t end at DNS. Reinforce transport security by publishing MTA‑STS and TLS‑RPT, and consider DANE if your registrar supports DNSSEC. If you want a friendly deep dive into that operational playbook, this explainer on MTA‑STS, TLS‑RPT, and DANE for email deliverability and security will save you a few midnight incidents. And if mail forwarding is part of your world, don’t let SPF/DMARC break your day; Sender Rewriting Scheme and ARC are your lifelines—see this friendly guide on how SRS and ARC keep forwarding from wrecking your authentication.

SSL That Just Keeps Working: ACME, CAA, and No‑Drama Cert Swaps

Certs are where migrations quietly go sideways. Users won’t see broken CSS, they’ll see a red lock and a bounced sales call. We keep SSL calm with three moves: control the CA path, choose the right ACME challenge, and rehearse renewals.

First, pre‑publish CAA records that allow both your current CA and your future CA for at least a week. If you’re switching from Plesk’s Let’s Encrypt extension to cPanel AutoSSL with Let’s Encrypt or another CA, publish both issuers so renewals don’t hit a 403 from your own DNS. If you’re curious about multi‑CA strategies, here’s a practical deep dive on CAA records and how to run a multi‑CA strategy without chaos.

Second, choose the right ACME challenge. If your web path is complex—reverse proxies, redirects, WAFs—DNS‑01 avoids those gremlins and is wonderful for wildcards. HTTP‑01 is fine for simple cases if you can guarantee .well‑known paths. If you want a crisp primer on when to pick which, this ACME challenges deep dive gives you the operational tradeoffs in plain language.

Third, if you want a guaranteed zero‑drama swap, export the current cert and private key from Plesk and import into cPanel ahead of the flip so the SANs remain identical. Then schedule a renewal rehearsal on cPanel during a low‑risk window. Watch rate limits; Let’s Encrypt is generous but not infinite. Keep an eye on the issuance counters if you run a fleet. Their summary of limits is here: Let’s Encrypt rate limits explained.

# Quick cert fingerprint check before and after
 openssl x509 -noout -fingerprint -sha256 -in current.pem
 openssl s_client -connect www.example.com:443 -servername www.example.com < /dev/null 2>/dev/null 
   | openssl x509 -noout -fingerprint -sha256

On cPanel, AutoSSL is convenient, but I prefer explicit control for apex + wildcard with DNS‑01 in complex shops. The outcome should be simple: same SANs, unbroken chains, a stable OCSP response, and a monitoring check that fails loudly before expiry, not after. If your site sends HSTS, don’t change HSTS max‑age until after you’ve validated multi‑region handshakes on the new host.

Data, Apps, and the Quiet Flip: Files, Databases, and Canary Validation

Between Plesk and cPanel, the busiest lift is content and databases. I treat it like blue/green: hydrate the new environment, sync changes, and cut traffic gradually. For websites, rsync preserves permissions and extended attributes; for databases, use consistent snapshots or logical dumps with flags that protect integrity.

# Files: preserve ownership, hardlinks, xattrs; throttle with --bwlimit if needed
 rsync -aHAX --numeric-ids --delete --info=stats2 
   -e 'ssh -o StrictHostKeyChecking=no' 
   root@plesk:/var/www/vhosts/example.com/httpdocs/ 
   root@cpanel:/home/example/public_html/

# MySQL/MariaDB: point-in-time safe logical copy
 mysqldump --single-transaction --routines --triggers --hex-blob 
   -h plesk-db -uexporter -p'STRONGPASS' exampledb 
   | mysql -h cpanel-db -uroot -p exampledb

For big datasets, rehearse with a subset first. When we replatformed an ISP’s shared hosting cluster, we shaved p95 from 480 ms to 310 ms simply by warming opcache and preloading the top 50 PHP endpoints during the last sync. Heat your caches before you invite real traffic; your error budget will thank you.

Account‑level moves are fine too. On Plesk, make a domain backup; on cPanel, restore the package. Keep it boring.

# Plesk backup (domain level)
 plesk bin pleskbackup --domains-name example.com --output-file /root/example.com.backup

# cPanel restore of a pkgacct archive
 /scripts/pkgacct example
 /scripts/restorepkg /home/cpmove-example.tar.gz

Once hydrated, run a synthetic canary. Curl the top 10 pages, exercise checkout if you have e‑commerce, open IMAP folders with a small script, and send a test mail through the new outbound IP. Your definition of done is boring: same headers, same payload, marginally better latency. If the new host is consistently slower by more than 20%, fix that before DNS moves.

The Step‑by‑Step Runbook: A Calm Timeline You Can Reuse

I like timelines because they turn anxiety into intention. Here’s the cadence I hand to the team, with stages you can check off in a war room.

At T‑7 days, baseline everything. Archive current zones to Git. Pre‑publish new DKIM selectors if you’re rotating. Add new outbound IPs to SPF; keep the lookup count within budget. Publish permissive CAA to include both current and future CAs. If you plan MTA‑STS, publish a testing mode policy.

At T‑48 hours, drop TTLs for the records you will change to 300 seconds. Hydrate content to cPanel with rsync and database snapshot. Stand up mailboxes and aliases. Generate or import SSLs on cPanel so SANs match. Enable AutoSSL if you will rely on it, but don’t force renewal yet. Create a temporary hostname for the old mail host (e.g., mail-legacy.example.com) so staff can reach it after cutover if needed.

At T‑24 hours, run the first imapsync pass for all mailboxes; keep IMAP open counts in your monitoring so you don’t hit connection limits. Rehearse a restore from your latest backups—yes, a real one. If compliance matters, capture a screenshot of the restore succeeding. Run a cert chain check against both environments; confirm OCSP is valid. Verify that DMARC aggregate reports are still arriving.

At T‑2 hours, start a change window. Freeze content updates or put them behind a feature flag. Warm caches on cPanel. Validate web, mail, and database health checks every five minutes. If you use status pages, prep a message but don’t post it yet. Confirm all owners can be paged.

At T‑0, change A/AAAA for web endpoints to cPanel. Watch p95, 5xx, and error density for at least 15 minutes. If healthy, update the IMAP/SMTP hostname to the new IP. Publish MX with the new host as primary and the old as secondary. Leave the old host accepting inbound mail for at least 24 hours. Run the delta imapsync to catch late changes.

At T+2 hours, verify mail flow and auth. Send from a few providers to your domain. Check that SPF passes (pass or softfail expected), DKIM aligns, DMARC policy applied. Verify STARTTLS with the right cert. Scan queues on both sides; if the old host is draining cleanly, you’re golden. If you run MTA‑STS, confirm the policy is present and fetchable by remote MTAs.

At T+24 to T+48 hours, if everything is clean, retire the old inbound MX and remove the temporary hostname. Rotate DKIM to the new selectors if you introduced them. Adjust TTLs back to sane values. Lock AutoSSL into a cadence you trust and remove the extra CAA issuers if that was a temporary phase.

# Quick mail auth check after flip
 swaks --to [email protected] --server mail.example.com --tls --auth LOGIN 
   --auth-user alice --auth-password 'newpass' --data 'Subject: cutover testnnhello'

Observability, Rollback, and the Post‑Migration Debrief

Great migrations don’t feel heroic because the graphs tell the story before chat does. During the flip, I keep four widgets in view: HTTP p95 latency, 5xx error rate, SMTP 4xx/5xx counts, and mail queue depth. I also watch DNS query hits for the old and new IPs so I know when caches have decayed. If your p95 goes red by 20% for more than five minutes, you either scale or roll back. No debate, no shame. Your error budget buys you patience, not stubbornness.

Rollback is not a feeling; it’s a command. If the web goes sideways, restore the old A/AAAA and keep TTL at 300. If mail delivery misbehaves, elevate the old MX to primary again while you debug. Because you kept the old host accepting inbound, nothing is lost; you’re just redirecting traffic like a good air traffic controller. Keep the rollback checklist one click away and write it in verbs, not nouns.

Once you’re steady, debrief. What surprised you? Which alert fired early and helped? Which one was noisy and needs a better threshold? Capture the Knowledge, assign owners for follow‑ups, and schedule the clean‑up window so tech debt doesn’t linger. If you want extra defense‑in‑depth on publication paths, or you run multiple CAs across brands and sub‑brands, revisiting your CAA and ACME approach will pay compound interest over time. I’ve also had teams use a light canary DNS split to vet performance, similar to how we route weighted traffic in application rollouts; if that interests you, the approach is a cousin of the techniques in our guide to canary deploys with weighted routing and safe rollbacks.

Wrap‑Up: Document, Share the Pager, Go Get Some Sleep

Zero‑downtime migrations aren’t magic; they’re choreography. You gather facts, you shape traffic, you move slow at the right moments and fast at the decisive ones. Between Plesk and cPanel, the playbook stays consistent: lower TTLs days ahead, hydrate data until the last minute, publish SPF/DKIM/DMARC early, keep both MTAs alive during the handoff, and make SSL boring by rehearsing CAA and ACME choices before the curtain rises. You watch p95 like a hawk and you treat rollback as part of success, not failure.

Turn this article into your team’s runbook. Put the commands in a private repo, wrap a few of them in scripts, and attach dashboards to each phase so everyone sees the same truth. If email is mission‑critical for your business, reinforce it with transport security and smart forwarding practices—your future self will thank you. And finally, rotate the pager and take a breath. Good ops is a team sport. Document what you learned, leave breadcrumbs for the next person, and get some sleep. You earned it.

Helpful references for tool specifics

If you prefer vendor docs for the transfer mechanics, the high‑level flow here maps cleanly to Plesk Migrator’s overview at Plesk Migrator guide and WHM’s transfer tooling at cPanel Transfer Tool. Use them for screen‑by‑screen guidance; keep this runbook for the sequencing and safety nets.