Migrating a CloudLinux 8 or 9 cPanel server to CloudLinux OS 10

CloudLinux OS 10 has been generally available since October 2025 and picked up its second point release, 10.2, on 26 May 2026. If you're running a shared cPanel host on CloudLinux 8 or 9 and wondering how to get there, the short answer is: not with an in-place upgrade. There is no ELevate path from either version straight to 10, and CloudLinux has no plans to add one in the near term.

This article covers what actually changed in CloudLinux OS 10, why the in-place route doesn't exist, the fresh-install-plus-transfer path that does work today, and — more importantly — whether you should bother yet given where cPanel support currently stands.

What changed in CloudLinux OS 10

Three changes matter more than the version bump itself.

No ISO, ever. Every previous CloudLinux release shipped a bootable ISO. CloudLinux OS 10 doesn't. The only supported install method is converting an existing AlmaLinux 10 machine with cldeploy — the same script covered in installing CloudLinux on an existing cPanel server, just pointed at AlmaLinux 10 instead of 8 or 9. There's no CentOS-7-style "boot the installer" option anymore.

It's a rolling release, and it doesn't rebrand the OS. CloudLinux OS 10 tracks AlmaLinux's point releases directly instead of shipping independent minor versions — 10.0 at GA, 10.1, then 10.2 in May 2026 with AlmaLinux's "Lavender Lion" base (kernel 6.12, Python 3.14, MariaDB 11.8, PostgreSQL 18). The conversion also no longer rewrites /etc/os-release, so a converted box still reports itself as AlmaLinux. Don't rely on cat /etc/redhat-release to confirm you're on CloudLinux — use cldetect --check-license and cldiag instead, same as on 8 and 9.

MySQL/MariaDB binaries are no longer LVE-patched upstream. On CloudLinux 8 and 9, the database binaries themselves were patched to cooperate with LVE and CageFS. CloudLinux OS 10 draws a cleaner line between upstream packages and CloudLinux-provided ones, which changes how MySQL Governor enforces limits at the database layer. If you rely on Governor's RESTRICT mode to throttle noisy-neighbour queries, test it on a staging CL10 box before you assume it behaves identically post-migration.

Should you move yet?

Probably not urgently. CloudLinux 8 and 9 track their RHEL upstream maintenance windows — support runs into 2029 and 2032 respectively — so neither is anywhere near forced-migration territory the way CentOS 7 was.

The bigger blocker is control-panel readiness. cPanel added AlmaLinux 10 as a supported base OS in version 132 (December 2025), but that's support for the bare OS — CloudLinux OS 10's cPanel integration (LVE Manager, CageFS hooks, the PHP Selector plugin) has trailed behind and was still catching up as of early 2026. Before you commit a production box, check cPanel's current supported-OS matrix and CloudLinux's own control-panel compatibility page rather than assuming parity with 8/9 — this is one of the few places in the stack where the underlying OS and the panel integration on top of it haven't shipped support on the same day.

The migration path: fresh AlmaLinux 10, then transfer

With no in-place option, the route is the same shape as the CentOS 7 to AlmaLinux migration: build a clean target server and move accounts across with WHM's Transfer Tool. The old box keeps serving traffic the entire time.

Step 1 — Build the target on AlmaLinux 10

Provision a new VPS or dedicated host, install AlmaLinux 10, then install cPanel from scratch. Confirm the cPanel version you land on actually lists AlmaLinux 10 as supported before you go further — /scripts/check_cpanel_pkgs will flag a mismatch early rather than mid-transfer.

Step 2 — Convert to CloudLinux OS 10

Once cPanel is running cleanly on AlmaLinux 10, run cldeploy against your CloudLinux activation key:

wget https://repo.cloudlinux.com/cloudlinux/sources/cln/cldeploy
sh cldeploy -k YOUR-KEY-HERE
reboot

After reboot, confirm the CloudLinux kernel and registration the same way you would on 8 or 9 — uname -r should show a .lve string, and cldetect --check-license should print License is OK. Since the OS identification files aren't rewritten on CL10, don't trust /etc/redhat-release here; it'll still say AlmaLinux.

Install CageFS and the LVE Manager plugin as usual:

yum install cagefs lvemanager -y
cagefsctl --init
cagefsctl --enable-all

If alt-php packages or the PHP Selector plugin aren't available yet in the CloudLinux 10 repos for your target cPanel version, that's the control-panel-lag issue from the previous section showing up directly — don't proceed to a production cutover until it's resolved.

Step 3 — Export WHM configuration from the source

Same as any cross-server cPanel move, capture the packages, feature lists, and EasyApache 4 profile before transferring accounts:

# On the old CloudLinux 8/9 server
whmapi1 listpkgs > /root/pkgs.txt
whmapi1 list_features > /root/features.txt
tar -czf /root/cpanel-config.tar.gz /var/cpanel/packages/ /var/cpanel/features/ /etc/wwwacct.conf

Copy the tarball to the new server, unpack it into the same paths, and reapply your EasyApache 4 profile before you bring accounts across — package mismatches during transfer are the single most common cause of a partially-broken PHP stack post-migration.

Step 4 — Transfer accounts

Run the WHM Transfer Tool from the new server, pointed at the old one:

WHM → Transfers → Transfer Tool → enter the source IP and root credentials → All accounts. Budget roughly 5-8 accounts per minute on a 1 Gbps link for typical WordPress sites, so a 150-account box moves in about 20-30 minutes.

Once accounts land, re-run cagefsctl --enable-all to cage the newly-created users — CageFS doesn't retroactively apply to accounts that existed before you initialised it, and a fresh transfer creates them all at once.

Step 5 — Verify LVE, Governor, and Selector before cutover

Before touching DNS, confirm the CloudLinux-specific layer actually works on the new box, not just cPanel itself:

lveinfo --list          # LVE limits are applied per account
cagefsctl --list-cagefs-enabled
dbctl governor status    # MySQL Governor mode matches the old server

Given the upstream MySQL packaging change noted above, don't assume Governor's behaviour is identical — re-check your thresholds against MySQL Governor modes rather than copying the old server's dbctl config blind.

Step 6 — Cut over DNS

Drop your authoritative DNS TTL to 300 seconds 48 hours ahead of cutover, then repoint A/AAAA records once account verification passes. Keep the old CloudLinux 8/9 box running for at least a week as a fallback, and watch the new server's access logs to confirm traffic has actually moved before decommissioning it.

Next steps

• Install CloudLinux on an existing cPanel server — the cldeploy mechanics this migration reuses on the AlmaLinux 10 target.
• CloudLinux vs AlmaLinux for hosting providers — if you're reconsidering whether you need CloudLinux at all on the new box.
• MySQL Governor modes — re-verify your throttling config against CloudLinux OS 10's unpatched upstream database packages before cutover.