ELevate: Upgrading CentOS 7 to AlmaLinux 8 or 9 In Place

The short answer

If you still run CentOS 7 and cannot afford a rebuild, ELevate is the AlmaLinux project's supported path to migrate that machine in place to AlmaLinux 8 — or directly to AlmaLinux 9. It wraps the Leapp framework (the same engine Red Hat uses for RHEL in-place upgrades) with AlmaLinux-specific repository data, so the system keeps its hostname, users, data, and installed services while the OS underneath is swapped out.

The practical decision you face is not whether the tool works — it does, on clean systems — but whether your machine passes the pre-upgrade checks, and whether you should target 8 (full support until 2029) or 9 (until 2032). Target 9 unless an application vendor pins you to EL8 libraries.

How the mechanism works

Leapp runs as a pipeline of small, pluggable units called actors. Each actor does one job: scan installed packages, detect inhibitors (conditions that would break the upgrade), download replacement packages, build a temporary upgrade environment, and swap packages during a special boot. AlmaLinux contributes its own data package (leapp-data-almalinux) that maps CentOS 7 repositories to AlmaLinux equivalents and defines the target package set. Vendors such as cPanel and CloudLinux ship their own data packages, which is why ELevate works on some panel-managed systems where a generic Leapp run would fail.

The upgrade itself happens in two phases. leapp preupgrade is read-only: it analyzes the system and writes a report. leapp upgrade downloads everything, then reboots into an initramfs-based environment that performs the actual package replacement before booting the new AlmaLinux system.

Worked example: CentOS 7 to AlmaLinux 9

Run all commands as root (or via sudo) on the CentOS 7 machine. Do this on a clone or snapshot first — the upgrade is not reversible.

# 1. Fully patch the existing CentOS 7 system and reboot
yum update -y && reboot

# 2. Install the ELevate release package (adds the ELevate repo)
yum install -y https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm

# 3. Install Leapp plus the AlmaLinux mapping data
yum install -y leapp-upgrade leapp-data-almalinux

# 4. Dry-run analysis — changes nothing
leapp preupgrade --target=9

# 5. Review the report before doing anything else
less /var/log/leapp/leapp-report.txt

# 6. Only if the report shows no inhibitors:
leapp upgrade --target=9
reboot

Omit --target=9 to land on AlmaLinux 8, the default. The reboot after step 6 takes significantly longer than normal — the package swap happens during that boot, and interrupting power mid-swap can leave the system unbootable. On a VM, take the snapshot before step 6, not after.

After the system comes up, synchronize any stragglers and verify:

dnf distro-sync -y
cat /etc/redhat-release   # expect: AlmaLinux release 9.x
uname -r                  # expect a 5.14.x kernel for EL9
dnf repolist              # expect only AlmaLinux repos, no centos/ entries

What the preupgrade report is telling you

The report classifies findings as inhibitors (hard blockers you must fix), or informational items with suggested remediations. Read every inhibitor; leapp upgrade will refuse to run until they are resolved. The most common ones:

• Third-party kernel modules — NVIDIA drivers, ZFS, custom kernels. Remove them or move them to DKMS before upgrading; EL7-built modules will not load on a 5.14 kernel.
• Legacy network scripts — if interfaces are managed by /etc/sysconfig/network-scripts/ without NetworkManager, you can lose connectivity after the upgrade. Install and enable NetworkManager first and confirm it manages all interfaces.
• Disk space — keep at least 1 GB free in /boot (new kernel/initramfs) and roughly 2 GB in /var for logs and downloaded packages. Old kernels can be pruned with package-cleanup --oldkernels --count=1 from yum-utils.
• Unsupported configurations — for example, XFS on /boot or heavily customized partitioning may be flagged.

Limits and common mistakes

Databases are not migrated. Leapp replaces the MariaDB or PostgreSQL server packages but does not touch your data files. A major-version jump in the database engine usually requires a dump before the upgrade and a restore after, or a manual in-place data upgrade. Plan this separately and test it.

ELevate is AlmaLinux-specific. It does not target Rocky Linux or other derivatives. If you want a different destination, ELevate is not the tool.

Skipping the clone test is the classic failure. Preupgrade on production, see zero inhibitors, and assume the real run will be clean — then discover a forgotten third-party repo serving a package with no EL9 equivalent. Run the full sequence on a snapshot or cloned VM first, including application smoke tests afterward.

Expecting zero downtime. The upgrade requires at least one long reboot. Treat it like a maintenance window, not a rolling update.

Verifying the result

Beyond the release-file and kernel checks above, confirm that sshd and your critical services started (systemctl --failed should be empty), that network interfaces came up under NetworkManager (nmcli device status), and that applications respond. Keep the pre-upgrade snapshot until you have run the workload for several days. Finally, check the ELevate documentation at https://almalinux.org/elevate/ for the current list of supported versions and known issues — supported paths and data packages evolve between releases.