AlmaLinux was the first CentOS replacement out of the gate when Red Hat retired CentOS Linux, and for many teams it is the default choice. It is a 1:1 binary-compatible RHEL rebuild backed by the non-profit AlmaLinux OS Foundation, and, usefully, it ships two tools that make leaving CentOS less painful than a plain reprovision: an in-place converter and ELevate, a major-version upgrade path that the EL world otherwise lacks. If you are weighing Alma against Rocky, the migration mechanics are similar; this guide covers what is specific to Alma and where it genuinely differs.
The in-place converter
For CentOS 8 (and CentOS Stream 8) hosts, AlmaLinux’s almalinux-deploy.sh swaps the distribution in place:
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.shIt replaces the CentOS packages and GPG keys, verifies the result, and leaves you on AlmaLinux after a reboot. As with any in-place conversion: snapshot first, run it in a maintenance window, and pilot on a representative host before fleet-wide rollout. Rollback is your backup, nothing else.
The CentOS 7 problem, and ELevate
CentOS 7 is where Alma’s toolchain earns its keep. There is normally no supported in-place jump across an EL major version, which is why most CentOS 7 plans mean a full rebuild. AlmaLinux maintains ELevate, a project built on Red Hat’s leapp framework plus a community-maintained package-mapping database, that performs an in-place CentOS 7 → AlmaLinux 8 upgrade:
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux
sudo leapp preupgrade # read the report, resolve every inhibitor
sudo leapp upgradeThe preupgrade report is the important step, it flags inhibitors (removed packages, kernel modules, config conflicts) you must resolve before committing. ELevate is powerful but it is a real upgrade across a major version; treat it as higher-risk than the 8→Alma8 swap, snapshot aggressively, and pilot it on a true representative of each workload class. For your most critical CentOS 7 hosts, a clean reprovision onto Alma 9 is still the lower-risk choice, use ELevate where rebuilding is impractical.
Alma vs Rocky, how to actually choose
Technically they are interchangeable: both are binary-compatible EL rebuilds with ten-year lifecycles and no license fee. Decide on governance and assurance, not packages:
- AlmaLinux is governed by a non-profit foundation with a board, and after the 2023 RHEL source-availability changes it committed to staying ABI-compatible with RHEL rather than strictly bug-for-bug, which in practice has let it ship security fixes quickly.
- Rocky positions itself as a strict 1:1 RHEL rebuild via build transparency.
Either is a defensible answer. Pick one and standardise, running both across a fleet just doubles your validation surface for no benefit.
What carries over
Because Alma is binary-compatible, EPEL, “el8”-targeted third-party repos, SELinux policy, and RHEL-certified software all work unchanged. The cleanup list is the familiar one: replace CentOS repo files, re-point hard-coded CentOS mirror URLs, update FROM centos:* container bases to almalinux/* or a UBI image, and fix any automation that string-matches CentOS in /etc/os-release or your config-management facts.
What to verify per host
Whether you swapped CentOS 8, ran ELevate, or reprovisioned, do not sign off a host until:
- OS identity in
/etc/os-releaseand/etc/redhat-releasereads AlmaLinux, on the standard kernel. - Repos resolve: AlmaLinux BaseOS and AppStream enabled, EPEL and third-party repos working, no leftover centos-release files.
- SELinux is in its expected mode and policy modules load without denials.
- Services and agents all return after a full reboot and re-check-in with backup, monitoring, and security systems.
- Containers and automation no longer reference CentOS bases or string-match CentOS in facts.
For ELevate specifically, add: confirm the upgrade actually reached AlmaLinux 8 (not a half-upgraded state), that leapp left no pending actions, and that the boot loader points at the new kernel.
Keeping a way back
For the almalinux-deploy swap, rollback is the pre-conversion snapshot, so batch conversions small. ELevate is the case that most needs a solid rollback: because it crosses a major version, a failed run can leave a host that will not boot, so snapshot aggressively and validate the restore path before you run it in anger. For reprovisioned hosts, keep the original CentOS box drained but powered until the Alma replacement is proven, then cut over and decommission. Leaving an EOL OS is urgent, but not so urgent that you should destroy your only fallback before validation.
Making the call
If you want to stay in place rather than rebuild, AlmaLinux gives you the most options: almalinux-deploy for CentOS 8 and ELevate for the otherwise-stuck CentOS 7 estate. Snapshot before every conversion, resolve every ELevate inhibitor from the preupgrade report, and reprovision your most critical CentOS 7 hosts onto Alma 9 instead of upgrading them. The decision between Alma and Rocky is a governance call, not a technical one, so make it once, document why, and apply it consistently.