Ditch the $150/mo cPanel Bill: Migrate to CyberPanel or Plesk

If your developer insists you must keep paying roughly $150 per month for a cPanel licence, pause before you renew. For many Australian small businesses and site owners, that fee is a control-panel tax—not a technical requirement. A clean Ubuntu VPS with CyberPanel (free, OpenLiteSpeed-based) or a properly licensed open-source Plesk path can host the same sites, mail, SSL, and backups without the recurring cPanel bill. This guide stays on that exact problem: what breaks when people try to leave cPanel, how to diagnose it yourself, and when to book remote help from Fixwebnode.

Fixwebnode provides direct remote Linux server support and bug fixing across Australia—not a freelance marketplace. We work on your existing VPS or a fresh box, migrate sites safely, and leave you with a panel you actually control. Service coverage is listed on our service areas page; the work itself is remote and digital.

Why the cPanel licence argument fails for most Australian sites

cPanel is polished. It is also expensive at scale, and many agencies lock clients into it because it is what their runbooks assume. Your stack—WordPress, Laravel, static sites, MySQL/MariaDB, Let’s Encrypt, email—does not require cPanel. CyberPanel and Plesk both give you vhosts, PHP versions, databases, SSL, and file managers. The hard part is not “installing a free panel in ten minutes on an empty server.” The hard part is migrating live sites without downtime, broken DNS, missing mail, or PHP version mismatches. That is the story this post solves.

Do I really need to keep paying for cPanel in Australia, or can I move to CyberPanel or Plesk?

Most brochure sites, WooCommerce shops, and small SaaS front-ends on a single VPS do not need a paid cPanel licence. You can migrate document roots, databases, SSL, and cron jobs to CyberPanel or Plesk on Ubuntu if you inventory accounts carefully and cut DNS over only after verification. Call a specialist when you have many accounts, custom mail routing, or no recent off-server backups.

Common issues when leaving a paid cPanel licence

These are distinct failure modes Australian owners hit when someone waves a free-panel install as a ten-minute miracle. Treat each separately.

Issue 1 — “We have to keep cPanel” with no inventory of what actually runs

Symptoms: Nobody can list every domain, subdomain, database, cron, or mailbox. The developer quotes the licence renewal because rebuilding from memory feels risky. Backups may exist only inside cPanel’s own format.

Issue 2 — Panel installs fine, but sites serve the wrong root or PHP version

Symptoms: CyberPanel or Plesk dashboard loads; visiting the domain shows default pages, 404s, or fatal errors like missing vendor/autoload.php or wrong PHP 8.x vs 7.4. WordPress white-screens after copy.

Issue 3 — DNS cutover works for HTTP but SSL, mail, or cron silently fail

Symptoms: Homepage loads on the new IP; browsers warn on certificate name mismatch; contact forms stop; scheduled jobs never fire; old cPanel server still receives mail because MX was forgotten.

Issue 4 — Half-migrated “temporary” dual hosting burns money and causes drift

Symptoms: Content edited on the old cPanel box while DNS still points there; the new panel is stale; licence is still paid “just in case”; nobody owns the final cut date.

How to fix Issue 1 — Build a real migration inventory before you cancel cPanel

Do this on the existing cPanel server (SSH as root or a sudo user). Goal: a written list you can tick off on CyberPanel or Plesk.

Step 1 — Snapshot and off-server backup first

Take a VPS snapshot from your Australian host’s panel if available. Then export account-level data. On cPanel/WHM you can use the UI backup, or from shell package critical paths:

sudo mkdir -p /root/pre-migration-backup
sudo tar -czf /root/pre-migration-backup/home-$(date +%F).tar.gz /home
sudo sh -c 'mysqldump --all-databases --single-transaction --quick > /root/pre-migration-backup/all-db-$(date +%F).sql'
ls -lh /root/pre-migration-backup/

Copy that directory off the server (SCP to your laptop or object storage). Do not cancel the cPanel licence until this file set exists somewhere else.

Step 2 — List domains, docroots, and PHP handlers

