Migrate cPanel to Plesk Obsidian: Secure Server Moves

Agency sites on ageing cPanel hosts often hit PHP limits, messy multi-domain layouts, and slow ticket queues. This guide walks Sydney CBD and remote teams through a secure cPanel-to-Plesk Obsidian migration: what breaks, how to diagnose it yourself, and when to hand off to a specialist.

Fixwebnode provides direct server support for control-panel moves—remote diagnostics, cutover planning, and post-migration hardening—not a freelance marketplace. If you run client sites from your area or a Sydney CBD office, the same remote runbook applies.

Why a careful cPanel → Plesk Obsidian migration matters

Plesk Obsidian handles subscriptions, PHP-FPM pools, and nginx/Apache hybrids differently from cPanel/WHM. A “full account transfer” can still leave broken mail routing, wrong document roots, expired or unbound certificates, and databases that connect on the old host but fail on the new one. For agencies, that means client sites 500ing, forms dropping mail, or HTTPS warnings during a Monday launch.

Treat the move as a controlled cutover: inventory on cPanel, restore or import on Plesk, verify services before DNS flips, then lock down SSH, firewall, and backups. Below are the failure modes we see most often—and the DIY steps that actually clear them.

What breaks when sites fail after moving from cPanel to Plesk?

After a panel migration, the usual pattern is: files look present, but one stack layer is misaligned—mail, PHP runtime, TLS, or DB credentials. Confirm the symptom first, then fix that layer; do not re-run a full transfer until you know what failed.

Common issues after cPanel to Plesk Obsidian migration

• Mailboxes present but empty or undeliverable — webmail opens, message list is blank, or external SMTP gets “relay access denied.” Root cause is often incomplete mail store sync, wrong mail home paths, or Plesk not owning the domain for local delivery.
• Sites return 500 after PHP handler change — WordPress or Laravel white-screens; cPanel used ea-php or MultiPHP while Plesk defaults another version or disables required extensions.
• SSL shows “not secure” or wrong certificate — Let’s Encrypt or commercial certs stayed on the old host; Plesk domain has HTTP-only or a default self-signed cert after import.
• Database connection refused or access denied — app still points at old localhost user/host pairs, or MySQL users were not recreated with the same password and privileges on Plesk.

Issue 1 — Empty or undeliverable mail after migration

Mail is the most painful cutover failure for agencies: clients notice first. On Plesk, confirm the domain is set for local mail and that mailbox storage actually contains maildirs.

Step 1 — Inventory mailboxes on the source (cPanel)

