CentOS 7 Is Gone — ELevate Gets You to AlmaLinux Without a Rebuild

CentOS 7 reached end of life in June 2024, which means no more security patches, no more bug fixes, and a growing compliance problem for anyone still running it. The obvious answer — rebuild every server on a fresh OS — is expensive and slow. AlmaLinux's ELevate project offers a different path: a supported, open-source toolchain for upgrading a CentOS 7 machine in place to AlmaLinux 8, and from there onward to 9.

The thesis here is simple: for a legacy estate where rebuilding everything at once isn't realistic, ELevate turns an OS migration into a staged, testable engineering project instead of a forklift replacement. But it only works if you treat the pre-upgrade report as a gate, not a suggestion.

How ELevate actually works

ELevate is built on Leapp, the upstream framework Red Hat created for in-place major-version upgrades of RHEL. Instead of wiping the disk, Leapp analyzes your installed packages, runs a set of migration "actors" (small programs that each handle one aspect of the transition), downloads the target packages, and reboots into the new userland. Your data, configuration files, and service layout survive the trip.

What ELevate adds on top is distribution-specific metadata — the leapp-data package and the PES (Package Evolution Specification) events repository. This is the mapping layer that says "this CentOS 7 package becomes that AlmaLinux 8 package," including packages that were renamed, split into pieces, or dropped entirely between major versions. Without that mapping, Leapp would have no idea what to do with half your system.

Because AlmaLinux maintains ABI compatibility with RHEL, the result stays binary-compatible with the RHEL ecosystem. That matters if you run commercial software certified against RHEL rather than AlmaLinux specifically — the vendor's binaries will still run.

The two-hop rule for CentOS 7 estates

A key planning decision: you cannot skip major versions. Leapp does not support jumping from 7 to 9. The supported path is CentOS 7 → AlmaLinux 8 first, then AlmaLinux 8 → 9 as a second, separate upgrade. Budget for both hops, with validation after each. Trying to shortcut this is how upgrades end in a restore-from-backup afternoon.

A worked example: preupgrade on a staging clone

Never run the real upgrade against production first. Clone a representative server (a VM snapshot or a restored backup on spare hardware) and run the assessment there. On the clone, as root or via sudo:

sudo dnf install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade --target 8

The exact package names and target flags vary by source system and current ELevate releases, so confirm them against the official AlmaLinux ELevate documentation at the time you run this — supported version combinations change over time.

The preupgrade run produces a report (in /var/log/leapp/leapp-report.txt) listing findings and, critically, inhibitors — blockers that will stop leapp upgrade from proceeding at all. Common inhibitors on old CentOS 7 boxes include:

• Out-of-tree kernel modules, such as vendor storage or network drivers
• Deprecated PAM or authentication configuration
• Third-party packages Leapp has no mapping for
• Custom kernels or non-standard boot configurations

Every inhibitor must be resolved before you proceed. Some are cosmetic; others reflect genuine application incompatibilities, and ignoring that distinction is the most common way these projects go wrong. Once the report is clean on the clone, run sudo leapp upgrade, let it reboot, and validate.

Verification after the upgrade

Don't declare success because the machine booted. Check the OS identity with cat /etc/almalinux-release, confirm your critical services are running, and run application-level smoke tests. Then compare package inventories: capture rpm -qa | sort before the upgrade and again after, and diff them. Anything installed from outside the distribution repositories — locally compiled tools, vendor agents, hand-installed RPMs — is not covered by the migration mapping and typically needs manual reinstallation or rebuilding. That diff is how you find what fell through the cracks.

The honest trade-off

In-place upgrade trades rebuild effort for risk concentration. The failure modes live in exactly the software ELevate can't see: third-party repos, custom drivers, and anything compiled locally. A tested snapshot or full backup plus a rehearsed rollback plan is a prerequisite, not a nice-to-have. And for a server running one simple, well-understood workload, a clean rebuild on AlmaLinux 9 may genuinely be less total work than two upgrade hops — run the preupgrade report first and let the inhibitor list inform that call.

Where to start

Pick your most representative CentOS 7 server, clone it, and run leapp preupgrade this week. The report costs you nothing and tells you whether you're looking at a smooth migration or an application-compatibility project. Either way, you'll be planning from evidence instead of hope.