Migration
adminbolt team20 min read

How to Move Hosting Accounts from cPanel to Plesk Without Downtime

How to Move Hosting Accounts from cPanel to Plesk Without Downtime

How to Move Hosting Accounts from cPanel to Plesk Without Downtime

Moving hosting accounts between control panels is one of the highest-stakes operations in hosting infrastructure. One miscalculated cutover, one DNS glitch, or one missed email, and your customer SLAs evaporate. This playbook walks you through a production-grade migration strategy that keeps all services live during the transition-no maintenance windows, no customer-facing downtime, no "sorry, we're back online at 3 AM" messages.

The core pattern is straightforward: run parallel infrastructure, establish dual-write DNS, collapse TTLs, validate thoroughly, flip traffic, then decommission the legacy system. What separates a botched migration from a transparent one is discipline in execution and contingency planning. This guide covers both.

By the end of this runbook, you'll have a repeatable, testable process for moving cPanel customers to Plesk at scale, whether you're migrating 10 accounts or 10,000.

Why Operators Move from cPanel to Plesk

Cross-platform flexibility. cPanel runs only on Linux. Plesk runs on both Linux and Windows Server, letting you consolidate infrastructure or serve Windows-only workloads (ASP.NET, SQL Server) without separate billing models.

WordPress Toolkit. Plesk's native WordPress plugin manager, staging environment generator, and one-click patching are unmatched. For shops with heavy WordPress portfolios, this alone justifies the move.

Edition flexibility and cost control. Plesk Web Admin ($9.90/mo, 10 domains), Web Pro ($15.26/mo, 30 domains), and Web Host ($25.16/mo, unlimited domains) let you right-size licensing. cPanel's tiered model (Solo $26.99/mo for 1 account, Admin $32.99/mo for 5 accounts, Pro $46.99/mo for 30 accounts, Premier $65.99/mo for 100 accounts) with $0.30/account overages incentivizes bundling accounts per tier, not per-server economics.

Modern architecture. Plesk's REST API, container-ready design, and cloud-native tooling fit modern deployment patterns better than cPanel's aging codebase.

Understanding Plesk Migrator: What It Does Well and Where It Falls Short

Plesk Migrator is Plesk's official migration tool. It automates account cloning, file transfer, database migration, and mail account creation. However:

Strengths:

  • Handles file transfer, MySQL databases, and standard mail accounts reliably.
  • One-click setup; minimal manual intervention.
  • Built-in source server connectivity and validation.

