CentOS vs RHEL vs Rocky Linux: Enterprise Migration Guide (2026)

CentOS Linux is dead. Not “in maintenance mode.” Not “winding down.” Dead. CentOS Linux 7 stopped getting security updates on June 30, 2024. CentOS Linux 8 was retired even earlier, at the end of 2021. If you’re still running either in production, you’re serving traffic on an OS with no official patches for known CVEs — barring paid third-party Extended Lifecycle Support (ELS) from vendors like TuxCare or OpenLogic, which some shops use as a stopgap. CentOS Stream, the project’s replacement, is a rolling “midstream” distribution that tracks ahead of the next RHEL point release. That’s a preview of what’s coming, not the stability most production servers need.

That leaves three real destinations: pay Red Hat for a RHEL subscription, move to Rocky Linux (a free, community-governed 1:1 rebuild of RHEL), or go with AlmaLinux (a similar free rebuild with different governance). This guide compares all three on cost, support, and binary compatibility. Then it walks through the real migration commands: convert2rhel, migrate2rocky/migrate2rocky9, and ELevate/Leapp. It also covers the post-migration checks that catch what quietly breaks during an in-place conversion. Short version: for most homelabs, startups, and cost-sensitive production shops, Rocky Linux is the right call. It’s free, ABI-compatible with RHEL, backed by a nonprofit, and has mature migration tooling. Pick RHEL if you need Red Hat’s support SLA, hardware or software certifications (VMware, SAP, Oracle DB), or a paid contract for compliance reasons. AlmaLinux is a solid alternative with nearly identical trade-offs. Pick it if you prefer its governance model or you’re already using ELevate.

Overview

Before comparing tooling, it helps to see where each option lands. All three below are RHEL binary-compatible at the package and ABI level. Version-specific caveats come later. Oracle Linux and the SUSE family are in the table for context only. They’re not the focus of this guide.

What We’re Comparing

Feature Comparison

At a Glance

Governance and Support Model

RHEL: Red Hat controls the roadmap. Every subscription tier includes access to Red Hat’s knowledge base and official patches on release day. Standard and Premium tiers also add a support ticket queue with SLA-backed response times. This matters most when you need someone to call. Think: a failed cluster at 2 a.m., an auditor asking who’s accountable for patching, or a vendor like SAP or VMware that only certifies against RHEL by name.

Rocky Linux: The Rocky Enterprise Software Foundation (RESF) governs Rocky Linux. It’s a member-funded nonprofit backed by AWS, Google Cloud, Microsoft Azure, and CIQ. There’s no first-party paid support queue from the core project, but several MSPs and CIQ itself sell commercial support on top of Rocky. Governance is public: RESF board meetings and decisions are documented. That matters if your procurement team wants proof the project won’t fold overnight the way CentOS did.

AlmaLinux: The AlmaLinux OS Foundation governs the project. It spun out from CloudLinux and runs with an independent board. The model is similar to Rocky’s: free, community-driven, ABI-compatible. One tool stands out: ELevate, which AlmaLinux maintains and Rocky also documents as a supported migration path.

Winner: RHEL for organizations that need a contractual support relationship. Rocky Linux for everyone else. The RESF’s multi-vendor backing gives it more durability than CentOS ever had as a Red Hat-owned project.

Cost and Licensing

RHEL pricing is per-socket-pair, per-year, and scales with support level. Rocky Linux and AlmaLinux are free no matter how many sockets or VMs you run. No license server, no subscription-manager registration step, no per-node counting.

Red Hat does offer a free developer subscription for up to 16 systems (self-support only, no SLA). It’s a genuine option for homelabs that want real RHEL without paying. It stops making sense once you’re past that node count, or once your team needs real support tickets.

Winner: Rocky Linux / AlmaLinux (tie). Nothing beats free. And the ABI compatibility means you’re not trading away package compatibility to get there.

Binary Compatibility (ABI)

This is the detail that decides whether third-party RPMs install cleanly: Docker CE, cPanel, EPEL packages, vendor agents. Both Rocky Linux and AlmaLinux rebuild directly from RHEL’s public source RPMs, targeting the same ABI version for version. A .rpm built and tested against RHEL 9 installs and runs the same way on Rocky Linux 9 or AlmaLinux 9. Most packages need no recompilation.

One thing to watch: kernel module packages built against RHEL’s exact kernel build number can lag on rebuild distros by a day or two after a RHEL point release. That’s because Rocky and AlmaLinux have to wait for Red Hat to publish source before rebuilding. For most shops that’s a non-issue. For kernel-module-heavy environments, like custom NIC drivers or some storage HBAs, check the rebuild distro’s changelog before patching on release day.