# Domains / users commonly under /var/cpanel or userdata
sudo ls /var/cpanel/users
sudo grep -H "documentroot\|phpversion\|servername" /var/cpanel/userdata/*/* 2>/dev/null | head -n 100

# Running web stack clue
sudo apachectl -S 2>/dev/null || sudo nginx -T 2>/dev/null | head
php -v
which php-fpm php || true

Step 3 — List databases and crons

sudo mysql -e "SHOW DATABASES;"
sudo ls /var/spool/cron/ 2>/dev/null
sudo cat /etc/crontab
sudo ls /etc/cron.d/

Step 4 — Decide CyberPanel vs Plesk for your case

• CyberPanel: strong free path, OpenLiteSpeed, good for WordPress-heavy single VPS setups.
• Plesk: familiar multi-service UI; confirm edition/licensing rules for your host before you standardise on it—do not assume “free forever” without reading current terms.

When to call Fixwebnode: dozens of accounts, reseller layouts, or backups only inside proprietary cPanel formats you cannot restore cleanly. Book remote inventory and export under Secure Linux Admin & Full-Stack Infrastructure Australia.

How to fix Issue 2 — Align document roots, PHP, and app files on the new panel

Assume a fresh Ubuntu 22.04/24.04 VPS. Install only one panel. Mixing leftover Apache from experiments with OpenLiteSpeed is a common self-inflicted outage.

Step 1 — Baseline the new server

sudo apt update && sudo apt -y upgrade
sudo timedatectl set-timezone Australia/Sydney
free -h
df -h
ip -br a

Step 2 — Install CyberPanel (example free path) only on a clean OS

Use the project’s current official installer on a minimal Ubuntu image. Always re-check the upstream install docs before production; the pattern looks like:

sudo su -
export DEBIAN_FRONTEND=noninteractive
# Official CyberPanel install script (verify URL/hash from cyberpanel.net before running)
sh <(curl https://cyberpanel.net/install.sh || wget -O - https://cyberpanel.net/install.sh)

For Plesk, use Plesk’s official installer on a clean OS instead—never stack both panels on one host.

Step 3 — Create the site and match PHP

In the panel UI, create each domain with the same PHP major version the app used on cPanel (check composer.json or a phpinfo drop file on the old host). Then sync files:

# From your workstation or a jump host (adjust user/host/paths)
rync -aH --info=progress2 \
 olduser@OLD_CPANEL_IP:~/public_html/ \
 root@NEW_PANEL_IP:/home/NEWUSER/public_html/

# Databases
mysqldump -h OLD -u root -p DBNAME > dbname.sql
mysql -h NEW -u root -p -e "CREATE DATABASE DBNAME CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -h NEW -u root -p DBNAME < dbname.sql

Step 4 — Fix app config and permissions

# WordPress example — update DB credentials in wp-config.php on the new host
sudo grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST" /home/NEWUSER/public_html/wp-config.php

# Ownership typical for CyberPanel/OpenLiteSpeed layouts (confirm user on your box)
sudo chown -R NEWUSER:NEWUSER /home/NEWUSER/public_html
find /home/NEWUSER/public_html -type d -exec chmod 755 {} \;
find /home/NEWUSER/public_html -type f -exec chmod 644 {} \;

Step 5 — Verify on the new IP before DNS

# Temporary host-header test from your laptop
curl -I http://NEW_IP/ -H "Host: www.example.com.au"
curl -kI https://NEW_IP/ -H "Host: www.example.com.au"

# On server: vhost and PHP-FPM/OLS health
sudo ss -tulpn | grep -E ':80|:443|:7080|:8088'
sudo tail -n 100 /usr/local/lsws/logs/error.log 2>/dev/null
sudo tail -n 100 /var/log/nginx/error.log 2>/dev/null
sudo tail -n 100 /var/log/apache2/error.log 2>/dev/null

If you still see the default page, the panel vhost server name or document root is wrong—fix the panel mapping, do not blindly reinstall.

When to call Fixwebnode: compiled extensions, ionCube, multi-PHP apps, or reverse-proxy layers you did not design. Nginx-heavy edge setups also appear in our Enterprise Nginx Support runbooks when the front door is not a simple panel vhost.

How to fix Issue 3 — SSL, mail, and cron after leaving cPanel

Step 1 — Issue certificates on the new panel while DNS still points old (or use host-file tests)

Prefer issuing Let’s Encrypt only when the domain already resolves to the new IP, or use DNS-01 if you must pre-stage. After the A/AAAA records aim at the new server:

# Confirm public resolution from Australia-friendly resolvers
dig +short example.com.au A
dig +short www.example.com.au A

# On new server, after panel SSL issuance
sudo openssl s_client -connect 127.0.0.1:443 -servername www.example.com.au </dev/null 2>/dev/null | openssl x509 -noout -dates -subject

Step 2 — Mail is not automatic

Map every MX, SPF, DKIM, and mailbox. If mail stays on Google Workspace or Microsoft 365, do not create conflicting local MX on the new panel. If mail lived on cPanel, export mailboxes deliberately (IMAP sync tools) and lower TTLs only after login tests.

dig +short example.com.au MX
dig +short example.com.au TXT | grep -i spf
# Send a test and read mail logs on the new host
sudo tail -n 200 /var/log/mail.log 2>/dev/null || sudo journalctl -u postfix -n 100 --no-pager

Step 3 — Recreate cron jobs explicitly

# Compare old crons you saved earlier, then install for the site user
sudo crontab -u NEWUSER -l
# Example WP cron replacement is often better as system cron hitting wp-cron.php
# Add only after verifying paths and PHP binary on the new panel

Step 4 — Restart only the services you changed

# CyberPanel / OpenLiteSpeed typical
sudo systemctl restart lsws
# or
sudo /usr/local/lsws/bin/lswsctrl restart

# If using PHP-FPM pools under another stack
sudo systemctl restart php8.2-fpm
sudo systemctl status php8.2-fpm --no-pager

When to call Fixwebnode: production mail cutovers, DKIM alignment for bulk senders, or multi-domain certificates behind CDNs. Remote specialists prevent the classic “site is up, nobody gets email” Monday morning.

How to fix Issue 4 — End the dual-host drift and cancel the licence cleanly

Step 1 — Freeze writes on the old app briefly

Put WooCommerce/maintenance mode on, or stop accepting orders for a short window. Final rsync:

rsync -aH --delete --info=progress2 \
 olduser@OLD_IP:~/public_html/ \
 root@NEW_IP:/home/NEWUSER/public_html/

Step 2 — Drop DNS TTL ahead of time, then switch A/AAAA (and WWW)

# After change, verify from multiple resolvers
dig example.com.au A +trace | tail
curl -I https://www.example.com.au/

Step 3 — Monitor old server for leftover traffic

# On old cPanel box — watch access logs for clients still hitting it
sudo tail -f /usr/local/apache/domlogs/* 2>/dev/null
# or
sudo tail -f /var/log/apache2/access.log

When traffic is gone and the new panel is healthy for several days, decommission cPanel and stop paying the licence. Keep the final off-server backup.

When to call Fixwebnode: you cannot afford a freeze window, or multiple developers keep publishing to the wrong host.

When DIY is enough vs when to book Fixwebnode

DIY is enough when you have one to three mostly static or standard WordPress sites, working off-server backups, SSH on both boxes, and you can tolerate a short maintenance window. Follow the inventory → parallel build → IP test → DNS → mail/cron verification path above.

Book Fixwebnode when any of these are true: no reliable backup; reseller or many add-on domains; custom Apache rewrite museums; payment traffic that cannot blip; mailboxes on the same cPanel; or a developer whose only plan is “renew cPanel.” We deliver remote cutovers as a direct specialist provider—conversation first, then hands-on migration—not bids on a board.

For ongoing hardening after the move (SSH, firewall, panel exposure, updates), pair the migration with the same Australia Linux admin service rather than leaving the new panel open on default ports without review.

Talk to Fixwebnode about your cPanel exit

If your developer’s only answer is a recurring cPanel invoice, get a second pair of eyes on the actual server inventory. Fixwebnode can remotely assess your Ubuntu (or similar) VPS, stage CyberPanel or Plesk, migrate sites, and verify SSL, PHP, and mail before you cancel anything.

Start with the landing page for Ubuntu Linux server support and bug fixing in Australia, review where we work on service areas, and open a conversation about a controlled panel migration—not another year of licence inertia.