You run a small hosting company on cPanel. The per-account licensing adds up, and you are considering Virtualmin to cut costs. But you have years of automation wired into cPanel: custom hooks, cron jobs that call cPanel APIs, and provisioning scripts that assume cPanel’s structure. A migration is not just copying files; it is re-engineering your automation. This article covers what breaks, how license costs compare at scale, and how to roll back if things go wrong.
What breaks in a cPanel to Virtualmin migration?
Almost everything that touches the control panel’s API or file system layout will need rework. Virtualmin uses a different architecture (based on Webmin) and does not provide the same hooks or command-line tools. The breakage falls into three areas: automation hooks, cron jobs, and provisioning scripts.
Automation hooks
cPanel provides hooks that trigger scripts on events like account creation, password changes, or suspension. These are often used to sync with billing systems, send welcome emails, or update monitoring. Virtualmin has its own event system, but the hook names, payloads, and execution context differ. Any custom script that relies on cPanel’s hook environment variables (like CPANEL_USER) will fail silently or error out.
Cron jobs
Many hosts schedule cron jobs to run cPanel’s /usr/local/cpanel/bin/ utilities for backups, SSL renewal, or log rotation. Virtualmin uses different commands (e.g., virtualmin backup-domain) and stores configuration in /etc/webmin/virtual-server/. Cron jobs that call cPanel binaries will break. Also, user-level cron jobs might reference paths like /home/user/public_html; Virtualmin’s default document root is /home/user/public_html as well, but the surrounding structure (e.g., etc, logs) is different.
Provisioning scripts
If you use a billing platform like WHMCS, Clientexec, or a custom script to create accounts via cPanel’s API, you will need a new provisioning module. Virtualmin offers a remote API (via Webmin’s remote access) but it is not a drop-in replacement. Scripts that parse cPanel’s API responses or rely on its specific error codes will need rewriting. The same applies to domain addition, email account creation, and database provisioning.
How do license costs compare at 50–500 accounts?
cPanel charges per account, while Virtualmin is free and open source. At 50 accounts, cPanel’s cost might be manageable, but at 500 it becomes significant. However, you must factor in the time to rebuild automation and the potential for downtime. The table below shows a simplified comparison based on list prices (as of 2024) for cPanel’s Solo and Admin tiers, and Virtualmin’s free version. Note that cPanel’s pricing varies by partner and contract; always check current rates.
| Accounts | cPanel Solo (approx.) | cPanel Admin (approx.) | Virtualmin |
|---|---|---|---|
| 50 | $15/mo | $30/mo | $0 |
| 100 | $30/mo | $45/mo | $0 |
| 250 | $75/mo | $75/mo | $0 |
| 500 | $150/mo | $125/mo | $0 |
The above figures are illustrative only; cPanel’s actual pricing depends on your reseller agreement. The key takeaway: at 500 accounts, cPanel could cost over $1,000 per year, while Virtualmin costs nothing in licenses. But you must weigh that against migration effort and potential loss of features like built-in support.
What does a rollback checklist for the first 30 days look like?
Even with careful planning, migrations can go sideways. A rollback plan ensures you can revert to cPanel if critical issues arise. The first 30 days are crucial: monitor closely and have a way back. Here is a checklist:
- Day 0–7: Keep cPanel running in parallel. Do not decommission the old server. Migrate a few test accounts and verify functionality. Keep DNS TTLs low (e.g., 300 seconds) so you can switch back quickly.
- Day 8–14: Monitor automation. Check that provisioning, backups, and email work. Compare logs from both systems. If a critical script fails, fix it or roll back that account.
- Day 15–21: Test rollback for one account. Pick a non-critical account, migrate it to Virtualmin, then roll it back to cPanel. Document the steps and time required.
- Day 22–30: Decide go/no-go. If more than 10% of accounts have issues, consider rolling back all. If issues are minor, proceed but keep cPanel available for another month.
Also, maintain a list of dependencies: which scripts call which APIs, and where configuration lives. This will speed up either migration or rollback.
How do you handle provisioning and automation after migration?
You will need to rewrite provisioning scripts to use Virtualmin’s API or command-line tools. For billing integration, check if your billing software has a Virtualmin module. If not, you can use Virtualmin’s remote API via HTTP or SSH. For example, to create a domain, you can call virtualmin create-domain with parameters. Automation hooks can be replaced with Virtualmin’s “post-change” scripts or by using a custom script that polls for changes. Cron jobs should be updated to call Virtualmin commands and use its logging.
If you use a billing platform, consider one that supports Virtualmin natively. For instance, Teculiar provides provisioning modules for Virtualmin, cPanel & WHM, and Hetzner Cloud, so you can automate account creation upon payment. Its API and signed webhooks let you integrate custom workflows. The Free plan covers up to 50 clients, which might suit smaller hosts testing the waters.
What to do next
- Inventory all scripts, cron jobs, and hooks that interact with cPanel.
- Set up a Virtualmin test server and migrate one non-critical account.
- Calculate your current cPanel license cost at 50, 100, 250, and 500 accounts.
- Write a rollback procedure and test it on a single account.
Start by listing every system that holds customer data.