Winner: Tie (Rocky Linux and AlmaLinux). Both are functionally indistinguishable from RHEL at the package level, which is the entire point of a 1:1 rebuild.

Migration Tooling

This is where the three paths diverge the most. Picking the wrong tool for your source OS is the single most common migration mistake.

Winner: Rocky Linux. migrate2rocky and migrate2rocky9 are purpose-built and actively maintained. Both are documented in the public GitHub repo, with clear guidance for EL8 and EL9 source systems.

Pricing Comparison

Prices are Red Hat’s publicly listed 2026 reference pricing and vary by reseller, cloud marketplace, or enterprise agreement. Check Red Hat’s pricing page before you build a budget around these numbers.

If you’re weighing whether to pay: Rocky Linux is good enough for most workloads that don’t need a support contract on paper. RHEL earns its subscription cost through vendor certification. Think SAP HANA, Oracle RAC, VMware compatibility matrices. It also gets you the ability to open a ticket with Red Hat and get a guaranteed response time. No free rebuild offers that natively. It’s the one thing you can’t route around with good sysadmin habits.

Pre-Migration Checklist

Run through this before touching any conversion tool. In-place migrations modify a live system’s package database, bootloader, and kernel. There’s no clean rollback if something goes sideways mid-conversion.

• Take a full backup or snapshot. If the server is a VM, snapshot it. If it’s bare metal, back up /etc, /var, application data, and take an image if your backup tooling supports it.
• Schedule a maintenance window. Both convert2rhel and migrate2rocky require a reboot mid-process. ELevate/Leapp requires at least two reboots: once into an upgrade initramfs, then again into the new OS.
• Inventory third-party repositories. Run dnf repolist and note anything outside the base OS repos: Docker CE, EPEL, cPanel, vendor agent repos. Some will need re-pointing after migration.
• Inventory custom kernel modules. Check lsmod and /etc/modules-load.d/ for anything not shipped by the stock kernel (custom NIC/HBA drivers, DKMS packages, VPN clients like some older OpenVPN/WireGuard kernel builds).
• Check for CentOS 8.0-era dead mirrors. If you’re on an old CentOS 8.x point release, mirrorlist= entries in /etc/yum.repos.d/CentOS-*.repo are almost certainly dead. Point baseurl= at CentOS Vault mirrors before any migration tool can even update the package cache.
• Confirm free disk space. ELevate and convert2rhel both download and stage a large number of packages: 5-10 GB of free space on / and /boot is a safe minimum.
• Document current package drift. Run rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH} %{VENDOR}\n' | grep -v "CentOS" to list packages not from the stock CentOS repos. These are the ones most likely to break.

Step-by-Step Migration Paths

Path 1: CentOS 8 / CentOS Stream 8 to Rocky Linux 8 with migrate2rocky

This is the most common path for shops still on an EL8 base.

# Confirm current OS and free disk space first
cat /etc/os-release
df -h /

# Download the official migrate2rocky script from the Rocky Linux repo
sudo curl -o migrate2rocky.sh -x "" https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
sudo chmod +x migrate2rocky.sh

Review the script before running it. It’s a small, readable bash file that swaps repo configuration and reinstalls every package from Rocky’s repos to match. Then run it:

# -r performs the actual migration (without -r it runs in dry-run/verify mode)
sudo bash migrate2rocky.sh -r

Expected behavior: the script backs up your existing .repo files, installs Rocky Linux’s GPG keys, and adds Rocky’s repo definitions. Then it reinstalls every RPM currently on the system against Rocky’s package set. This takes 10 to 40 minutes depending on package count and network speed. Do not interrupt this process. It modifies the RPM database live.

Warning: Run migrate2rocky.sh only against a snapshot or backed-up system. It reinstalls the majority of your installed packages in place, and an interrupted run (power loss, SSH drop) can leave the RPM database in an inconsistent state.

Reboot when it finishes:

sudo reboot

Path 2: CentOS Stream 9 to Rocky Linux 9 with migrate2rocky9

The EL9 script is a separate download with the same mechanics:

sudo curl -o migrate2rocky9.sh -x "" https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky9.sh
sudo chmod +x migrate2rocky9.sh
sudo bash migrate2rocky9.sh -r
sudo reboot

The README in the GitHub repo lists the exact supported source OS versions for each script release. Check it before running, since supported source versions get added over time.

Path 3: CentOS 7 to Rocky Linux 9 with ELevate, then migrate2rocky9

migrate2rocky does not support CentOS 7 as a source. You have to jump the major version first with ELevate, which is built on Red Hat’s Leapp framework. Then optionally convert to Rocky if ELevate lands you on a generic EL base.

# Install the ELevate release package and the Leapp utility
sudo yum install -y https://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-almalinux