# On cPanel/WHM source (SSH as root)
uapi --user=ACCOUNT Email list_pops
# Or list maildir sizes
du -sh /home/ACCOUNT/mail/* 2>/dev/null | head -50

Record every address and approximate size so you can spot incomplete copies.

Step 2 — Verify domain mail service on Plesk

# On Plesk target
plesk bin domain_pref -u example.com -mail_service true
plesk bin mail -l
# Confirm local delivery preference
plesk bin subscription_info -domain example.com | grep -i mail

Step 3 — Test local delivery and logs

# Send a local test and watch the queue/log
echo "migration test" | mail -s "plesk mail test" you@example.com
tail -n 80 /var/log/maillog
# Postfix/qmail style queues vary; on many Plesk builds:
postqueue -p 2>/dev/null || true

Step 4 — Re-sync mail data if counts differ

If webmail users exist but folders are empty, re-copy maildir contents with rsync over SSH from the old host into the Plesk mail home for that domain (paths differ by OS template—confirm under /var/qmail/mailnames/ or the distribution’s Plesk mail root). Fix ownership to the mail system user afterward, then retest.

When to call Fixwebnode: multiple domains, catch-alls, forwarders, or Mailman/lists that must stay live during DNS cutover. Remote specialists can stage dual delivery and validate SPF/DKIM before you flip MX.

Issue 2 — HTTP 500 and PHP version / handler mismatches

cPanel MultiPHP and Plesk PHP handlers do not map 1:1. A site that ran PHP 8.1 with specific modules can land on 7.4 or a pool without intl, imap, or enough memory_limit.

Step 1 — Read the real error, not the browser page

# Domain error log (path may vary)
tail -n 100 /var/www/vhosts/example.com/logs/error_log
# PHP-FPM pool log if used
tail -n 100 /var/log/plesk-php81-fpm/error.log 2>/dev/null
# nginx/Apache proxy errors
tail -n 50 /var/log/nginx/error.log

Step 2 — Align PHP version per domain in Plesk CLI

# List installed PHP handlers
plesk bin php_handler --list
# Set domain to a known-good version (example: 8.2 FPM)
plesk bin domain -u example.com -php_handler_id plesk-php82-fpm

Step 3 — Enable missing extensions and raise limits safely

# Example: enable intl on PHP 8.2 (package names follow OS)
# Debian/Ubuntu-style Plesk hosts often use:
plesk ext php-ini -d example.com -s memory_limit=256M
# Verify loaded modules from CLI matching the site handler
/opt/plesk/php/8.2/bin/php -m | egrep 'intl|imap|mbstring|pdo_mysql'

Redeploy or touch the app config if opcode caches hold stale paths. Clear WordPress object/page caches after PHP changes.

Step 4 — Confirm HTTP response

curl -sI https://example.com/ | head -n 15
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/

When to call Fixwebnode: dozens of subscriptions with mixed PHP needs, custom handlers, or open_basedir jail issues that block plugin writes. That is standard remote server support work—not something to guess under client deadline pressure.

Issue 3 — SSL certificates missing or unbound on Plesk

Imports often bring private keys incompletely, or HTTP-01 challenges fail because DNS still points at cPanel. Browsers then show the default Plesk cert or plain HTTP.

Step 1 — See what Plesk thinks is installed

plesk bin certificate -l -domain example.com
plesk bin subscription_info -domain example.com | egrep -i 'ssl|cert'

Step 2 — Issue or reassign Let’s Encrypt when DNS already points to Plesk

# Only after A/AAAA records hit the new server
plesk bin extension --exec letsencrypt cli.php -d example.com -d www.example.com -m admin@example.com

If DNS is not ready, keep serving the site on a temporary hostname or hosts-file test, upload the existing commercial cert via Plesk UI/CLI, and schedule LE for cutover night.

Step 3 — Force HTTPS and check chain

plesk bin domain -u example.com -ssl true -ssl-redirect true
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates -subject

When to call Fixwebnode: multi-SAN agency certs, reverse proxies, or CDN origin certs that must stay valid during a staged DNS move across several client brands.

Issue 4 — Database access denied after the move

Apps still use old cPanel-style usernames, or MySQL users were created without localhost/127.0.0.1 grants on Plesk.

Step 1 — Confirm DB and user on Plesk

plesk bin database -l
plesk bin database --info dbname
mysql -e "SELECT user,host FROM mysql.user WHERE user LIKE '%partial%';"

Step 2 — Reset password and grants to match wp-config / .env

plesk bin database --update dbname -user dbuser -passwd 'NEW_STRONG_PASSWORD'
# App side: update DB_PASSWORD / DB_HOST=localhost then retest
mysql -u dbuser -p -e "USE dbname; SHOW TABLES;" | head

Step 3 — Import dump if tables never arrived

# From a verified cPanel dump
mysql -u dbuser -p dbname < /root/backups/dbname.sql
# Or via Plesk
plesk bin database --import dbname -file /root/backups/dbname.sql

Verify table counts against the source dump before deleting cPanel backups.

When to call Fixwebnode: encrypted dumps, broken foreign keys across multiple DBs, or production cutovers where you need parallel read-only replicas during switch.

When DIY is enough vs when to book Fixwebnode

DIY is reasonable if you have SSH on both hosts, fewer than a handful of domains, current full backups, and a maintenance window. Work issue-by-issue: mail inventory, PHP handler, certificate, database—verify with curl, openssl, and mail tests before changing public DNS.

Book a specialist when you manage many client subscriptions, need zero-ish downtime MX/web cutover, inherit unknown custom Apache includes, or already see mixed failures (mail + PHP + TLS together). Fixwebnode operates as a direct remote provider for server support—planning, secure transfer, verification, and hardening—across all service areas, including teams based in Sydney CBD and distributed staff elsewhere.

Do not skip a pre-cutover backup on both panels, a hosts-file browser test of every critical site, and a post-cutover check of cron, SPF/DKIM, and automated backups on Plesk.

Talk through your cPanel to Plesk cutover

If your agency is stuck mid-migration—or you want a supervised Obsidian landing before DNS moves—start a conversation with Fixwebnode. Share panel access method, domain count, and whether mail must move the same night.

Book remote help via the landing page: server support step-by-step. We will focus on a secure, verifiable move from cPanel to Plesk Obsidian, not generic “restart and hope” advice.