Still Running CentOS 7 in 2026? ELS vs Migration, Honestly Compared

$ cat /etc/os-release | grep -E '^(NAME|VERSION_ID)='
NAME="CentOS Linux"
VERSION_ID="7"
$ sudo yum check-update
Loaded plugins: fastestmirror, ovl
Could not retrieve mirrorlist http://mirrorlist.centos.org/?release=7&arch=x86_64&repo=os
error was
14: curl#6 - "Could not resolve host: mirrorlist.centos.org"

If you are still reading past the TL;DR, you almost certainly know your reasons already: a vendor appliance that only ships a CentOS 7 image, an internal app nobody wants to touch, a box that has been up for six years and everyone is scared to reboot it let alone reinstall it. None of that is stupid. It is just risk that used to be invisible and stopped being invisible on June 30, 2024.

What "end of life" actually means here, concretely

CentOS 7 followed the same lifecycle as the RHEL 7 it rebuilds, and that clock ran out. No more errata, no more CVE patches, no more kernel updates, full stop. Red Hat itself still sells RHEL 7 Extended Life Cycle Support to paying subscribers, which tells you plainly that the underlying code still needs patching, Red Hat just will not give it to you for free anymore, and CentOS never had that paid option to begin with because CentOS was never a subscription product.

OpenLogic's own survey research, cited widely across the RHEL-family press, found that 38 percent of organizations still running end-of-life CentOS said they had no plan to address newly discovered vulnerabilities. That is not a scare number invented for a blog post, it is orgs admitting on a survey that they know the exposure exists and are not budgeting for it. If your CentOS 7 box talks to the internet in any capacity (a web app, an API, even outbound package installs from a now-unpatched OpenSSL), every CVE disclosed against RHEL 7 packages from June 2024 onward is a CVE your box will never see fixed, unless you do one of the two things below.

Path 1: pay for Extended Lifecycle Support (buy time, do not fix the underlying problem)

Several vendors, TuxCare, OpenLogic, and CIQ among them, sell CVE-patch backporting for CentOS 7 past its EOL date, delivered through your existing package manager once you repoint it at their repos. This is a real, legitimate service, the same idea Red Hat sells for RHEL itself, just aimed at the CentOS rebuild that never had an official paid tier. It is not a workaround or a hack: these vendors maintain their own patch pipelines and backport fixes for critical and high-severity CVEs, typically within a defined SLA window (TuxCare advertises 14 days for newly disclosed critical and high issues, for example).

What it does not do: it does not give you newer software, newer kernels, or a path to features that shipped in EL8, EL9, or EL10. You are still running a 3.10-series kernel and 2020-era userspace, just with the worst CVEs quietly patched underneath it. Pricing is per-system, billed monthly or annually, and tiers vary by vendor, so treat any specific dollar figure you see quoted online as a starting point to confirm on the vendor's current page rather than something to budget against blind.

ELS makes sense when the box genuinely cannot be touched on any near-term timeline: a certified medical or industrial appliance image, a vendor stack where the vendor itself has not certified anything newer, a system you are actively decommissioning in the next few months anyway so a migration project is wasted effort. It does not make sense as a permanent substitute for migration on anything you actually control the software stack of, because you are still paying to run 2020-era software with 2026-era CVEs quietly triaged behind it, and that gap only gets wider.

Path 2: migrate in place with ELevate, no reinstall required

If you control the stack and can tolerate a maintenance window, this is the path that actually gets you off borrowed time. The AlmaLinux-maintained ELevate project wraps Red Hat's own leapp upgrade tool with the data needed to jump CentOS 7 to a rebuild of EL8, in place, preserving your data, users, and installed applications through the upgrade. One important detail people get wrong: ELevate moves one major version at a time. There is no direct CentOS 7 to AlmaLinux 10 jump. You go 7 to 8 first, then 8 to 9, then 9 to 10 if you want to land on the current release with a long runway ahead of it. Budget for a maintenance window per hop, not one single leap.

Before anything else: snapshot or back up the box. This is an in-place kernel and userspace replacement on a production filesystem, and a bad upgrade mid-flight is a much worse day than a clean restore from a snapshot taken five minutes earlier.

# 1. Fully update and reboot the CentOS 7 box first, leapp refuses to run on a stale system
$ sudo yum update -y && sudo reboot
Output length varies with what is pending, that part does not matter. The reboot completing cleanly afterward is what this step actually confirms before you touch leapp.

# 2. After reboot, install the ELevate repo package
$ sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el$(rpm --eval %rhel).noarch.rpm
Installed:
  elevate-release.noarch 0:1.0-1.el7

# 3. Install leapp and the AlmaLinux upgrade data
$ sudo yum install -y leapp-upgrade leapp-data-almalinux
Installed:
  leapp.noarch leapp-upgrade.noarch leapp-data-almalinux.noarch (and dependencies)

