{"id":2026,"date":"2025-11-18T15:18:21","date_gmt":"2025-11-18T12:18:21","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/zero%e2%80%91downtime-migration-between-plesk-and-cpanel-the-calm-no%e2%80%91drama-runbook\/"},"modified":"2025-11-18T15:18:21","modified_gmt":"2025-11-18T12:18:21","slug":"zero%e2%80%91downtime-migration-between-plesk-and-cpanel-the-calm-no%e2%80%91drama-runbook","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/zero%e2%80%91downtime-migration-between-plesk-and-cpanel-the-calm-no%e2%80%91drama-runbook\/","title":{"rendered":"Zero\u2011Downtime Migration Between Plesk and cPanel: The Calm, No\u2011Drama Runbook"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" class=\"toc_transparent no_bullets\"><p class=\"toc_title\">\u0130&ccedil;indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#The_0200_Pager_That_Taught_Me_ZeroDowntime_Migrations\"><span class=\"toc_number toc_depth_1\">1<\/span> The 02:00 Pager That Taught Me Zero\u2011Downtime Migrations<\/a><\/li><li><a href=\"#Before_You_Touch_DNS_Discovery_SLOs_and_a_Clear_Exit_Strategy\"><span class=\"toc_number toc_depth_1\">2<\/span> Before You Touch DNS: Discovery, SLOs, and a Clear Exit Strategy<\/a><\/li><li><a href=\"#DNS_Without_the_Dunk_Tank_TTL_Tactics_Nameservers_and_Cutover_Flow\"><span class=\"toc_number toc_depth_1\">3<\/span> DNS Without the Dunk Tank: TTL Tactics, Nameservers, and Cutover Flow<\/a><\/li><li><a href=\"#Email_Moves_That_Dont_Lose_Mail_SPF_DKIM_DMARC_and_Queue_Drains\"><span class=\"toc_number toc_depth_1\">4<\/span> Email Moves That Don\u2019t Lose Mail: SPF, DKIM, DMARC, and Queue Drains<\/a><\/li><li><a href=\"#SSL_That_Just_Keeps_Working_ACME_CAA_and_NoDrama_Cert_Swaps\"><span class=\"toc_number toc_depth_1\">5<\/span> SSL That Just Keeps Working: ACME, CAA, and No\u2011Drama Cert Swaps<\/a><\/li><li><a href=\"#Data_Apps_and_the_Quiet_Flip_Files_Databases_and_Canary_Validation\"><span class=\"toc_number toc_depth_1\">6<\/span> Data, Apps, and the Quiet Flip: Files, Databases, and Canary Validation<\/a><\/li><li><a href=\"#The_StepbyStep_Runbook_A_Calm_Timeline_You_Can_Reuse\"><span class=\"toc_number toc_depth_1\">7<\/span> The Step\u2011by\u2011Step Runbook: A Calm Timeline You Can Reuse<\/a><\/li><li><a href=\"#Observability_Rollback_and_the_PostMigration_Debrief\"><span class=\"toc_number toc_depth_1\">8<\/span> Observability, Rollback, and the Post\u2011Migration Debrief<\/a><\/li><li><a href=\"#WrapUp_Document_Share_the_Pager_Go_Get_Some_Sleep\"><span class=\"toc_number toc_depth_1\">9<\/span> Wrap\u2011Up: Document, Share the Pager, Go Get Some Sleep<\/a><ul><li><a href=\"#Helpful_references_for_tool_specifics\"><span class=\"toc_number toc_depth_2\">9.1<\/span> Helpful references for tool specifics<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2 id=\"section-1\"><span id=\"The_0200_Pager_That_Taught_Me_ZeroDowntime_Migrations\">The 02:00 Pager That Taught Me Zero\u2011Downtime Migrations<\/span><\/h2>\n<p>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 <strong>plans<\/strong>. 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\u2019s queue doubled in three minutes. The root cause wasn\u2019t dramatic\u2014an old SPF record forgot to include the new outbound IP, DKIM selectors didn\u2019t match, and AutoSSL rate\u2011limited itself right when a wildcard needed renewal. Classic. Fixable. Avoidable.<\/p>\n<p>Here\u2019s the thing: a platform migration is never just \u201ccopy files and move DNS.\u201d 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\u2019ll walk you through a step\u2011by\u2011step plan I\u2019ve used in on\u2011call rotations and compliance audits to migrate between Plesk and cPanel with <strong>zero downtime<\/strong> for HTTP and <strong>zero lost mail<\/strong>. We\u2019ll talk TTL tactics, dual\u2011delivery 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.<\/p>\n<h2 id=\"section-2\"><span id=\"Before_You_Touch_DNS_Discovery_SLOs_and_a_Clear_Exit_Strategy\">Before You Touch DNS: Discovery, SLOs, and a Clear Exit Strategy<\/span><\/h2>\n<p>Every calm cutover starts like a blameless post\u2011mortem: with discovery, not heroics. I start by asking three questions. First, what\u2019s the SLO? If we promise 99.9% monthly, our error budget is about 43 minutes. That\u2019s the redline. Second, which workloads are most fragile\u2014mail, dynamic PHP, or admin panels? Third, what\u2019s the rollback in under five minutes, no approvals needed? If it isn\u2019t reversible in five minutes, it isn\u2019t ready.<\/p>\n<p>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\u2019t 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.<\/p>\n<p>Measure the baseline so you know when you\u2019re regressing. Capture p50\/p95 web latency, 5xx rates, SMTP 4xx\/5xx counts, mail queue depth, and IMAP login times during normal traffic. You need <strong>numbers<\/strong> you can point to during the cutover. A single graph that says \u201cwe\u2019re fine\u201d beats ten hopeful messages in Slack.<\/p>\n<h2 id=\"section-3\"><span id=\"DNS_Without_the_Dunk_Tank_TTL_Tactics_Nameservers_and_Cutover_Flow\">DNS Without the Dunk Tank: TTL Tactics, Nameservers, and Cutover Flow<\/span><\/h2>\n<p>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 <em>without<\/em> delegating. Publish means you reduce TTLs and pre\u2011announce new endpoints. Drain means you move the apex and monitor, while keeping old endpoints alive long enough to catch stragglers.<\/p>\n<p>Two days before cutover, lower TTLs for A\/AAAA, CNAMEs, MX, and TXT that you intend to change to 300 seconds. Don\u2019t touch nameserver records yet; registrar glue changes take longer and offer no benefit mid\u2011migration. If your current DNS host is Plesk and you\u2019re moving to cPanel DNSOnly, replicate zones ahead of time and validate them by querying the new authoritative servers directly without delegation.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig @new-auth-ns1.example.net example.com A +nocmd +noall +answer\n dig @new-auth-ns1.example.net www.example.com CNAME +noall +answer\n dig @new-auth-ns1.example.net example.com MX +noall +answer<\/code><\/pre>\n<p>While we\u2019re 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.<\/p>\n<p>On cutover day, change the A\/AAAA for the web endpoints first. Keep the Plesk web still serving and healthy; we\u2019re not powering anything down. Validate from multiple vantage points. A good quick\u2011and\u2011dirty check is to curl from a few cloud regions:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -sS -o \/dev\/null -w &quot;%{remote_ip} %{http_code} %{time_total}n&quot; https:\/\/www.example.com<\/code><\/pre>\n<p>If you see both Plesk and cPanel IPs during the 5\u201315 minutes after cutover, that\u2019s 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\u2014start with low\u2011traffic paths, then the homepage, then the whole zone if needed.<\/p>\n<p>Nameserver delegation moves last, and only if you\u2019re changing DNS providers. When you do, update at the registrar, then watch for traffic shift by querying public resolvers with +trace. If you aren\u2019t changing DNS providers, skip this and keep life simple.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">dig +trace example.com | sed -n '1,200p'<\/code><\/pre>\n<h2 id=\"section-4\"><span id=\"Email_Moves_That_Dont_Lose_Mail_SPF_DKIM_DMARC_and_Queue_Drains\">Email Moves That Don\u2019t Lose Mail: SPF, DKIM, DMARC, and Queue Drains<\/span><\/h2>\n<p>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 <strong>new outbound IPs<\/strong> to SPF <em>before<\/em> you switch anything. If your current record is tight, extend it a week early so reputation builds. Keep it under the 10\u2011lookup 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\u2011publish 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.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># SPF sanity checks\n dig TXT example.com +short | tr -d '&quot;'\n spfquery --scope mfrom --identity postmaster@example.com --ip 203.0.113.25<\/code><\/pre>\n<p>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.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Check queues during cutover\n postqueue -p | tail -n +2 | awk '{print $5}' | sort | uniq -c | sort -nr\n exim -bpr | exiqsumm | head<\/code><\/pre>\n<p>To move mailboxes without user pain, I rely on <em>imapsync<\/em> in two passes: a long pre\u2011sync days before, and a short delta sync during cutover. Throttle so you don\u2019t murder disks. If you have 2 TB mail stores, segment by department or domain to keep charts predictable.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">imapsync \n  --host1 mail.plesk.example.com --user1 alice --password1 'oldpass' \n  --host2 mail.cpanel.example.com --user2 alice --password2 'newpass' \n  --ssl1 --ssl2 --authmech1 LOGIN --authmech2 LOGIN \n  --automap --skipsize --nofoldersizes --useheader 'Message-Id' \n  --addheader --regextrans2 's,Sent,Sent Items,' \n  --regextrans2 's,INBOX.Drafts,Drafts,'<\/code><\/pre>\n<p>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:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">openssl s_client -starttls smtp -connect mail.example.com:587 -servername mail.example.com &lt; \/dev\/null | grep -E &quot;subject=|issuer=|Verify&quot;<\/code><\/pre>\n<p>Finally, deliverability doesn\u2019t end at DNS. Reinforce transport security by publishing MTA\u2011STS and TLS\u2011RPT, and consider DANE if your registrar supports DNSSEC. If you want a friendly deep dive into that operational playbook, this explainer on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91postada-mta%e2%80%91sts-tls%e2%80%91rpt-ve-dane-teslim-edilebilirligi-nasil-tatli-tatli-yukseltirsin\/\">MTA\u2011STS, TLS\u2011RPT, and DANE for email deliverability and security<\/a> will save you a few midnight incidents. And if mail forwarding is part of your world, don\u2019t let SPF\/DMARC break your day; Sender Rewriting Scheme and ARC are your lifelines\u2014see this friendly guide on <a href=\"https:\/\/www.dchost.com\/blog\/en\/e%e2%80%91posta-yonlendirmede-spf-dmarc-neden-kiriliyor-srs-ve-arc-ile-nasil-tatli-tatli-onarirsin\/\">how SRS and ARC keep forwarding from wrecking your authentication<\/a>.<\/p>\n<h2 id=\"section-5\"><span id=\"SSL_That_Just_Keeps_Working_ACME_CAA_and_NoDrama_Cert_Swaps\">SSL That Just Keeps Working: ACME, CAA, and No\u2011Drama Cert Swaps<\/span><\/h2>\n<p>Certs are where migrations quietly go sideways. Users won\u2019t see broken CSS, they\u2019ll 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.<\/p>\n<p>First, pre\u2011publish CAA records that allow both your current CA and your future CA for at least a week. If you\u2019re switching from Plesk\u2019s Let\u2019s Encrypt extension to cPanel AutoSSL with Let\u2019s Encrypt or another CA, publish both issuers so renewals don\u2019t hit a 403 from your own DNS. If you\u2019re curious about multi\u2011CA strategies, here\u2019s a practical deep dive on <a href=\"https:\/\/www.dchost.com\/blog\/en\/caa-kayitlari-derinlemesine-neden-nasil-ve-ne-zaman-coklu%e2%80%91caya-gecmelisin\/\">CAA records and how to run a multi\u2011CA strategy without chaos<\/a>.<\/p>\n<p>Second, choose the right ACME challenge. If your web path is complex\u2014reverse proxies, redirects, WAFs\u2014DNS\u201101 avoids those gremlins and is wonderful for wildcards. HTTP\u201101 is fine for simple cases if you can guarantee .well\u2011known paths. If you want a crisp primer on when to pick which, this <a href=\"https:\/\/www.dchost.com\/blog\/en\/acme-challenge-turleri-derinlemesine-http%e2%80%9101-dns%e2%80%9101-ve-tls%e2%80%91alpn%e2%80%9101-ne-zaman-hangisi\/\">ACME challenges deep dive<\/a> gives you the operational tradeoffs in plain language.<\/p>\n<p>Third, if you want a guaranteed zero\u2011drama 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\u2011risk window. Watch rate limits; Let\u2019s Encrypt is generous but not infinite. Keep an eye on the issuance counters if you run a fleet. Their summary of limits is here: <a href=\"https:\/\/letsencrypt.org\/docs\/rate-limits\/\" rel=\"nofollow noopener\" target=\"_blank\">Let\u2019s Encrypt rate limits explained<\/a>.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Quick cert fingerprint check before and after\n openssl x509 -noout -fingerprint -sha256 -in current.pem\n openssl s_client -connect www.example.com:443 -servername www.example.com &lt; \/dev\/null 2&gt;\/dev\/null \n   | openssl x509 -noout -fingerprint -sha256<\/code><\/pre>\n<p>On cPanel, AutoSSL is convenient, but I prefer explicit control for apex + wildcard with DNS\u201101 in complex shops. The outcome should be simple: same SANs, unbroken chains, a stable OCSP response, and a monitoring check that fails loudly <em>before<\/em> expiry, not after. If your site sends HSTS, don\u2019t change HSTS max\u2011age until after you\u2019ve validated multi\u2011region handshakes on the new host.<\/p>\n<h2 id=\"section-6\"><span id=\"Data_Apps_and_the_Quiet_Flip_Files_Databases_and_Canary_Validation\">Data, Apps, and the Quiet Flip: Files, Databases, and Canary Validation<\/span><\/h2>\n<p>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.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Files: preserve ownership, hardlinks, xattrs; throttle with --bwlimit if needed\n rsync -aHAX --numeric-ids --delete --info=stats2 \n   -e 'ssh -o StrictHostKeyChecking=no' \n   root@plesk:\/var\/www\/vhosts\/example.com\/httpdocs\/ \n   root@cpanel:\/home\/example\/public_html\/\n\n# MySQL\/MariaDB: point-in-time safe logical copy\n mysqldump --single-transaction --routines --triggers --hex-blob \n   -h plesk-db -uexporter -p'STRONGPASS' exampledb \n   | mysql -h cpanel-db -uroot -p exampledb<\/code><\/pre>\n<p>For big datasets, rehearse with a subset first. When we replatformed an ISP\u2019s 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.<\/p>\n<p>Account\u2011level moves are fine too. On Plesk, make a domain backup; on cPanel, restore the package. Keep it boring.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Plesk backup (domain level)\n plesk bin pleskbackup --domains-name example.com --output-file \/root\/example.com.backup\n\n# cPanel restore of a pkgacct archive\n \/scripts\/pkgacct example\n \/scripts\/restorepkg \/home\/cpmove-example.tar.gz<\/code><\/pre>\n<p>Once hydrated, run a synthetic canary. Curl the top 10 pages, exercise checkout if you have e\u2011commerce, 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.<\/p>\n<h2 id=\"section-7\"><span id=\"The_StepbyStep_Runbook_A_Calm_Timeline_You_Can_Reuse\">The Step\u2011by\u2011Step Runbook: A Calm Timeline You Can Reuse<\/span><\/h2>\n<p>I like timelines because they turn anxiety into intention. Here\u2019s the cadence I hand to the team, with stages you can check off in a war room.<\/p>\n<p>At T\u20117 days, baseline everything. Archive current zones to Git. Pre\u2011publish new DKIM selectors if you\u2019re 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\u2011STS, publish a testing mode policy.<\/p>\n<p>At T\u201148 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\u2019t force renewal yet. Create a <em>temporary<\/em> hostname for the old mail host (e.g., mail-legacy.example.com) so staff can reach it after cutover if needed.<\/p>\n<p>At T\u201124 hours, run the first imapsync pass for all mailboxes; keep IMAP open counts in your monitoring so you don\u2019t hit connection limits. Rehearse a restore from your latest backups\u2014yes, 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.<\/p>\n<p>At T\u20112 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\u2019t post it yet. Confirm all owners can be paged.<\/p>\n<p>At T\u20110, 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 <em>imapsync<\/em> to catch late changes.<\/p>\n<p>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\u2019re golden. If you run MTA\u2011STS, confirm the policy is present and fetchable by remote MTAs.<\/p>\n<p>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 <em>AutoSSL<\/em> into a cadence you trust and remove the extra CAA issuers if that was a temporary phase.<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># Quick mail auth check after flip\n swaks --to you@example.com --server mail.example.com --tls --auth LOGIN \n   --auth-user alice --auth-password 'newpass' --data 'Subject: cutover testnnhello'<\/code><\/pre>\n<h2 id=\"section-8\"><span id=\"Observability_Rollback_and_the_PostMigration_Debrief\">Observability, Rollback, and the Post\u2011Migration Debrief<\/span><\/h2>\n<p>Great migrations don\u2019t 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.<\/p>\n<p>Rollback is not a feeling; it\u2019s 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\u2019re just redirecting traffic like a good air traffic controller. Keep the rollback checklist one click away and write it in verbs, not nouns.<\/p>\n<p>Once you\u2019re 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\u2011ups, and schedule the clean\u2011up window so tech debt doesn\u2019t linger. If you want extra defense\u2011in\u2011depth on publication paths, or you run multiple CAs across brands and sub\u2011brands, revisiting your CAA and ACME approach will pay compound interest over time. I\u2019ve 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 <a href=\"https:\/\/www.dchost.com\/blog\/en\/vpste-canary-dagitimi-nasil-tatli-tatli-kurulur-nginx-agirlikli-yonlendirme-saglik-kontrolu-ve-guvenli-rollback\/\">canary deploys with weighted routing and safe rollbacks<\/a>.<\/p>\n<h2 id=\"section-9\"><span id=\"WrapUp_Document_Share_the_Pager_Go_Get_Some_Sleep\">Wrap\u2011Up: Document, Share the Pager, Go Get Some Sleep<\/span><\/h2>\n<p>Zero\u2011downtime migrations aren\u2019t magic; they\u2019re 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.<\/p>\n<p>Turn this article into your team\u2019s 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\u2011critical for your business, reinforce it with transport security and smart forwarding practices\u2014your 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.<\/p>\n<h3><span id=\"Helpful_references_for_tool_specifics\">Helpful references for tool specifics<\/span><\/h3>\n<p>If you prefer vendor docs for the transfer mechanics, the high\u2011level flow here maps cleanly to Plesk Migrator\u2019s overview at <a href=\"https:\/\/docs.plesk.com\/en-US\/obsidian\/administrator-guide\/plesk-migrator-guide\/overview.74669\/\" rel=\"nofollow noopener\" target=\"_blank\">Plesk Migrator guide<\/a> and WHM\u2019s transfer tooling at <a href=\"https:\/\/docs.cpanel.net\/whm\/transfers\/transfer-tool\/\" rel=\"nofollow noopener\" target=\"_blank\">cPanel Transfer Tool<\/a>. Use them for screen\u2011by\u2011screen guidance; keep this runbook for the sequencing and safety nets.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>\u0130&ccedil;indekiler1 The 02:00 Pager That Taught Me Zero\u2011Downtime Migrations2 Before You Touch DNS: Discovery, SLOs, and a Clear Exit Strategy3 DNS Without the Dunk Tank: TTL Tactics, Nameservers, and Cutover Flow4 Email Moves That Don\u2019t Lose Mail: SPF, DKIM, DMARC, and Queue Drains5 SSL That Just Keeps Working: ACME, CAA, and No\u2011Drama Cert Swaps6 Data, [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":2027,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[32,33,25],"tags":[],"class_list":["post-2026","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-alan-adi","category-nasil-yapilir","category-sunucu"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2026","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=2026"}],"version-history":[{"count":0,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/2026\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/2027"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=2026"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=2026"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=2026"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}