If your VPS is still running CentOS 7, you've probably already seen the warning banner in WHM: no more security patches, no more package updates, and a growing list of software that refuses to build against it. CentOS 7 went end-of-life in mid-2024, and wordpress-missing-a-temporary-folder-upload-error" class="auto-link">cPanel has been steadily tightening what it will support on it. The good news is you don't have to nuke the server and start over. cPanel ships a tool called ELevate that upgrades the underlying OS in place, while keeping your accounts, mail, and websites intact.
Symptom: WHM warns your OS is unsupported (or worse, is silent about a real problem)
A few things usually trigger someone to look into this:
- WHM's "Server Status" or license check shows an EOL/unsupported OS warning.
yum updatestarts failing because CentOS's mirror infrastructure has been pulled or redirected to the vault archive.- A plugin or PHP extension refuses to install because it needs packages that no longer exist for CentOS 7.
- cPanel itself announces it's dropping install/update support for the OS version in an upcoming release.
None of these mean your server is broken right now. They mean you're on borrowed time — no security patches means every unpatched CVE from this point forward is permanently open on your box.
Cause: CentOS 7/8 are dead, and cPanel only supports current RHEL-derivatives
Red Hat killed the free CentOS Linux line years ago in favor of CentOS Stream, and CentOS 7 held on the longest before its EOL date passed. cPanel supports AlmaLinux and CloudLinux (both RHEL-compatible, both still receiving updates) going forward. A fresh reinstall is the "safe" path most guides suggest, but it means rebuilding every account, re-issuing SSL, re-pointing DNS, and hoping nothing gets missed. ELevate exists specifically so you don't have to do that.
What ELevate actually does
ELevate is built on Red Hat's own leapp upgrade framework, wrapped by cPanel/CloudLinux with extra checks for cPanel-specific software. It converts the OS in place: your existing hostname, IPs, accounts, mail, MySQL databases, and cPanel configuration all carry over. It's not magic — it still involves multiple reboots and real risk — but it avoids a full rebuild for the vast majority of setups.
Before you touch anything: back up properly
This is the one step people skip and regret. An in-place OS conversion is not reversible once it's underway.
- Take a full VPS snapshot at the provider/hypervisor level if your plan supports it — this is your real rollback plan, not a cPanel backup.
- Run a full cPanel backup as well:
/scripts/pkgacctper account, or a WHM-level full backup to a remote destination. - Export your firewall rules (CSF:
csf -land note any custom entries) — some custom configs don't survive the upgrade cleanly. - Confirm you have out-of-band access (VNC/console from your provider's panel) in case SSH doesn't come back after a reboot.
If your host offers a snapshot feature, take it immediately before step one below, not after you've already started the conversion.
Fix: the ELevate migration walkthrough
- Update cPanel and check disk space first.
You need several GB of free space on/usr/local/cpanel/cpkeyclt /scripts/upcp --force df -h //and/boot— the process downloads a full set of new-OS packages before it starts swapping anything out. Low space is the single most common reason a run stalls partway through. - Download and run the ELevate script.
Run it insidecd /root curl -o elevate.sh https://raw.githubusercontent.com/cpanel/elevate/release/elevate.sh chmod +x elevate.sh ./elevate.shscreenortmux— the process takes a while and includes automatic reboots, and you don't want an SSH disconnect to kill the run. - Let the pre-flight checks run first. ELevate scans your installed packages, third-party repos, and cPanel plugins for anything known to break the conversion (custom PHP builds, unsupported repos, leftover packages from software you removed years ago). Read the output — it will tell you exactly what to remove or fix before continuing, rather than guessing.
- Resolve blockers, then re-run. Common blockers are third-party yum repos (nginx's own repo, old MySQL/Percona repos, EPA-testing repos) that don't have an AlmaLinux equivalent enabled yet, or kernel modules tied to the old kernel. Disable or remove what the script flags, then run it again — it's safe to re-run the checks as many times as needed.
- Start the actual conversion. Once pre-flight passes clean, the script proceeds through several phases automatically, including at least two reboots. Monitor progress with:
Don't manually reboot or interrupt the process mid-phase — let it drive its own reboots.elevate-status - Verify after it finishes.
Check that cPanel services are all running, then load a few live sites, test SMTP/IMAP login, and confirm SSH, cron, and MySQL are healthy.cat /etc/redhat-release whmapi1 servicestatus systemctl --failed
What commonly goes wrong
| Symptom | Likely cause | Fix |
|---|---|---|
| Pre-flight fails on a repo | Third-party repo (Nginx, Percona, Docker) has no leapp mapping | Temporarily disable the repo, re-run checks, re-enable the AlmaLinux version after |
| Run stalls with a disk error | Not enough free space on / or /boot | Clear old kernels, logs, cPanel backups stored locally, then retry |
| Server doesn't come back after reboot | Custom kernel modules or bootloader edits incompatible with the new kernel | Use provider console access to check boot logs; may need to select the correct kernel in GRUB |
| CSF/firewall rules missing post-upgrade | Config format changed between OS versions | Reapply from your pre-migration csf -l export, then restart csf/lfd |
| A specific PHP extension is gone | Extension wasn't rebuilt for the new OS's PHP handler | Reinstall via WHM's MultiPHP/EasyApache after the migration completes |
Prevention: don't let this happen again
The cycle here repeats every few years, so plan for it instead of scrambling at EOL:
- Subscribe to cPanel's and your OS vendor's EOL announcements — don't rely on discovering it via a broken
yum update. - Keep a recent full server backup at all times, stored off the VPS itself, so an emergency migration is never also your first backup in months.
- Test ELevate (or any major upgrade) on a snapshot or staging clone first if your workload is business-critical — don't run your first-ever attempt on production during business hours.
- Avoid piling on obscure third-party repos and custom kernel modules where you can — every one of them is a potential blocker on the next OS transition.
If your VPS is hosted with SkyServer and you'd rather have someone drive the migration for you, our support team can take a snapshot, run the conversion, and verify services before handing it back — open a ticket and mention you're on CentOS and want to move to AlmaLinux.
Frequently Asked Questions
Do I have to use ELevate, or can I just reinstall the server?
A fresh reinstall works too, and is sometimes simpler for small, simple sites. But it means manually recreating every cPanel account, re-uploading content, re-issuing SSL, and re-checking DNS and mail settings. ELevate is worth it specifically to avoid that rebuild on servers with many accounts or complex configurations.
How long does the ELevate migration take?
Budget at least 1-2 hours for a typical single-server setup, more if you have a lot of installed packages or third-party repos that need resolving first. The actual conversion runs unattended through its reboots, but the pre-flight cleanup can take longer than the upgrade itself.
Will my websites go down during the migration?
Yes, expect downtime — the server reboots multiple times during the process and services are unavailable during those windows. This isn't a zero-downtime operation; plan it for a low-traffic maintenance window and let customers know in advance if needed.
What if the migration fails partway through?
This is exactly why the snapshot in step one matters. If ELevate leaves the server in a bad state, restoring the pre-migration snapshot gets you back to a known-good CentOS 7 server, and you can investigate what blocked the run before trying again.
Can I go straight to AlmaLinux 9, or do I need to stop at 8 first?
This depends on your starting OS version and the ELevate release you're using — check the current ELevate documentation for your specific source version, since supported upgrade paths have changed as the tool has matured. Don't assume a direct jump is supported without confirming first.
