CentOS Alternatives in 2026: AlmaLinux vs Rocky Linux (and How to Migrate)

CentOS is dead — here's the short version

CentOS Linux is discontinued. CentOS 8 was cut short and reached end of life on 31 December 2021; CentOS 7 reached end of life on 30 June 2024. Running either today means no security updates. And CentOS Stream is not the replacement most people want: since the 2020 pivot it sits upstream of Red Hat Enterprise Linux — a rolling preview of the next RHEL, not a downstream stable rebuild of it.

The two real successors are AlmaLinux and Rocky Linux. Both are free, both are RHEL-compatible, both are legitimate CentOS Linux replacements. Here is the conditions-based answer this guide will justify:

• Choose AlmaLinux if you run a hosting stack (cPanel, CloudLinux), want faster security patches, or need a distribution that holds its own FIPS 140-3 validation.
• Choose Rocky Linux if you specifically need strict 1:1 binary parity with RHEL — bug-for-bug — because a vendor or an internal certification demands the identical build.
• Choose RHEL itself if compliance requires a paid support SLA and vendor certification, and you can absorb the subscription.
• Do not choose CentOS Stream as a stable production base. It is excellent for previewing RHEL and for development; it is not a fixed, point-release target.

The rest of this article is why, and — because that is the part every other guide skips — exactly how to migrate, with the failure points named.

What actually differs now: ABI vs 1:1 binary

Before June 2023 the two projects were doing the same thing: rebuilding Red Hat's published RHEL sources into a free, identical distribution. Then Red Hat restricted RHEL source distribution to its customer portal, leaving CentOS Stream as the only public source. AlmaLinux and Rocky responded differently, and that difference is the whole decision.

Rocky Linux chose to stay 1:1. It keeps building from the exact RHEL source RPMs, obtaining them through routes that don't require accepting Red Hat's subscription terms. In Rocky's own words from Keeping Open Source Open: one route is "the usage of UBI container images which are based on RHEL," another is "pay-per-use public cloud instances… anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata" — all "without compromising our commitment to open source software or agreeing to TOS or EULA limitations." The result is a distribution designed to be bug-for-bug identical to RHEL.

AlmaLinux chose ABI compatibility instead. Rather than chase byte-identical packages, AlmaLinux dropped the 1:1 aim and now builds primarily from CentOS Stream, targeting Application Binary Interface compatibility: "software that runs on RHEL will run the same on AlmaLinux." In their own footnote, ABI compatibility means "working to ensure that applications built to run on RHEL (or RHEL clones) can run without issue on AlmaLinux." Building from Stream rather than waiting for released RHEL sources also lets AlmaLinux ship some fixes ahead of the downstream cadence.

So what does "ABI-compatible versus 1:1 binary" actually change for a running server? Less than the debate implies, in three specific places:

• Third-party and ISV RPMs: No practical difference. Both satisfy the RHEL ABI, so anything built for RHEL — a vendor agent, a database RPM, a monitoring package — installs and runs on either. This is the case that matters to almost everyone, and it is a non-issue.
• Kernel modules (kmods): Both track the RHEL kernel and its kABI, so pre-built out-of-tree modules generally load on both. The theoretical edge is Rocky's: a byte-identical kernel is a stronger guarantee for a binary kmod than an ABI guarantee. In practice AlmaLinux maintains kABI parity and there is no documented, reproducible breakage — treat this as Rocky positioning, not an observed AlmaLinux fault.
• FIPS 140-3: This is the one place the split is materially visible. AlmaLinux has its own FIPS 140-3 validation — the AlmaLinux 9.2 cryptographic modules were validated (funded and submitted by CloudLinux), with later releases progressing through NIST's pipeline. Rocky Linux does not hold its own NIST validated certificate; its modules have appeared on NIST's Modules-in-Process list, and FIPS compliance for Rocky is offered commercially by CIQ/TuxCare. The crypto code is functionally the same as RHEL's on both — the difference is the certificate, and if you have a procurement checkbox that says "FIPS 140-3 validated," that distinction is the whole game.

One more axis behind the two projects: who funds and governs them. AlmaLinux is backed by CloudLinux, a founding platinum sponsor committed to roughly $1M/year, and is stewarded by the non-profit AlmaLinux OS Foundation. Rocky Linux is run by the Rocky Enterprise Software Foundation (RESF), with commercial support from CIQ. Neither is going anywhere; both have been shipping on schedule for years. This is not the drama it was in 2023.

