If you are leaving Oracle Linux to escape the support subscription and the Oracle ecosystem pull, AlmaLinux is one of the two natural destinations (Rocky is the other). Both are 1:1 RHEL rebuilds, so the choice is about governance rather than packages. AlmaLinux brings two things that are handy when leaving Oracle Linux specifically: an in-place converter and ELevate, a major-version upgrade path. This guide covers what is Alma-specific and the Oracle Linux details (mainly the kernel) that apply whichever rebuild you pick.
Why it is nearly mechanical
Oracle Linux and AlmaLinux are both binary-compatible with RHEL, so packages, versions, SELinux policy, EPEL, and RHEL-certified software all carry over with no application changes. You are moving between two builds of the same upstream, the work is in the conversion mechanics and in de-Oracling the host, not in re-platforming anything.
Converting Oracle Linux 8 in place
For Oracle Linux 8, AlmaLinux’s converter 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 Oracle packages, repos, and GPG keys, verifies the result, and leaves you on AlmaLinux after a reboot. Snapshot first, pilot on a representative host, and run it in a maintenance window.
The Oracle-specific catch: the UEK kernel
Oracle Linux can boot Oracle’s Unbreakable Enterprise Kernel (UEK) instead of the standard RHEL-compatible kernel that AlmaLinux uses. Before converting:
- Confirm whether hosts run UEK, and that nothing depends on UEK-only modules or features.
- After conversion you run the standard kernel, so validate storage and network drivers on a pilot host before scaling.
Oracle Linux 7: use ELevate
There is normally no in-place jump across an EL major version, which is why OL7 usually means a rebuild. AlmaLinux’s ELevate (built on Red Hat’s leapp plus a community package-mapping database) performs an in-place OL7 to 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 # resolve every inhibitor in the report first
sudo leapp upgradeRead the preupgrade report carefully and resolve inhibitors before committing. For your most critical OL7 hosts, a clean reprovision onto Alma 9 is still lower-risk than an in-place major upgrade.
Alma or Rocky?
Technically interchangeable: both are RHEL-compatible rebuilds with ten-year lifecycles and no fee. Decide on governance. AlmaLinux is run by a non-profit foundation and committed to staying ABI-compatible with RHEL (which has let it ship security fixes quickly); Rocky positions itself as a strict bug-for-bug rebuild via build transparency. Pick one, standardise, and document the reason.
What to clean up
Whichever you choose, remove the Oracle bits so hosts stop depending on Oracle infrastructure: ULN registration, Ksplice (no direct Alma equivalent, plan kpatch or a reboot cadence), Oracle Cloud agents, and any UEK leftovers.
The extra items UEK adds to your checks
The Oracle-specific items make this list longer than a plain RHEL-rebuild conversion. Before signing off a host:
- Kernel: the host runs the standard RHEL-compatible kernel, no UEK kernel or UEK-only modules remain, and the boot default points at the standard kernel.
- Drivers: storage and network drivers behave the same off UEK, checked under real load rather than only at boot.
- OS identity:
/etc/os-releaseand/etc/redhat-releasereport AlmaLinux. - Repos: AlmaLinux BaseOS and AppStream are enabled, EPEL and third-party repos resolve, and no Oracle or ULN repo definitions linger.
- Oracle agents gone: ULN, Ksplice, and Oracle Cloud agents are removed and no longer phoning home.
- Services and agents return after a full reboot and re-check-in with backup, monitoring, and security.
For ELevate’d OL7 hosts, also confirm the upgrade actually reached AlmaLinux 8, leapp left no pending actions, and the boot loader points at the new kernel.
Getting back to a working state
For an in-place OL8 conversion, rollback is the pre-conversion snapshot, so convert in small batches. The kernel switch makes that snapshot doubly valuable: if a driver misbehaves on the standard kernel, restoring the UEK-booting snapshot is the fastest recovery. ELevate needs the most careful rollback because a failed cross-major upgrade can leave a host that will not boot, so snapshot aggressively and test the restore path first. For reprovisioned OL7 hosts, keep the original Oracle box drained but powered until the Alma 9 replacement is proven, then cut over and decommission.
Stopping the Oracle support spend
The saving is the removed Oracle Linux Support subscription, and it only lands once you stop the support relationship for the migrated hosts. After each host is validated on AlmaLinux and de-Oracled, reconcile it against your Oracle support agreement so you are not renewing coverage for systems that no longer run Oracle Linux. Oracle support is a per-system subscription, so track the migration host by host and let the support count fall as machines move across. Decide early whether the freed budget stays as savings or partly funds optional AlmaLinux commercial support for critical hosts, and treat the figures in the calculator above as illustrative until your support posture is settled.
What this comes down to
Oracle Linux to AlmaLinux drops the Oracle support subscription and ecosystem while keeping a RHEL-compatible OS. Convert OL8 in place with almalinux-deploy, use ELevate (or reprovision) for OL7, and validate the move off UEK to the standard kernel. Strip ULN, Ksplice, and Oracle agents afterward. The Alma-versus-Rocky decision is governance, not technology, so make it once. Model the removed Oracle support cost against optional AlmaLinux commercial support in the calculator above.