Linux servers have a way of running quietly for years. That's a good thing, right up until the operating system or software stack underneath them stops getting security updates. Several of the most widely deployed Linux platforms have reached end-of-life recently, and many of them are still running in production.
Here's how to check whether your servers are affected, and what to do about it.
What's past end-of-life as of October 2026
| Software | End of security support | Status |
|---|---|---|
| CentOS 7 | June 30, 2024 | End of life |
| CentOS Stream 8 | May 31, 2024 | End of life |
| Ubuntu 20.04 LTS | May 2025 (standard support) | Paid Ubuntu Pro only |
| Debian 11 "bullseye" | August 31, 2026 (LTS) | End of life |
| PHP 7.4 | November 28, 2022 | End of life |
| PHP 8.1 | December 31, 2025 | End of life |
| PHP 8.2 | December 31, 2026 | Ends this year |
| MySQL 8.0 | April 2026 | End of life |
Dates change and vendors occasionally extend them. endoflife.date is an excellent, up-to-date reference for checking any product.
For new builds, the safe choices today are AlmaLinux 9 or 10, Ubuntu 24.04 LTS or Debian 13, with PHP 8.3 or newer and a current MySQL LTS or MariaDB release.
Check your server in five minutes
Log in over SSH and run these commands:
# Operating system and version
cat /etc/os-release
# PHP version (if installed)
php -v
# Database server version
mysql --version
# How long since the last reboot (very long uptimes often mean a stale kernel)
uptimeCompare the results against the table above. Running cPanel? The Server Information page in WHM shows the operating system, and MultiPHP Manager shows which PHP version each site uses. Old PHP versions often linger on individual sites long after the server default was updated.
Why it matters
- Unpatched vulnerabilities pile up. Every flaw discovered after end-of-life stays open for good. Attackers actively scan for old CentOS and PHP versions because they know the patches will never come.
- Software stops installing. Package repositories for old releases get archived or removed, so even routine maintenance starts to fail.
- Compliance and insurance. PCI DSS, cyber insurance questionnaires and client security reviews increasingly ask about unsupported software directly.
Live kernel patching tools like KernelCare are excellent for keeping a supported system's kernel patched without reboots. They don't fix the hundreds of other packages on an end-of-life system, though: OpenSSL, the web server, PHP and so on. If you're paying for extended lifecycle support from a vendor such as TuxCare, treat it as a bridge to buy time for migration, not a destination.
Your migration options
In-place upgrade
For CentOS 7, the ELevate project from AlmaLinux can upgrade a server in place to AlmaLinux 8, and then onward to 9. cPanel servers need cPanel's own ELevate-based process, because the control panel has its own requirements. In-place upgrades keep IP addresses and configuration, but they need careful preparation, a full backup and a tested rollback plan. Not every server is a good candidate.
Build new and migrate (usually our recommendation)
Provision a fresh server on a current OS, configure it cleanly, migrate sites, databases and email, test everything, then switch DNS. The old server stays untouched as a fallback until you're satisfied. This is also the right moment to move to faster NVMe hardware or right-size an oversized server. We often find clients paying for far more server than they need.
Upgrade the application stack
Moving from PHP 7.4 or 8.1 to 8.3 or newer can break older plugins, themes and custom code. Test each site on the new PHP version before switching. On cPanel this can be done per site, which makes it easy to upgrade gradually. WordPress sites usually make the jump smoothly once plugins are current. See 4 signs your WordPress website needs maintenance.
A migration checklist
- Inventory every server: OS, PHP versions per site, database version, and what each server does.
- Prioritize internet-facing servers and anything handling payments or personal data.
- Back up everything, and test a restore before you start.
- Choose in-place upgrade or rebuild for each server.
- Stage and test applications on the new OS and PHP version.
- Lower DNS TTLs a day or two ahead so the cutover propagates quickly.
- Migrate during a maintenance window, verify, and monitor closely afterward.
- Decommission the old server only after a few quiet days.
We can help
Green Olive Tree has been managing Linux servers since 2001. We handle CentOS-to-AlmaLinux migrations, cPanel server moves and PHP upgrades routinely, and we're a partner of AlmaLinux, cPanel, CloudLinux and TuxCare KernelCare. Once you're on a current platform, our proactive server management keeps it patched and monitored so you don't end up here again.
Not sure where your servers stand? Contact us and we'll help you check, or book a block of hourly support for the migration.