When the CentOS-as-RHEL-rebuild model ended with the shift to CentOS Stream, two community rebuilds filled the gap: Rocky Linux and AlmaLinux. Both are 1:1, binary-compatible RHEL clones with no license fee, and the migration mechanics are nearly identical. This guide covers AlmaLinux specifically and where it differs from the Rocky path.
AlmaLinux vs Rocky, how to choose
Technically they’re interchangeable: same packages, same versions, same long support lifecycle, ABI-compatible with RHEL so RHEL-certified software runs unchanged. The differences are governance and approach:
- AlmaLinux is run by the non-profit AlmaLinux OS Foundation and, post-2023, builds to be ABI-compatible with RHEL (rather than strictly 1:1 from sources), which has let it keep shipping smoothly and even patch independently when useful.
- Rocky Linux (RESF) aims for bug-for-bug rebuilds.
Pick on community fit and governance preference; the migration below applies to either, so this isn’t a technical decision so much as an organizational one.
What you trade away
As with any RHEL exit, you give up the Red Hat subscription and its ecosystem: official 24×7 support and SLAs, Red Hat Insights, and Satellite. If a vendor contract specifically requires “RHEL,” confirm they support rebuilds first. Commercial support for AlmaLinux is available (e.g., TuxCare) if you want a safety net; many run it community-supported.
The in-place conversion
AlmaLinux provides almalinux-deploy, which converts RHEL/CentOS (and other EL rebuilds) in place:
curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.shIt swaps the distro packages and GPG keys, then you reboot into AlmaLinux. Convenient, but reversible only via your backup, so snapshot first.
For critical hosts, reprovisioning (fresh AlmaLinux from a kickstart/image, redeploy config via Ansible) is cleaner: a drift-free baseline and a trivial rollback (the old host is untouched).
Convert in place or rebuild?
The trade is the same one you face with any EL rebuild. In-place conversion is fast and preserves the host’s exact state, including whatever undocumented tweaks have accumulated over the years, which is convenient right up until one of those tweaks is what breaks. Reprovisioning is more work up front but forces you to express the host in code, so the AlmaLinux replacement is reproducible and the RHEL original stays available as a rollback. A workable policy: convert well-managed, stateless hosts in place, and rebuild the long-lived, hand-tuned ones. If a host is already fully owned by Ansible, in-place conversion is low risk because you can rebuild it anyway.
The sequence to follow
- Snapshot/back up every host before converting.
- Test on non-production first, a representative app server.
- Convert with
almalinux-deploy(or reprovision), then reboot. - De-register from Red Hat:
subscription-manager unregister; remove RHSM/Insights agents. - Validate packages, enabled repos (EPEL works the same), third-party repos, Secure Boot if used, and that services return.
Confirming the conversion took
Before signing off a converted host, confirm on the host:
- OS identity:
/etc/os-releaseand/etc/redhat-releasereport AlmaLinux and the standard kernel is running. - Repositories: AlmaLinux BaseOS and AppStream are enabled, EPEL and third-party repos still resolve, and no stale RHSM repo files linger.
- Packages: nothing is still signed by Red Hat GPG keys and no critical package was dropped in the swap.
- Services and agents: every service returns after a reboot, and backup, monitoring, and security agents re-check-in while RHSM and Insights agents are removed.
- Boot: if Secure Boot is enabled, the machine boots on the AlmaLinux shim and kernel signatures on your real hardware.
Backing out safely
The converter has no built-in undo, so the snapshot you took beforehand is your rollback for an in-place conversion. Convert in small batches so a single window is always recoverable. For a reprovisioned host, rollback is simply draining traffic back to the still-running RHEL box and discarding the new AlmaLinux host. Keep the source available through hypercare rather than decommissioning it the moment the replacement answers.
Releasing the entitlements
Savings arrive only when the entitlements are actually freed. After each host is validated, run subscription-manager unregister, remove the RHSM and Insights packages, and verify in the Red Hat portal that the per-socket entitlement returns to the pool. Track it per host: converting the fleet but forgetting de-registration on a subset means you keep paying for entitlements no running system uses. The modelled saving is real only once the entitlement count drops.
Watch for these
- Do it in a maintenance window, it touches core packages.
- Inventory layered Red Hat products that may not be supported on a rebuild.
- If you used Satellite/Insights, plan a replacement (local mirror + Ansible).
- AlmaLinux’s ABI-compatibility (vs strict 1:1) is a non-issue for the vast majority of workloads, but worth knowing if you depend on exact build-level behavior.
Where this leaves you
RHEL → AlmaLinux is the same high-confidence, low-cost migration as the Rocky path: a binary-compatible OS with a long lifecycle and an in-place converter (almalinux-deploy). The choice between AlmaLinux and Rocky is about governance, not difficulty, snapshot first, test on non-prod, reprovision critical hosts, and confirm any RHEL-only vendor support. Model the per-system subscription savings in the calculator above, and treat them as illustrative until you confirm your support strategy.