AlmaLinux 8 reaches the end of its active support window in 2029, but a cPanel server on 8 already misses features such as MySQL 8.4-only defaults and, more importantly, gains a much longer runway by moving to 9 or 10 now. cPanel’s ELevate project wraps the AlmaLinux Leapp-based upgrade so that cPanel’s own packages, EasyApache 4 and the database server survive the jump. The upgrade goes one major version at a time: 8 to 9, then 9 to 10. Each hop is a separate maintenance window with its own reboots.
Applies to cPanel & WHM ELevate from AlmaLinux 8 to 9 to 10
Table of Contents
Short answer: Take a backup and a snapshot, bring cPanel current with /scripts/upcp --force, download elevate-cpanel from cPanel’s GitHub release branch and run ./elevate-cpanel --check until it reports no blockers. Then start the upgrade with ./elevate-cpanel --start inside a screen session and let it reboot through the Leapp stages, which takes one to two hours. Repeat the same process for 9 to 10 after confirming the CPU supports x86-64-v3 and the database is on a version AlmaLinux 10 accepts.
What ELevate does and does not do
ELevate runs a pre-flight check, upgrades the operating system with Leapp, then reinstalls cPanel components that were removed for the upgrade and rebuilds EasyApache from your saved profile. It handles MariaDB or MySQL by removing and reinstalling the same version where possible. It does not migrate data between servers, and it does not fix a server that already has broken packages. It also refuses to run if the cPanel version is not current for the tier, if the server is a Rocky Linux box, or if certain unsupported components are present.
The 9-to-10 hop has an extra constraint: AlmaLinux 10 requires the x86-64-v3 CPU baseline for the standard build. Check the CPU flags before you plan it:
/lib64/ld-linux-x86-64.so.2 --help | grep supportedIf the output does not list x86-64-v3 (supported, searched), the standard AlmaLinux 10 kernel will not boot on that hardware and you should stay on 9 or move to a new server.
Prepare for the first hop (8 → 9)
Start with the same discipline as any OS-level change: a verified backup and a hypervisor snapshot. Then bring the panel current and reboot:
/scripts/upcp --force
dnf -y update
rebootFetch the ELevate script from cPanel’s download host and run the check stage only:
cd /root
curl -LO https://raw.githubusercontent.com/cpanel/elevate/release/elevate-cpanel
chmod 700 elevate-cpanel
./elevate-cpanel --checkThe check reports blockers and warnings. Typical blockers include unsupported MySQL or MariaDB versions for the target OS, a running CloudLinux conversion, third-party kernels, custom Apache modules that are not in the EA4 repository, and ea-php versions that do not exist on the target. Warnings cover things like PostgreSQL or Imunify that will be reinstalled but may need attention. Resolve every blocker, then rerun the check until it is clean.
Before starting, note the current EA4 profile so you can compare afterwards:
/usr/local/bin/ea_current_to_profile --target-os=AlmaLinux_9 > /root/ea4-before.jsonRun the upgrade
Launch the upgrade from a screen session; the process reboots the server several times and reports progress in /var/log/elevate-cpanel.log:
./elevate-cpanel --startThe stages are: preparation and package removal, the Leapp upgrade itself with a reboot into an upgrade initramfs, a second boot into the new OS, and then a final stage where ELevate reinstalls cPanel, EasyApache, the firewall and any other components it removed. Expect one to two hours for a typical server. If you lose your session, reconnect and run ./elevate-cpanel --status to see where it is; the process continues on its own through a systemd unit.
If a stage fails, ./elevate-cpanel --log shows the reason. Many failures in the final stage are recoverable by fixing the reported package problem and running ./elevate-cpanel --continue. A failure inside the Leapp reboot stage is the one case where the snapshot rollback is the safer choice.
Post-upgrade work and the second hop (9 → 10)
After ELevate reports success, verify the OS and rebuild anything it could not:
cat /etc/os-release
whmapi1 version
/scripts/check_cpanel_pkgs --fixCompare ea_current_to_profile output against your saved profile and reinstall any missing PHP versions or modules through WHM → Software → EasyApache 4. Confirm the database server started: systemctl status mariadb or mysqld, and log in with mysql -e 'SELECT VERSION();'. Reinstall CSF if it was removed (/scripts/autorepair cpanel_csf_install for the cPanel fork) and reapply your csf.conf. Reinstall KernelCare, Imunify or CloudLinux tools per their vendor instructions.
Once the server has run on AlmaLinux 9 for a few days without complaint, repeat the process for 10. Note the different requirements: on AlmaLinux 10, cPanel supports only MySQL 8.4 among MySQL releases, and MariaDB 10.11, 11.4 or 11.8. A server on MySQL 8.0 must upgrade to 8.4 or switch to MariaDB before the 9-to-10 hop, and PHP versions older than what EA4 ships for 10 will be dropped. Run ./elevate-cpanel --check again on the 9 server; the target OS is detected automatically.
Verify
Browse a representative set of hosted sites, test a PHP-FPM site and a non-FPM site, send and receive mail, log into cPanel as a user, and run a database-backed application. Confirm the kernel is the AlmaLinux one with uname -r and that dnf repolist lists only AlmaLinux, cPanel and your deliberate third-party repositories. Finally run our server security audit and MySQL health snapshot to catch regressions.
Common pitfall
The single most common failure is a pre-check that was skipped because it looked like a warning. A MariaDB 10.5 server upgrading to AlmaLinux 9 is fine, but that same server cannot go to AlmaLinux 10 because 10.5 is not offered there; ELevate will stop mid-way. Plan database upgrades first, one LTS at a time, following Upgrading MariaDB in WHM safely. The second trap is a custom EA4 module compiled by hand rather than installed from the repository. ELevate cannot carry it across; either package it properly or accept that it will need rebuilding after each hop.
CPanel ELevate AlmaLinux at a glance
Official documentation: cPanel & WHM documentation, AlmaLinux wiki, Linux man pages.
Related guides: Choosing a VPS for a cPanel or DirectAdmin server in 2026 · cPanel dropped Rocky Linux: migrating a Rocky 8/9 server to AlmaLinux before updates stop · Replacing cxs: malware scanning with LMD (maldet), ClamAV and ImunifyAV on hosting servers.
Frequently asked questions
Does ELevate work on Rocky Linux or CloudLinux cPanel servers?
Not on Rocky Linux; cPanel stopped supporting it at version 133, so those servers need a migration to AlmaLinux instead. CloudLinux servers use ELevate with the CloudLinux conversion step and the same one-major-version-at-a-time rule.
How long does an ELevate upgrade from AlmaLinux 8 to 9 take?
Expect one to two hours of downtime per hop on a typical server, including several reboots, plus the time needed beforehand to resolve every blocker the check stage reports.
Can I roll back if ELevate fails part-way through?
Failures in the final reinstall stage are usually fixable with ./elevate-cpanel --continue, but a failure inside the Leapp reboot stage is best recovered by restoring the hypervisor snapshot taken before the upgrade started.
Maintenance record
This guide changes servers, data or security settings, so we re-check it against current versions on a fixed schedule. Take a backup or snapshot before you start.
- Maintained by
- srvScripts editorial team
- Supported versions
- cPanel & WHM ELevate from AlmaLinux 8 to 9 to 10
- Last full review
- Next review