Upgrading CentOS 7 Without a Reinstall: What AlmaLinux's ELevate Actually Does

CentOS 7 reached end of life in mid-2024, and plenty of machines are still running it. The obvious options are painful: rebuild on fresh hardware and migrate everything, or pay for extended support and postpone the problem. AlmaLinux offers a third path that's less discussed: ELevate, a tooling layer on top of the upstream Leapp framework that performs an in-place major-version upgrade — CentOS 7 becomes AlmaLinux 8 on the same machine, with the same hostname, users, and data.

This post is about when that trade-off makes sense, what the process actually looks like, and where it bites people.

The thesis: in-place upgrades are a risk-management decision, not a shortcut

ELevate doesn't make upgrades free. It changes the shape of the work. Instead of provisioning a new server, reinstalling your stack, and migrating data, you spend your effort on assessment, testing on a clone, and resolving incompatibilities before the real run. For a fleet of similar machines, that effort amortizes well. For a single snowflake server running a decade of accumulated third-party packages, it may not.

One structural fact shapes everything: upgrades go one major version at a time. CentOS 7 → AlmaLinux 8 is one ELevate run. Getting to AlmaLinux 9 is a second run. Plan for two maintenance windows, not one.

How the Leapp framework drives the process

Leapp works in two phases. The assessment phase inspects your system — installed packages, kernel modules, repositories, configuration — and produces a report listing inhibitors: things that will block the upgrade until resolved. The upgrade phase then replaces packages, migrates configurations, and reboots into the new major version.

The assessment is where the real value is. You run it as root on the machine (or better, on a clone):

leapp preupgrade

This makes no changes to the system. It writes a report (conventionally under /var/log/leapp/leapp-report.txt) listing findings by severity. Typical inhibitors include:

• Packages from third-party repositories with no EL8 equivalent
• Out-of-tree kernel modules (proprietary storage or network drivers are the classic offenders)
• Deprecated services or removed configuration options
• Custom repository definitions Leapp doesn't know how to map

Only when the report is clean do you run leapp upgrade as root, which does change system state and ends in a reboot. Before that step, a verified backup or VM snapshot is not optional — an interrupted in-place upgrade can leave a system in a mixed state that's genuinely hard to recover.

A worked example: a web server with one problem package

Say you have a CentOS 7 VM running nginx from EPEL plus a monitoring agent from a vendor repo. A sensible dry run looks like this:

1. Snapshot the VM, or clone it and work on the clone.
2. Install the ELevate release package and Leapp data for your source/target pair, following the current AlmaLinux ELevate quickstart for your exact OS combination — supported paths change, so check the matrix rather than assuming.
3. Run leapp preupgrade and read the report.

Suppose the report flags the vendor monitoring agent as having no EL8 target. Your options: check whether the vendor publishes an EL8 build (if so, note it for post-upgrade reinstall), remove the agent before upgrading and reinstall after, or treat that machine as a candidate for clean migration instead. The report turns a vague worry into a specific decision.

After a successful leapp upgrade and reboot, verify before declaring victory:

cat /etc/almalinux-release
rpm -qa | grep -i el7 | head
systemctl --failed
journalctl -b -p err

Leftover el7 packages aren't automatically fatal, but each one deserves a look. Failed units and boot-time errors tell you what the upgrade didn't migrate cleanly.

The ABI-compatibility backdrop

There's a second decision embedded in choosing AlmaLinux as the target. Since Red Hat's 2023 source-policy change, AlmaLinux no longer rebuilds RHEL source bug-for-bug; it targets ABI (Application Binary Interface) compatibility instead, building from CentOS Stream sources and other inputs. In practice this means software compiled for RHEL 8/9 runs on AlmaLinux 8/9, but behavior can differ subtly in edge cases. If your workloads carry vendor certifications that name RHEL specifically, confirm that ABI compatibility satisfies them before betting the migration on it.

Where ELevate is the wrong tool

Be honest about the limitations:

• Stateful services. For database servers, dump-and-restore onto a fresh system is usually safer than upgrading the OS underneath a live data directory.
• Heavy third-party dependency. If the preupgrade report is a wall of inhibitors from custom repos, the cleanup cost may exceed a rebuild.
• Out-of-tree drivers. Proprietary kernel modules frequently break across major versions and need vendor updates that may not exist yet.
• Path coverage. ELevate supports specific source/target combinations. Verify yours is on the list before scheduling anything.

Closing: clone first, decide second

The actionable move costs almost nothing: clone one representative machine, run leapp preupgrade, and read the report. That single artifact tells you whether ELevate is a weekend project or a quarter-long cleanup for your environment — and it does so without touching production. If the report is clean, snapshot and run the full upgrade on the clone to validate your verification checklist. If it's not, you've learned that cheaply, and a clean migration plan is still on the table.