# 4. Run the pre-upgrade check. This step is expected to report problems on a default install, that is its job.
$ sudo leapp preupgrade
============================================================
                     REPORT OVERVIEW
============================================================
Highest task risk: high
Total number of possible problems: N
Reports summary:
    Errors: 0
    Inhibitors: N (you must resolve these before upgrading)
============================================================
A report has been generated at /var/log/leapp/leapp-report.txt

Read /var/log/leapp/leapp-report.txt line by line. It names actual inhibitors on your specific box, most commonly third-party repos leapp does not have upgrade data for (disable them with yum-config-manager --disable and re-add after), a non-stock kernel, or insufficient free space on /boot. Fix each one, then re-run leapp preupgrade until it reports zero inhibitors. Do not skip an inhibitor with a leapp flag unless you have personally confirmed what it is protecting against, that flag exists for edge cases, not for impatience.

Some inhibitors are not a fix at all, they are a question leapp needs an explicit answer to before it will proceed, for example whether it is safe to remove a PAM module. Those show up as an unresolved entry in /var/log/leapp/answerfile. Resolve them there directly (uncomment the relevant confirm = line and set it to True or False) or with leapp answer --section <name>.confirm=True, then re-run leapp preupgrade to confirm it is clean. Do this now, not during the next step: leapp upgrade itself does not stop to ask you anything.

# 5. Once the report is clean, start the actual upgrade
$ sudo leapp upgrade
Runs unattended, no prompt appears. Progress messages only, this stage takes roughly 20-40 minutes.
If you skipped an answerfile question in step 4, this halts immediately instead:
Inhibitor: Missing required answers in the answer file. Go back, resolve it, and re-run leapp preupgrade first.

# 6. Reboot into the special upgrade initramfs, then again into the new system
$ sudo reboot

# 7. Verify the landing
$ cat /etc/redhat-release
AlmaLinux release 8.10 (Cerulean Leopard)

The box reboots twice: once into an ELevate-Upgrade-Initramfs GRUB entry that leapp adds automatically, where the actual package and kernel replacement happens, and once more into the finished AlmaLinux 8 (or Rocky 8, depending on which leapp-data-* package you installed in step 3) system. If you land there cleanly, SELinux will trigger a full filesystem relabel on that first real boot into the new system, which is normal and can take several minutes on a busy disk, not a hang. If you see AVC denials on a service after the relabel settles, work them the right way with ausearch and audit2allow rather than reaching for setenforce 0, our SELinux AVC troubleshooting guide walks through exactly that.

From AlmaLinux or Rocky 8, you are on a distro with a real, published lifecycle again (both run through May 2029 on the 8 line, longer if you keep hopping to 9 and eventually 10), and every guide on this site for the current RHEL-family releases applies to you the same way it applies to a box provisioned fresh. If you have not settled on which of the two rebuilds to land on for the long term, our Rocky vs AlmaLinux comparison covers what actually differs between them since 2023 and which reasons to pick either one. Once you are there, the initial server setup guide covers hardening users, SSH, and firewalld the same way regardless of which major version you land on.

Disclosure: the Vultr link below is a referral. You get 300 dollars of trial credit for 30 days. This site earns a commission only if you stay active past 30 days and spend 100 dollars or more. Both sides of that arrangement, in full.

Do not run your first ELevate attempt against a production box you cannot afford to lose. I keep a pair of disposable lab instances on Vultr's 300 dollar trial credit specifically for rehearsing exactly this kind of in-place upgrade before I let it near anything real: deploy a CentOS 7 image, run the whole ELevate flow above start to finish, confirm the app still works, then and only then schedule the window on the real box.

Which path actually fits your box

Ask one question: do you control the software running on this box, or does a vendor? If it is your own app or a standard service (nginx, a database, a custom binary you built), migrate, there is no good long-term argument for paying indefinitely to freeze it at 2024's patch level. If it is a vendor appliance where the vendor has not certified anything past CentOS 7 and reinstalling voids support, ELS buys you the runway to either get the vendor to certify a newer target or plan its replacement, without running fully unpatched in the meantime. And if it is genuinely air-gapped with no network path in or out at all, honestly weigh whether either option is worth the spend right now, an isolated box's exposure window is a different risk calculation than one sitting on the open internet.

Wrap up

CentOS 7 is not going to get patched again no matter which option you pick, that part is settled and has been for over two years. ELS is a legitimate way to buy time on a box you genuinely cannot touch yet, not a substitute for a plan. ELevate is the actual exit, and it works in place without a reinstall, one major version at a time. Pick based on who actually controls the software on the box, not on which option feels less scary this week, because the exposure window does not care which one felt easier.