# Run the pre-upgrade check — this does NOT modify the system
sudo leapp preupgrade

Expected output ends with a report path:

============================================================
REPORT OVERVIEW
============================================================

Risk Factor Reports
————————————-
high 1
medium 2
low 5

Report saved to /var/log/leapp/leapp-report.txt
============================================================

Read that report carefully. It flags third-party repos, unsupported packages, and kernel modules that will block the upgrade. Fix everything marked as an inhibitor before proceeding:

sudo leapp upgrade
sudo reboot

The system reboots into a special upgrade initramfs. It performs the actual EL7-to-EL9 jump, then reboots again into the new OS. Once you’re back up on an EL9 base, run migrate2rocky9.sh -r as shown in Path 2. That lands you on Rocky Linux branding and repos instead of a generic EL9 system.

Path 4: CentOS 8 to RHEL 8 with convert2rhel

If you’re going the paid route instead:

# Register the system with Red Hat first (requires a valid subscription)
sudo subscription-manager register --auto-attach

# Install convert2rhel from Red Hat's repo
sudo yum install -y convert2rhel

# Dry-run analysis (no changes made)
sudo convert2rhel analyze

# Perform the actual conversion
sudo convert2rhel convert

convert2rhel walks through pre-checks, replaces repo configuration, and reinstalls RPMs against RHEL’s repos. It’s mechanically similar to migrate2rocky. But it requires an active subscription and Red Hat account credentials during the process.

Post-Migration Verification

Don’t call the migration done until you’ve confirmed all five of these. It’s tempting to reboot, see a login prompt, and walk away. That’s exactly how a broken SELinux config or a dead time sync goes unnoticed for a week.

1. Repository configuration

cat /etc/os-release

Expected output should clearly show the new distribution name and version, for example:

NAME=”Rocky Linux”
VERSION=”9.4 (Blue Onyx)”
ID=”rocky”
ID_LIKE=”rhel centos fedora”

dnf repolist

Confirm every repo listed points to the new distribution’s mirrors, not leftover CentOS URLs.

2. Kernel version

uname -r

Compare this against rpm -q kernel --last | head -n 3. Confirm you’re booted into the newest installed kernel, not an old one left over from before the migration.

3. SELinux status

sestatus

Expected output:

SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: enforcing
Mode from config file: enforcing

If Current mode shows permissive or disabled and you expected enforcing, something in the migration reset /etc/selinux/config. Fix it, then reboot before moving on.

4. Running services

sudo systemctl --failed

Expected output on a healthy system:

0 loaded units listed.

If services show up here, check them individually:

sudo journalctl -u SERVICE_NAME --since "1 hour ago"

5. NTP/time sync

Time drift breaks Kerberos/Active Directory auth, TLS certificate validation, and clustered services almost immediately. Check this explicitly rather than assuming it survived the migration.

chronyc tracking

Expected output:

Reference ID : C0A80101 (192.168.1.1)
Stratum : 3
Ref time (UTC) : Sun Aug 16 06:05:04 2026
System time : 0.000012345 seconds fast of NTP time
Last offset : +0.000009876 seconds
RMS offset : 0.000015432 seconds
Leap status : Normal

If chronyd isn’t installed or running after migration, install and enable it:

sudo dnf install -y chrony
sudo systemctl enable --now chronyd
chronyc sources -v

Common Pitfalls

Third-party repo incompatibility. Docker CE, cPanel, and vendor agent repos are often pinned to a specific major EL version in their .repo URL. After migration, dnf update will either fail outright, or silently pull nothing new from these repos. Fix it by updating the version number in the repo file.

Custom kernel modules breaking. Anything compiled against the old kernel won’t survive a kernel version jump: DKMS-built NIC drivers, some VPN clients, custom storage HBA drivers. Rebuild or reinstall these against the new kernel headers immediately after migration. Don’t wait for the next reboot to find out it’s broken.

EPEL misalignment. EPEL packages are versioned per major EL release. A leftover epel-release package pointed at EL8 on a system now running EL9 causes dependency resolution errors. Fix it with:

sudo dnf remove -y epel-release
sudo dnf install -y epel-release