Limitations:

  • Doesn't move mail content-only account metadata.
  • SSL certificate handling is manual (Let's Encrypt must be re-issued; custom certs require manual import).
  • No native support for cPanel-specific features (AutoSSL, cron monitoring, UAPI callbacks).
  • Database locks during full MySQL dumps on large DBs (no low-lock methodology).
  • WHMCS integration requires manual provisioning module reconfiguration.
  • Single-threaded on source; migration speed is I/O-bound.

The real gap: Plesk Migrator is a file and account synchronizer, not a zero-downtime orchestrator. You'll use it, but you'll wrap it in parallel infrastructure and cutover discipline.

The Zero-Downtime Pattern: Parallel Infrastructure, Dual-Write DNS, TTL Collapse, Validate, Flip

This is the mental model. All the steps that follow map to this framework:

  1. Parallel infrastructure. Plesk server is provisioned, hardened, and validated in parallel to production cPanel infrastructure. Customers remain on cPanel.
  2. Dual-write DNS. During the migration window, DNS records point to both cPanel (primary) and Plesk (secondary). Most requests hit cPanel; some hit Plesk for validation.
  3. TTL collapse. 24-48 hours before cutover, reduce DNS TTL from 86400 (1 day) to 300 (5 minutes). Caches flush faster; traffic re-routes quicker.
  4. Validation. Run smoke tests: HTTP requests, mail send/receive, database queries, cron execution. All must pass on Plesk while cPanel remains primary.
  5. Traffic flip. Atomically swap DNS primary/secondary. Plesk becomes primary; cPanel becomes read-only backup.
  6. Decommission. After 1-2 weeks of rollback window, shut down cPanel accounts.

This pattern means no scheduled downtime announcement, no customer impact, and a quick rollback if things go wrong.

Pre-Migration Audit: Build Your Scope Document

Before touching infrastructure, audit each account:

  • Account type. Single domain or multisite (addon/parked domains)?
  • DNS configuration. cPanel-hosted or external (Route 53, Cloudflare)?
  • Mail setup. How many mailboxes? Forwarders? Distribution lists?
  • SSL certificates. Auto-renewing (AutoSSL)? Custom (EV, wildcard)? Let's Encrypt?
  • Databases. MySQL only, or PostgreSQL? Size? Transactional or analytical?
  • Cron jobs. Scheduled tasks? WHMCS callbacks? Backup scripts?
  • Custom scripts. Shell scripts, custom cPanel plugins, hooks in cPanel API?
  • Rewrite rules. .htaccess complexity? NGINX configs?
  • Disk usage. Estimate time to initial transfer and whether incremental sync is needed.

Document everything in a CSV: account name, owner, status (active/dormant), complexity level (low/medium/high). This becomes your migration manifest.

Parallel Server Provisioning and Plesk Installation Hardening

Step 1: Provision new Plesk server.

Spin up a server with identical or greater specs than your cPanel infrastructure. OS: AlmaLinux 9 or Ubuntu 22.04 LTS (avoid CentOS 8; it's EOL).

sudo dnf update -y
sudo dnf install -y fail2ban htop iotop nethogs
sudo systemctl enable fail2ban

Step 2: Install Plesk.

ssh root@<plesk-server-ip>
curl https://installer.plesk.com/plesk-installer | sudo bash
sudo plesk-installer install release=latest

Choose your edition (Web Professional recommended for shared hosting). Plesk will auto-detect OS and install compatible components.

Step 3: Post-install hardening.

# Disable autossl (you'll issue manually during migration)
plesk bin extension --disable-sharing autossl

# Configure firewall for Plesk services only
sudo firewall-cmd --permanent --add-service http
sudo firewall-cmd --permanent --add-service https
sudo firewall-cmd --permanent --add-port 8443/tcp  # Plesk admin panel
sudo firewall-cmd --reload

# Set IP whitelist for Plesk panel (your office/VPN IPs only)
plesk bin ipmanage -i <your-ip> -set Administrator

Step 4: Configure mail, backups, and licensing.

  • Connect mail server (Postfix/Dovecot auto-configured; just validate SPF/DKIM).
  • Set backup destination (S3 bucket recommended; mount via s3fs).
  • Activate Plesk license.

Step 5: Create DNS zones and A records.

In Plesk, create placeholder DNS zones for each account before Plesk Migrator runs. This prevents DNS resolution hiccups during account cloning.

# Example: create zone for customer account
plesk bin domain -c customer.example.com -ip <plesk-server-ip> -dns

Why parallel provisioning? If Plesk installation fails, your cPanel stack is untouched. If security hardening breaks something, you debug in isolation.

Plesk Migrator Setup and Dry Runs

Step 1: Install Plesk Migrator plugin.

sudo plesk installer add --products plesk-migrator

Step 2: Connect source cPanel server.

In Plesk admin panel → Plesk Migrator → Add Source → SSH Connection:

  • Host: <cpanel-server-ip>
  • Port: 22
  • Username: root
  • SSH key or password (root only; Migrator needs full access).

Test connectivity. Migrator will enumerate all cPanel accounts.

Step 3: Run a dry-run migration (low-complexity test account).

Select a small, low-risk account-perhaps an internal test domain. Run migration; do NOT mark as final. Plesk Migrator will:

  • Copy files via rsync (to /var/www/vhosts/).
  • Clone database (mysqldump → restore).
  • Create mail accounts.
  • Clone DNS records.

Step 4: Validate the dry run.

On Plesk:

  • SSH into account's home directory: ssh -l <account_user> <plesk-ip> → check file permissions.
  • Run database query: mysql -u <user> -p<pass> <dbname> -e "SELECT COUNT(*) FROM <table>;"
  • Test HTTP access: curl -I http://<account_domain>/ → should return 200.
  • Test HTTPS: curl -I https://<account_domain>/ → should resolve (cert will be self-signed initially).

Step 5: Identify gaps and adjust.

  • Are file permissions off? Plesk uses different UIDs/GIDs than cPanel. Fix ownership: chown -R <user>:<user> /var/www/vhosts/<domain>/.
  • Is mail not working? Verify mailbox creation in Plesk panel → Mail → check account.
  • Is a script failing? Run it manually and check logs (tail -f /var/log/plesk/mail/postfix.log for mail issues; /var/log/apache2/error.log for web).

Repeat the dry run 2-3 times until you have a bulletproof checklist.

Account-by-Account Migration in Waves

Don't migrate all customers at once. Use a phased approach:

Wave 1: Internal test accounts (2-3 accounts). Low-risk, fully under your control.

Wave 2: Low-complexity customers (3-5 accounts). Single-domain, no custom scripts, no complex databases.

Wave 3: Medium-complexity customers (5-10 accounts). Multisite, databases, standard cron.

Wave 4: High-complexity customers (1-3 accounts). Custom code, integrations, special requirements.

Between waves, collect feedback from your support team. Fix automation gaps discovered in Wave 1 before rolling Wave 2.

For each wave:

  1. Notify customers. "We're upgrading your control panel. Your site remains live; zero impact expected."
  2. Run Plesk Migrator on all accounts in the wave simultaneously (Plesk can parallelize multiple accounts).
  3. Let files sync overnight if databases are large (migration can take 2-12 hours per account depending on size).
  4. Run validation tests the next morning.
  5. Stage DNS cutover for 48 hours later.

Mail Migration with IMAPSync: No Missed Mail

Plesk Migrator creates mail accounts but does not copy mailbox contents. For customers with years of email, this is unacceptable.

Why not Plesk Migrator's mail sync? It doesn't do incremental IMAP sync; it's account creation only.

Use IMAPSync instead:

Step 1: Install IMAPSync on Plesk server.

sudo apt-get install -y imapsync
# or
sudo dnf install -y imapsync  # AlmaLinux

Step 2: For each mail account, run incremental sync.

imapsync \
  --host1 <cpanel-server-ip> \
  --user1 mail@oldaccount.com \
  --password1 "<cPanel mailbox password>" \
  --host2 <plesk-server-ip> \
  --user2 mail@oldaccount.com \
  --password2 "<Plesk mailbox password>" \
  --syncinternaldates \
  --useheader "Message-ID" \
  --maxbytes 1000000000 \
  --maxage 36500 \
  --split1 100 \
  --split2 100 \
  --noauthmd5 \
  2>&1 | tee /var/log/imapsync-mail@oldaccount.com.log

Key flags:

  • --syncinternaldates: Preserves received dates.
  • --useheader "Message-ID": Deduplicates if sync runs twice (idempotent).
  • --split1/--split2 100: Syncs in batches (prevents timeout on large mailboxes).
  • --maxage 36500: Last 100 years (keeps all mail).

Step 3: Automate the sync.

Create a bash loop over all accounts:

#!/bin/bash

# imapsync_all.sh
# Loop through all customers and sync mail

MAILBOXES_FILE="/root/mailboxes.csv"  # user,pass,oldhost,newhost
OLD_SERVER="cpanel.example.com"
NEW_SERVER="plesk.example.com"

while IFS=',' read -r user pass domain rest; do
  echo "Syncing $user@$domain..."
  imapsync \
    --host1 "$OLD_SERVER" \
    --user1 "$user@$domain" \
    --password1 "$pass" \
    --host2 "$NEW_SERVER" \
    --user2 "$user@$domain" \
    --password2 "$pass" \
    --syncinternaldates \
    --useheader "Message-ID" \
    --noauthmd5 \
    2>&1 | tee "/var/log/imapsync-${user}@${domain}.log"
done < "$MAILBOXES_FILE"

Step 4: Run sync twice.

  • Initial sync: 24 hours before DNS cutover. Copies 95% of mail.
  • Delta sync: 1 hour before cutover. Catches new mail sent during migration window.

The --useheader "Message-ID" flag makes this idempotent; running twice doesn't duplicate mail.

Database Migration with Low-Lock Approaches

Large database migrations can lock tables and cause downtime if done carelessly. Use strategies that minimize locking.

For small databases (< 1 GB):

# Single transaction dump and restore
mysqldump -h <cpanel-server> -u <user> -p<pass> \
  --single-transaction \
  --quick \
  --lock-tables=false \
  <database> | mysql -h <plesk-server> -u <user> -p<pass> <database>

--single-transaction: Consistent snapshot via REPEATABLE READ isolation with minimal locks.

For large databases (1-100 GB):

Use MySQL replication for zero-lock migration:

Step 1: Set up replication on cPanel server.

-- On cPanel MySQL
SET GLOBAL binlog_format = 'ROW';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'<plesk-server-ip>' IDENTIFIED BY 'replpass';
FLUSH PRIVILEGES;
FLUSH MASTER;
SHOW MASTER STATUS;  -- Note binlog file and position

Step 2: Initialize replica on Plesk.

-- On Plesk MySQL
CHANGE MASTER TO 
  MASTER_HOST='<cpanel-server-ip>',
  MASTER_USER='repl',
  MASTER_PASSWORD='replpass',
  MASTER_LOG_FILE='mysql-bin.000123',
  MASTER_LOG_POS=12345;
START SLAVE;
SHOW SLAVE STATUS\G  -- Wait for Seconds_Behind_Master = 0

Step 3: Let replica catch up (may take hours).

Monitor:

watch -n 1 'mysql -e "SHOW SLAVE STATUS\G" | grep -E "(Slave_IO|Slave_SQL|Seconds_Behind)"'

Step 4: Stop writes on cPanel, wait for sync to finish, promote replica.

-- Briefly stop app writes to cPanel
-- Monitor: SHOW SLAVE STATUS until Seconds_Behind_Master = 0
STOP SLAVE;
-- Plesk MySQL is now a full copy; ready for cutover

This adds 2-4 hours to migration, but zero application downtime during sync.

DNS Cutover: The Critical Moment

DNS cutover is where silence means success and every second matters.

Pre-cutover (48 hours before):

  1. Reduce TTL on all records:

    # In Plesk panel or via API, set TTL to 300 (5 minutes) for all zones
plesk bin dns -u <domain> -type all -ttl 300

    Or via Plesk API:

    curl -u admin:password -k -X POST \
  https://<plesk-ip>:8443/api/v1/domains/<domain_id>/dns-records \
  -d '{...}' -H "Content-Type: application/json"

    This flushes caches faster once you flip.

  2. Create backup DNS zones on secondary nameserver. If using external DNS (Route 53, Cloudflare), create records pointing to Plesk IP as secondary. Don't activate yet.

  3. Verify both servers resolve correctly (from multiple locations):

    dig @8.8.8.8 customer.example.com
dig @1.1.1.1 customer.example.com

During cutover (maintenance window: 1-2 hours recommended):

  1. Announce to customers (via email, status page): "System maintenance 2 AM-3 AM UTC. Brief DNS propagation delays possible; services remain online."

  2. Stop writes to cPanel accounts (disable FTP, SSH, SFTP; prevent new emails).

    # Disable all user accounts on cPanel
whmapi1 suspend_account account=<user> reason="Migration in progress"

  3. Final IMAPSync delta run (1 minute; catches last-minute mail).

  4. Flip DNS (atomic operation):

    • Update authoritative nameserver to point domain to Plesk IP.
    • Or: change route53 A record, update Cloudflare A record, etc.
    # Example: Cloudflare API
curl -X PATCH https://api.cloudflare.com/client/v4/zones/<zone-id>/dns_records/<record-id> \
  -H "Authorization: Bearer <token>" \
  -d '{"type":"A","name":"customer.example.com","content":"<plesk-ip>","ttl":300}'

  5. Monitor immediately:

    • Check DNS from multiple geolocations: nslookup customer.example.com 8.8.8.8
    • Verify Plesk is responding: curl -I https://customer.example.com
    • Check mail: echo "" | openssl s_client -connect customer.example.com:143 -starttls imap (should show IMAP banner)
    • Monitor Plesk server logs for errors: tail -f /var/log/apache2/error.log /var/log/plesk/mail/postfix.log

  6. Run smoke tests on first 5 accounts.

    • Can you reach the homepage?
    • Can you login to a CMS (if applicable)?
    • Can you send a test email?

  7. Keep rollback decision window open for 15-30 minutes. If something's broken, flip DNS back to cPanel. Mail and databases remain synced.

Post-cutover (immediately):

  • Monitor first hour closely. Set alerts on error rates.
  • Communicate "cutover complete, services nominal" to team.
  • Re-enable user accounts on Plesk: plesk bin subscription -u <subscription_id> -status active

SSL Certificate Handling: Let's Encrypt and Custom Certs

Plesk Migrator does not copy SSL certificates. You must re-issue.

For Let's Encrypt (most common):

Plesk will auto-renew Let's Encrypt certs if you issue them before cutover. Don't rely on Let's Encrypt auto-renewal immediately after DNS change; there's a race condition.

# Via Plesk CLI: issue LE cert for domain
plesk bin certificate -c -domain <domain> -certificate-type LE

Or in Plesk panel: Domains → <domain> → SSL/TLS → Renew Let's Encrypt.

For custom/EV certificates:

  1. Export cert from cPanel (WHM → Manage SSL → download).

  2. Import into Plesk:

    plesk bin certificate -c -domain <domain> \
  -cert-file /path/to/cert.crt \
  -key-file /path/to/key.key \
  -ca-file /path/to/ca.crt

  3. Or via Plesk panel: Domains → <domain> → SSL/TLS → Upload Custom Certificate.

Before cutover:

Ensure every domain has a valid cert in Plesk. Test:

openssl s_client -connect <domain>:<plesk-ip>:443 -showcerts | grep -A5 "subject="

WHMCS Reconfiguration and Provisioning Module Switch

If you bill via WHMCS, the provisioning module must switch from cPanel to Plesk.

Step 1: Install Plesk module in WHMCS.

Download from WHMCS marketplace or via GitHub:

# Typical WHMCS modules path
cd /home/whmcs/modules/servers/
git clone https://github.com/plesk/whmcs-module-plesk.git plesk

Step 2: Reconfigure product/service groups.

In WHMCS:

  • Products/Services → Edit Product → Module Settings.
  • Change Server Group from "cPanel" to "Plesk".
  • Map Plesk server to the product.

Step 3: Provision existing customers on Plesk.

If using automatic provisioning, manually update existing subscriptions:

  • Admin → Clients → View Client → Manage Products/Services.
  • For each subscription, change associated server from cPanel to Plesk.

Step 4: Test provisioning workflow.

Create a test customer and test subscription to ensure auto-provisioning works.

Validation Tests During Maintenance Window

During the cutover, before declaring success, run these validation checks:

HTTP/HTTPS availability:

for domain in $(cat domains.txt); do
  http_code=$(curl -s -o /dev/null -w "%{http_code}" https://$domain)
  echo "$domain: $http_code"
  [[ "$http_code" != "200" ]] && echo "ALERT: $domain failed HTTP check"
done

Database connectivity:

mysql -h <plesk-server> -u <user> -p<pass> <database> -e "SELECT VERSION();"

Mail send/receive:

# Send test email via SMTP
(echo "EHLO test"; sleep 1) | nc <plesk-server> 25

# Verify IMAP login
echo "" | openssl s_client -connect <plesk-server>:993 -quiet

DNS resolution (multiple ISPs):

dig @8.8.8.8 <domain>  # Google DNS
dig @1.1.1.1 <domain>  # Cloudflare DNS
dig @208.67.222.222 <domain>  # OpenDNS

Cron job execution:

# Check last run time of cron jobs
grep -r "CRON" /var/log/syslog | tail -20

Rollback Playbook: Revert in Minutes

If cutover goes sideways, you have a quick-exit plan:

Within 30 minutes of cutover, before TTL expires:

  1. Flip DNS back to cPanel.

    # If using Cloudflare: point A record back to cPanel IP
curl -X PATCH https://api.cloudflare.com/client/v4/zones/<zone>/dns_records/<id> \
  -d '{"content":"<cpanel-ip>"}'

  2. Notify customers (brief, factual). "Brief DNS anomaly detected. Services restored. We're investigating and will retry migration tomorrow."

  3. Check cPanel is responsive.

    curl -I https://<cpanel-ip>:2083

  4. Mail is still on both servers (thanks to IMAPSync), so no data loss.

  5. Databases: If you used replication, Plesk has a read-only copy; no data loss. If mysqldump, cPanel is still primary.

  6. Post-incident: Review logs, identify failure, wait 24 hours, retry.

Rollback should take < 5 minutes. This is why the low-TTL and parallel-infra strategy exists.

Customer Communication Template

Pre-migration (1 week before):

Subject: Platform Upgrade-Improved Control Panel Coming Your Way

"We're upgrading your hosting control panel from cPanel to Plesk. What does this mean for you?

  • Zero downtime. Your site, email, and databases remain online.
  • Better performance and modern tools.
  • Same features you use today.
  • DNS cutover happens at [DATE/TIME UTC], expected to complete in 30 minutes.

No action required from you. We'll handle the migration end-to-end."

24 hours before:

"Friendly reminder: your hosting platform upgrade happens tomorrow at [TIME UTC]. Services remain online. If you have any concerns, reply to this email."

During cutover:

"System maintenance in progress (target: 1 hour). Services remain online; DNS propagation may take a few minutes globally. No action needed."

Post-cutover (success):

"Migration complete. Your new Plesk control panel is live. You can login at [new URL] with your same username/password. Documentation: [link]. Support team standing by if you have questions."

Common Zero-Downtime Mistakes to Avoid

  1. Skipping the dry run. Always test on a throwaway account first. Plesk's auto-configuration catches 90% of issues; the remaining 10% will break production.

  2. Not reducing TTL pre-cutover. TTL at 86400 means your DNS change takes up to 24 hours to propagate. Reduce to 300; then flip. Increase after cutover.

  3. Forgetting mail content. Plesk Migrator creates accounts; IMAPSync copies mail. Without IMAPSync, customers lose years of email history. Unacceptable.

  4. Assuming Let's Encrypt auto-renewal works immediately. Renew certs before DNS cutover. ACME challenges may fail if DNS timing is off.

  5. Not testing database replication before cutover. Run replication in parallel for 12+ hours. Watch for lag. Promote only after Seconds_Behind_Master = 0.

  6. Skipping the rollback window. Keep cPanel accounts active and DNS capable of reverting for 24-48 hours post-cutover. Only decommission cPanel after a stable period.

  7. Migrating all customers at once. One broken customer account shouldn't break 100 others. Use waves. Lessons from Wave 1 fix Wave 2.

  8. Not monitoring actively during cutover. Have team on-call, logs open, monitoring dashboard visible. Be present.

Modern Alternatives Sidebar

If you're considering a platform switch, several modern control panels offer competitive features. Adminbolt ($20/mo VPS, $45/mo bare metal, flat per-server with unlimited accounts) stands out for flat-fee billing with built-in WordPress management and a modern API-first architecture, eliminating per-account licensing complexity. Other options like Cyberpanel (open-source, cost-effective) and Cloudpanel (developer-focused, free) have emerged, though Plesk remains the most feature-rich for traditional shared-hosting operators.

FAQ

Q: Can I migrate accounts one at a time, or must I do them in waves?

A: Either works. Waves reduce testing overhead; one-at-a-time is safer for critical customers. Recommend hybrid: low-risk in wave batches, critical accounts individually with extended validation.

Q: What if a customer's disk is 500 GB? Will migration take forever?

A: Yes, initial rsync can take 12+ hours. Start that overnight. Use --bwlimit 500000 to cap bandwidth if needed: rsync --bwlimit=500000 -av .... Or use Plesk Migrator's parallel account feature to migrate multiple accounts simultaneously on different I/O queues.

Q: Should I decommission cPanel immediately after cutover?

A: No. Keep it online for 48 hours as a backup. If anything goes wrong (corrupted file discovered, customer reports missing data), you can flip DNS back and investigate. After 48 hours, you can safely shut it down.

Q: Do I need to reconfigure apps like WHMCS or client portals?

A: Yes, if they're provisioning accounts. Update the API credentials in your provisioning module to point to Plesk instead of cPanel. Test provisioning a new account before announcing the migration to customers.

Q: Will customer passwords change?

A: No. cPanel account credentials transfer 1:1 to Plesk. Mail account passwords do as well (set in IMAPSync). FTP users: re-create in Plesk or manually migrate if using SFTP (no FTP passwords needed for SFTP).

Q: What about cPanel AutoSSL certificates?

A: AutoSSL is cPanel-specific and won't exist in Plesk. Before migration, issue Let's Encrypt certificates in Plesk for all domains. Plesk's auto-renewal will handle renewals going forward.

Q: Can I test mail migration without doing a full account migration first?

A: Yes. Run IMAPSync as a standalone operation. It doesn't require account or file migration; it just syncs IMAP mailboxes between servers. Useful for testing mail volume and sync speed independently.

Q: How do I handle cPanel add-on domains and parked domains in Plesk?

A: cPanel's add-ons and parked domains are just additional DNS zones with different WWW roots. Plesk calls these "Additional Domains" (same feature). Plesk Migrator creates these automatically; just verify they're configured correctly in Plesk after migration.

Q: What if DNS propagation is slow after cutover?

A: Propagation typically takes 5-30 minutes with a 300-second TTL. If slower:

  • Check authoritative nameservers are resolving correctly: dig +trace <domain>.
  • Verify no caching issues on client systems: nslookup -norecurse <domain>.
  • Wait. ISP recursive resolvers can lag. If most clients see Plesk within 15 minutes, you're fine.

Q: Should I use rsync or SCP for file transfer?

A: rsync. It's resumable (if interrupted mid-transfer, re-run and only missing files are transferred). SCP must re-transfer everything. Plesk Migrator uses rsync internally, so stick with that.

Conclusion

A zero-downtime migration from cPanel to Plesk is operationally intensive but absolutely achievable. The key is discipline: parallel infrastructure, staged waves, low TTL, extensive validation, and a practiced rollback plan.

Start small (Wave 1: 2-3 accounts). Document every step. Fix every gap. Then scale. By Wave 4, you'll have migrated your entire customer base with zero reported downtime and zero data loss.

Your customers won't notice anything changed except a new control panel login. That's the whole point.

Summary

Choosing or replacing a hosting control panel is a multi-year decision. The right choice depends on your pricing model, automation needs, security stack, and growth trajectory - not on brand recognition alone.

If you want to evalua

← Back to Blog