CentOS Stream: useful, but not your production base

It is worth being precise about Stream because the naming misleads people. Red Hat now develops RHEL in CentOS Stream: Stream is "continuously delivered" and "tracks just ahead of RHEL development." That means Stream receives changes before they land in a released RHEL point release — the opposite of the old CentOS Linux, which trailed RHEL.

Stream is genuinely good for two things: previewing what is coming in the next RHEL, and CI/development against the RHEL that will exist in a few months. It is a poor fit as a fixed production base, because it is a rolling target with no stable point releases to pin to. If your instinct is "CentOS Stream is the natural continuation of CentOS," reset it — the continuation you want is AlmaLinux or Rocky. For context on where all of this sits next to Ubuntu and Debian, see our hub guide on choosing a Linux distribution for a dedicated server.

Side-by-side: the dimensions you actually decide on

Two rows there deserve calling out because they moved recently and they decide real cases:

cPanel dropped Rocky Linux in version 134. As of cPanel & WHM version 134 (released January 2026), you cannot upgrade a Rocky Linux server to the current cPanel; the supported OS list is AlmaLinux 8/9/10, CloudLinux 8/9/10, and Ubuntu 24.04 LTS, and cPanel explicitly recommends converting Rocky servers to AlmaLinux. If you run cPanel, this alone settles the AlmaLinux-vs-Rocky question. (Verify against cPanel's live release notes before you act — this is recent and fast-moving.)

Rocky EOLs the previous minor the moment a new one ships. Unlike RHEL's Extended Update Support, Rocky's policy is that once, say, 9.7 is out, 9.6 is immediately end-of-life. If you need to stay on a specific minor for an extended qualification window, that is a point in RHEL's favour, not Rocky's.

The verdict, without the hedge

Every other comparison ends on "both are excellent, it depends." Here is the version that actually commits:

• Running cPanel or a CloudLinux stack? → AlmaLinux. cPanel dropped Rocky, CloudLinux is the company behind Alma, and the CloudLinux/Immunify/hardened-kernel ecosystem is built around it. This is not close.
• Want the freshest security patches on a free EL? → AlmaLinux. Building from Stream lets it push some fixes ahead of the strict-downstream cadence.
• Need a validated FIPS 140-3 module on a free distro? → AlmaLinux, which holds its own certificate. Rocky needs a commercial add-on for that.
• Have a vendor or internal rule demanding byte-identical RHEL builds? → Rocky Linux. If a certification literally requires "the same binary as RHEL," Rocky's 1:1 model is the safe answer.
• Bound by compliance to a supported, certified OS with an SLA? → RHEL, and bring the subscription. Our RHEL dedicated servers let you bring your own entitlement.

For most people leaving CentOS in 2026 — especially anyone in hosting — the pragmatic default is AlmaLinux. Rocky is the right call for the narrower "I need bit-for-bit RHEL" requirement. Both beat staying on an EOL CentOS by an infinite margin, because "no security updates" is not a strategy.

Migrating off CentOS, step by step

There are two very different situations, and conflating them is where people get hurt:

1. You are on CentOS 8 (or another EL8/EL9 rebuild) and want to move sideways to Rocky or Alma at the same major version. This is a well-supported, scripted, in-place conversion.
2. You are on CentOS 7 and need to cross a major version (7 → 8 → 9). This is a Leapp-based upgrade, it is genuinely harder, and it will throw a wall of pre-flight inhibitors at you. That wall is the real content — every fleet hits it.

The commands below are the real tools, flags, and repositories. The console output shown is representative of what each tool prints, to illustrate the shape of a run — substitute your own hostnames and expect your own package counts. Always run against a snapshot or a throwaway clone first, never a production box you can't roll back.

Before you touch anything: the pre-flight checklist

Same for all three paths:

• Take a full snapshot or image-level backup. These conversions are effectively one-way; there is no clean "undo" script. Your rollback plan is the snapshot (see below).
• Inventory third-party repositories (dnf repolist / yum repolist). EPEL is fine; vendor repos (a database, a monitoring agent, a panel) may pin packages that fight the conversion. Note them.
• List out-of-tree kernel modules (lsmod, DKMS packages) — storage/NIC drivers, ZFS, proprietary agents. These are the usual breakage.
• Record your panel/control-plane (cPanel, Plesk, CloudPanel) and check its supported-OS matrix for the target before you start.
• Confirm free disk space for a full package re-download and swap, and that the box can reach the target repos.

Path A — CentOS/EL8 or EL9 → Rocky Linux (migrate2rocky)

Rocky ships migrate2rocky in the rocky-tools repository. There are two scripts: migrate2rocky.sh converts an EL8 system to Rocky 8, and migrate2rocky9.sh converts EL9 to Rocky 9. Fetch the one that matches your major version and run it with -r to perform the conversion:

# On an EL8 system (CentOS 8 / other EL8 rebuild)
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
sudo ./migrate2rocky.sh -r

The script removes the old distro's identity packages, installs the Rocky release and GPG packages, points every repo at Rocky, and reinstalls the base system from Rocky mirrors. A published CentOS 8 → Rocky 8 walkthrough captures the shape of a real run — it maps each repo, lists the CentOS packages it will swap for Rocky equivalents (centos-linux-release → rocky-release, centos-gpg-keys → rocky-gpg-keys, centos-linux-repos → rocky-repos), and ends on Complete! / Done, please reboot your system. Representative output:

migrate2rocky - Begin logging at Tue Jul  7 09:14:02 2026.

Removing dnf modules that are not compatible with Rocky Linux...
Identifying repositories to be replaced...
Determining repository names for Rocky Linux...
Repository baseos matched by repository id baseos.
Repository appstream matched by repository id appstream.
Removing distribution packages: centos-linux-release centos-gpg-keys ...
Installing Rocky Linux release package: rocky-release rocky-gpg-keys ...
Switching old release to Rocky Linux release.
Distro-syncing to Rocky Linux ...
...
Complete!
Done, please reboot your system.

Reboot, and confirm you landed on Rocky:

$ cat /etc/redhat-release
Rocky Linux release 8.10 (Green Obsidian)
$ rpm -q rocky-release
rocky-release-8.10-1.5.el8.noarch

Two caveats before you run this on anything you care about. CIQ — the company behind Rocky — warns that custom-compiled kernel modules can cause failures "that could leave your machine inoperable," so lab-test first; and on a UEFI box you may have to pick the Rocky boot entry manually in GRUB on the first reboot. There is no reliable published wall-clock for the conversion — it's a package swap plus a distro-sync, bounded by download and dnf time, typically minutes to tens of minutes on a modest box. Time your own snapshot run to get a figure you can trust.

Path B — CentOS/EL8 or EL9 → AlmaLinux (almalinux-deploy)

AlmaLinux ships almalinux-deploy, a single script that converts a same-major EL system (8.4+, 9, or 10) to AlmaLinux. It runs a pre-flight compatibility check first, then swaps release packages and reinstalls from AlmaLinux repos:

curl -O https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh
sudo bash almalinux-deploy.sh

The status strings the almalinux-deploy.sh script prints — each followed by OK or ERROR — run in roughly this order:

Check root privileges                                               OK
Check Secure Boot disabled                                          OK
Check centos-8.x86_64 is supported                                  OK
Your OS is supported
Download the AlmaLinux GPG public key                               OK
Install almalinux-release package                                   OK
Run dnf distro-sync -y                                              OK
Enabled AlmaLinux repositories that were before the migration       OK
Migration to AlmaLinux is completed

Reboot and verify:

$ cat /etc/almalinux-release
AlmaLinux release 8.10 (Cerulean Leopard)

The AlmaLinux migration guide sets the prerequisites: the source must be EL 8.4 or newer, Secure Boot disabled (the Check Secure Boot disabled line is exactly where the script stops if it isn't), a boot partition with room for three kernels, and — as always — a snapshot taken first.

Path C — CentOS 7 → 8 → 9 (ELevate, and the inhibitor wall)

CentOS 7 is the hard case, and it is where honesty separates a useful guide from a command dump. You cannot jump CentOS 7 straight to a version-9 distribution. AlmaLinux's own ELevate guide is explicit: Leapp performs one-step upgrades, so the path is 7 → 8, then 8 → 9 (and 9 → 10 after that if you want the newest). Each hop is a separate Leapp run with its own pre-flight.

ELevate is the AlmaLinux project's Leapp-based tooling that extends Red Hat's Leapp to cross-distro, cross-major upgrades. The 7 → 8 run looks like this:

# Install ELevate + the AlmaLinux migration data
sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux

# Pre-flight analysis — this is the important part
sudo leapp preupgrade

leapp preupgrade does not upgrade anything. It analyses the system and writes a report to /var/log/leapp/leapp-report.txt listing inhibitors — blocking problems you must resolve before Leapp will proceed. On a real CentOS 7 box you should expect several, and the same handful recur in write-up after write-up. These are the ones people actually hit, quoted from real reports, with the documented fix:

• Removed kernel drivers. "Detected loaded kernel drivers which have been removed in RHEL 8. Upgrade cannot proceed." The usual culprits are pata_acpi and floppy (plus the mpt* SCSI drivers on VMware guests); unload them with modprobe -r pata_acpi floppy and re-run. (Valentin S, Vander Host)
• The pam_pkcs11 answer. "Missing required answers in the answer file" for remove_pam_pkcs11_module_check.confirm — Leapp makes you acknowledge it explicitly: leapp answer --section remove_pam_pkcs11_module_check.confirm=True. (CIQ KB)
• Root login over SSH. "Possible problems with remote login using root account" — set PermitRootLogin yes in /etc/ssh/sshd_config so you don't lock yourself out after the upgrade. (Bigstep)
• A broken third-party repo. Bad vendor-repo metadata can halt the pre-upgrade outright — one account hit a ModelViolationError traced to the PostgreSQL PGDG repo in /etc/yum.repos.d/. Disable questionable repos before you start. (ApisCP)

The 8 → 9 hop then adds two you won't have seen on 7 → 8: "Current x86-64 microarchitecture is unsupported in RHEL9" (fix the VM's CPU type — set it to host or a v2-capable model on the hypervisor) and "Detected RPMs with RSA/SHA1 signature" (old third-party packages signed with SHA-1). (Vander Host)

Work through the report, fix each inhibitor, and re-run leapp preupgrade until it comes back clean. Then:

sudo leapp upgrade
sudo reboot   # boots into the upgrade initramfs, applies the transaction, reboots again

Budget the time: the Leapp upgrade proper runs roughly 5–10 minutes plus three ~5-minute reboots (into the upgrade initramfs, into the SELinux relabel, into the real OS), and one CentOS 7 hosting-panel account put the whole exercise near an hour with pre- and post-upgrade cleanup included.

After 7 → 8 succeeds and the system is healthy, repeat the ELevate process for 8 → 9. Do not stack the hops without verifying the box in between.

The rollback plan (test it before you need it)

There is no reliable script that un-migrates a converted system. Your rollback is the snapshot you took in the pre-flight step:

1. Before starting, take a full VM snapshot or block-level image of the boot and data volumes.
2. Run the migration on that machine.
3. If it fails or the box misbehaves, restore the snapshot — you are back exactly where you started.

On a hypervisor this is a right-click and a few minutes; on bare metal it means a pre-migration image you can re-deploy. The point is the same: never run these conversions without a tested restore path. Both AlmaLinux's migration guide and CIQ are explicit that there is no built-in "undo" — the snapshot is the rollback — and the forums have the cautionary tales to match, including an operator left "pretty much bricked" mid-ELevate with only a fresh reinstall to fall back on. The "fix forward" option in a failed cross-major upgrade can be a long night.

What breaks (the honesty section)

The conversions themselves are reliable; the breakage is almost always in the things bolted onto the base system. These are real, documented failure points pulled from the tools' issue trackers and forums:

• A stale third-party kernel module breaks the pre-flight. One migrate2rocky run aborted with a broken RPM database because an old el7 kmod-kvdo module conflicted with itself — ending in "Error: Check discovered 95 problem(s)". Clean up out-of-tree modules and repair the RPM DB before converting.
• cPanel/panel dependency conflicts during distro-sync. Converting a cPanel box to AlmaLinux hit libstdc++-devel-...el8.alma versus stock-library conflicts that failed the dnf distro-sync; the workaround was re-running it with --allowerasing/--skip-broken. Worse, a Leapp 8 → 9 upgrade on a cPanel host wiped all WHM/cPanel packages on reboot — check your panel's supported-OS matrix for the target first.
• EFI/GRUB drops to a grub prompt after conversion. A UEFI box landed at a bare grub prompt after migrate2rocky; the fix was grub2-mkconfig --output=/boot/efi/EFI/rocky/grub.cfg, and Secure Boot must be disabled before you begin.
• A stray Stream-only repo lingers. After migrating to AlmaLinux, a CentOS-Stream-only epel-next-release package survived and caused conflicts until removed with dnf remove epel-next-release.
• Config drift after a major upgrade. Leapp brings configuration forward but not perfectly. Expect to reconcile sshd_config, firewalld, and SELinux — which drops to permissive during the upgrade, so set it back to enforcing — plus any service whose defaults changed between majors.

Post-migration validation

Whatever path you took, verify before you call it done:

# Confirm the OS identity
cat /etc/os-release

# Any packages still from the old distro? (should be empty/none)
rpm -qa | grep -Ei 'centos' 

# Reconcile everything against the new repos
sudo dnf distro-sync -y

# Repos point where you expect
dnf repolist

# Core services are up
systemctl --failed

dnf distro-sync is the important one: it aligns every installed package with the target distribution's version, cleaning up anything the conversion left straddling two releases. If you migrated a RHEL box (rather than CentOS) into a rebuild, also run subscription-manager unregister / remove and uninstall subscription-manager so the system stops trying to talk to Red Hat. Finish by rebooting once more and confirming services, then re-enable any third-party repos you disabled in pre-flight.

Frequently asked questions

Is CentOS Stream safe for production?

It is stable enough to run, but it is a rolling distribution positioned upstream of RHEL, with no fixed point releases to pin to. For most production fleets that want a predictable, patched, point-release target, AlmaLinux or Rocky is the better fit. Stream shines for previewing RHEL and for CI/development against what RHEL will become.

Can I migrate CentOS 7 directly to AlmaLinux 9 or 10?

No. Leapp/ELevate does one major version per run, so the path is CentOS 7 → 8, then 8 → 9, then 9 → 10 — each a separate, verified hop. There is no supported single jump from 7 to a version-9 or version-10 distribution. On many CentOS 7 fleets, deploying a fresh version-9/10 box and migrating data across is less work than three chained in-place upgrades.

Is AlmaLinux still 1:1 with RHEL?

No, and that is deliberate. Since 2023 AlmaLinux targets ABI compatibility — applications built for RHEL run unmodified on AlmaLinux — rather than byte-for-byte identical packages. Rocky Linux is the one still pursuing strict 1:1 binary parity. For running third-party software the ABI guarantee is what matters, and it holds.

AlmaLinux vs Rocky Linux — is one faster?

No. Both are rebuilt from the same upstream sources with the same kernel, so there is no reproducible performance difference. Phoronix's EL10 benchmarks put AlmaLinux, Rocky, and RHEL essentially on-par across dozens of tests. Pick on compatibility model, ecosystem, patch cadence, and FIPS — not throughput.

Does cPanel still support Rocky Linux?

Not on current versions. cPanel & WHM dropped Rocky Linux support in version 134; the supported list is AlmaLinux, CloudLinux, and Ubuntu 24.04. If you run cPanel, AlmaLinux is the migration target. (Confirm against cPanel's current release notes, as this changed recently.)

Skip the migration: deploy fresh on Serverside

The cleanest CentOS exit is often not an in-place conversion at all — it is a fresh box on the successor you chose, with your data and config brought across. Every Serverside dedicated server images AlmaLinux and Rocky Linux (and RHEL, bring-your-own-subscription) onto bare metal in under a minute, so you can stand up the target, validate your stack, and cut over on your own schedule instead of gambling a production host on a one-way upgrade.

The hardware is identical whichever you pick, and always-on DDoS mitigation on our ASN 55285 network sits in front of the box regardless of distribution. If you are still weighing the RHEL family against Ubuntu or Debian, start with our Linux distribution guide; when you have decided, our CentOS-successor dedicated servers deploy AlmaLinux or Rocky preinstalled, and our RHEL dedicated servers take your own entitlement.