Dead CentOS 8.0 mirrors blocking the whole process. If dnf update fails immediately with connection errors, before you even run a migration script, your repo files are still pointing at CentOS’s live mirrors. Those went offline after EOL. Edit /etc/yum.repos.d/CentOS-*.repo, comment out mirrorlist= lines, and set baseurl= to a CentOS Vault URL (e.g., https://dl.rockylinux.org/vault/centos/8.5.2111/) before proceeding.

Use Case Recommendations

Choose RHEL if:

• You need a support contract with a contractual SLA and someone to call at 2 a.m.
• Your software stack (SAP, Oracle Database, VMware) explicitly requires RHEL certification
• You’re in a regulated industry where “we run a paid, vendor-supported OS” is a compliance checkbox
• Budget isn’t the primary constraint and you have fewer than a few hundred nodes to license

Choose Rocky Linux if:

• You want free, RHEL-compatible infrastructure for homelabs, startups, or internal tooling
• You’re migrating a fleet where per-socket subscription costs would add up fast
• You value transparent, multi-vendor-backed governance (RESF) over a single corporate owner
• You need mature, well-documented in-place conversion tooling from CentOS

Choose AlmaLinux if:

• You prefer AlmaLinux’s foundation governance model over RESF
• You’re already using ELevate as your primary migration tool and want native alignment
• You want a second free option to diversify away from single-rebuild risk across your fleet

Final Verdict

On cost and compatibility alone, Rocky Linux wins for most readers of this site: homelabbers, startups, and IT teams running infrastructure without a Red Hat support contract. RHEL earns its price tag when you need the support SLA or vendor certifications it provides. AlmaLinux is a legitimate free alternative if you’d rather diversify away from a single rebuild project, or you’re already using ELevate.

Overall Winner: Rocky Linux

Most readers face the same scenario: a CentOS 7/8 or CentOS Stream server that needs to move somewhere supported, without a new line item in the budget. Rocky Linux offers the best mix of zero cost, full ABI compatibility, transparent governance, and mature official migration tooling.

Score Summary

Frequently Asked Questions

Is CentOS still safe to run in 2026?

No, if you mean CentOS Linux 7 or 8. Both are fully end of life. CentOS 7 stopped receiving security patches on June 30, 2024. CentOS 8 was retired at the end of 2021. Any unpatched CVE affecting the kernel, OpenSSL, or a network-facing service is a standing risk on those systems. CentOS Stream is still maintained. But it’s a rolling release, not a stable production target for most workloads.

What’s the difference between CentOS Linux and CentOS Stream?

CentOS Linux was a downstream rebuild of RHEL. It trailed RHEL releases and matched RHEL’s stability and package versions exactly. CentOS Stream sits upstream of RHEL instead. It’s a rolling distribution that previews changes headed into the next RHEL minor release. That makes it useful for testing and RHEL development. But packages update more frequently and less predictably than a production server typically wants.

Can I migrate CentOS 7 directly to Rocky Linux 9?

Not in a single step. migrate2rocky and migrate2rocky9 don’t support CentOS 7 as a source OS. You need ELevate (Leapp) first to jump CentOS 7 to an EL8 or EL9 base. Resolve any inhibitors the pre-upgrade report flags. Then optionally run migrate2rocky9 to convert that EL9 base to Rocky Linux branding and repos.

Do I need to pay for RHEL, or is Rocky Linux “good enough”?

For most homelabs and small-to-midsize production environments, Rocky Linux is genuinely good enough: ABI-compatible with RHEL and free. Pay for RHEL when you need Red Hat’s contractual support SLA. Or when a vendor like SAP, Oracle, or VMware requires RHEL certification by name for support eligibility.

What does migrate2rocky actually do, and is it safe on a production server?

It backs up your existing repo configuration and installs Rocky Linux’s GPG keys and repos. Then it reinstalls most of your currently-installed packages against Rocky’s package set, in place. It’s safe when you follow the pre-migration checklist first: backup, resolve third-party repo issues, schedule a maintenance window. It does modify the live RPM database and requires a reboot. Treat it with the same caution as any major in-place OS change.

How do I check that NTP/time sync is still working correctly after migration?

Run chronyc tracking and confirm Leap status shows Normal. The System time offset should be small, well under a second. If chronyd isn’t running, install it with sudo dnf install -y chrony and enable it with sudo systemctl enable --now chronyd. This matters most for Kerberos/Active Directory authentication, TLS certificate validation, and clustered services. All three fail in confusing ways when clocks drift.

What breaks most often during an in-place Linux distro migration?

Ranked by frequency: third-party repos pointed at the old major version (Docker CE, cPanel, vendor agents); custom kernel modules that don’t survive a kernel version jump; and EPEL configuration left pointing at the old EL release. All three show up as dnf or package errors, or as failed services after the reboot. Check systemctl --failed and dnf repolist first when something doesn’t come back up cleanly.

Wrapping Up

If you’re still running CentOS in production, the free path is Rocky Linux. The tooling is solid enough to trust on a real server, as long as you back up first and follow the checklist above. RHEL is the right call when you genuinely need the support contract, not out of habit left over from the “CentOS was the free RHEL clone” era.

Once you’re confirmed on Rocky Linux or RHEL, go back and check EPEL repo alignment and SELinux enforcement settings specifically. Those two deserve a dedicated pass beyond the quick checks above.