Choosing a CentOS 8 Migration Path: Stream vs. Rocky Linux vs. AlmaLinux

CentOS 8 reached end-of-life in December 2021, which means its mirrors went offline and security updates stopped. If you still run CentOS 8 workloads, the real decision is not whether to migrate but where to land: CentOS Stream, which tracks just ahead of RHEL, or a 1:1 RHEL-compatible rebuild such as Rocky Linux or AlmaLinux. The right choice depends on how much package churn your applications can tolerate.

Comparison of Migration Targets

Understanding the Trade-offs

CentOS Stream sits between Fedora and RHEL in the development pipeline. Packages land in Stream before they ship in RHEL, so you get security fixes and features earlier, but a library update can arrive ahead of what a third-party vendor certified against. If a proprietary application pins specific glibc or OpenSSL versions, that churn is a real risk. Also note that converting CentOS 8 to Stream is effectively one-way: returning to a RHEL clone afterward requires a fresh install.

Rocky Linux and AlmaLinux were created specifically to replace CentOS 8's original role. Rocky targets bit-for-bit parity with RHEL; AlmaLinux guarantees ABI compatibility, meaning applications built for RHEL run correctly even if individual package builds differ slightly. For a production server that must stay static for years, either is a safer target than Stream.

Implementation: In-place Migration to Rocky Linux

The supported approach for converting an existing CentOS 8 host is the migrate2rocky script, which swaps repository configuration and synchronizes packages to Rocky Linux 8. Run all commands as root (or via sudo) on the host being migrated. Take a full backup or VM snapshot first.

Step 1: Repoint repositories to the vault

Because CentOS 8 mirrors are offline, DNF will fail until repo files point at the archived vault:

sed -i 's/^mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sed -i 's|^#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
dnf clean all

Step 2: Run the migration script

curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
bash migrate2rocky.sh -r

The -r flag performs the actual conversion. The script replaces CentOS repo definitions, reinstalls packages from Rocky mirrors, and updates the branding packages. Expect a large download and a required reboot afterward.

Step 3: Validate the result

cat /etc/os-release
dnf repolist
rpm -Va | head -20

Check that /etc/os-release reports Rocky Linux, that dnf repolist shows the Rocky BaseOS and AppStream repositories enabled, and that rpm -Va (which verifies installed files against the RPM database) shows only expected configuration-file changes rather than missing or corrupted binaries. Reboot and confirm your application services start cleanly.

Limitations and Risks

• Migration scripts can fail on hosts with custom kernel modules, third-party drivers, or packages from non-standard repositories. Remove or isolate those before migrating.
• In-place conversion keeps existing configuration drift. For critical systems, a fresh install on the target OS with configuration redeployed via automation is cleaner and easier to audit.
• Repository URLs and script locations change over time; verify the current migration documentation for your chosen distribution before running anything.
• Test the full path in a staging environment or container built from the target OS image before touching production.

The practical check that matters most: after migration, run your application's own health checks and confirm dnf check-update returns security metadata from the new repositories. If patches flow and services pass their checks, the migration did its job.