Seamless Migration: Transitioning CentOS 8 to AlmaLinux

CentOS 8 reached end of life on 2021-12-31, ending regular updates and security fixes. For production estates, running EOL distributions is unwise—unpatched vulnerabilities and outdated toolchains create an operational hazard. Most RHEL-compatible workloads now target AlmaLinux, which delivers binary compatibility with Red Hat Enterprise Linux 8.x without a subscription lock-in.

Pre-Migration: Sanity Checklist

Critically, do not touch core infrastructure without:

• Full offline backup of /etc, /var/lib, all databases, and application state. Snapshots (e.g., LVM, Ceph, or even hypervisor-based) are preferable.
• Detached SSH session or direct console access (do not rely solely on a single remote shell).
• All CentOS 8 updates applied:

  sudo dnf clean all
  sudo dnf update -y
  sudo reboot   # This really matters if kernel or systemd updated
  

• EPEL and 3rd-party repos disabled, or at least documented. Repo mismatch causes post-migration package drift.

Known edge case: iSCSI-mounts and legacy network interface names sometimes break after OS conversion due to changes in udev rules.

Migration Approach: Leapp & ELevate

Forget manual package swapping. The recommended workflow is to use AlmaLinux’s ELevate tooling—built on top of Red Hat’s leapp utility—to automate low-level OS realignment.

1. Install ELevate and Migration Data

sudo dnf install -y https://repo.almalinux.org/elevate/elevate-release-latest.el8.noarch.rpm
sudo dnf install -y leapp-upgrade leapp-data-almalinux

Tip: If you see Error: Unable to find a match, ensure you’re running a fresh dnf update and that DNS isn’t misconfigured.

2. Run Pre-Migration Scan

sudo leapp preupgrade

Inspect /var/log/leapp/leapp-preupgrade.log for blocked migrations—common issues include custom kernel modules, 3rd-party vendor packages, or missing migration data.

Sample log output for blocked run:

INHIBITOR: Detected elrepo kernel: kernel-ml-5.15.35-1.el8.elrepo.x86_64.
INHIBITOR: Third-party repository remi-safe is enabled.

Upgrade will not proceed while inhibitors are present.

3. Address Blocking Issues

Remove or temporarily disable unsupported packages and repos:

sudo dnf remove kernel-ml
sudo dnf config-manager --set-disabled remi-safe

(Alternatively, edit /etc/yum.repos.d/*.repo directly.)

4. Execute Migration

Assuming preupgrade passes without inhibitors:

sudo leapp upgrade --target almalinux8

This downloads and stages AlmaLinux packages. A leapp-generated GRUB entry is created for the next boot.

5. Reboot & Complete OS Switch

sudo reboot

System now boots under the AlmaLinux branding. In rescue scenarios (boot fails), select the previous kernel via GRUB menu.

Post-Migration Validation

Check core OS identity:

cat /etc/os-release
rpm -q almalinux-release
uname -r

Expected output (example):

NAME="AlmaLinux"
VERSION="8.9 (Midnight Beetle)"
...
almalinux-release-8.9-1.el8.x86_64

Verify core services:

sudo systemctl status network
sudo systemctl status sshd
sudo systemctl status <your_SERVICE>  # e.g., httpd, nginx, mariadb

Note: If services fail, check /var/log/messages and systemctl status <UNIT> for missing dependencies or SELinux context mismatches.

Repository Realignment

Leftover CentOS repos often cause update errors:

sudo dnf remove centos-linux-repos centos-gpg-keys -y
sudo dnf install almalinux-release -y
sudo dnf distro-sync -y   # Ensures package versions match Alma baseline
sudo dnf clean all && sudo dnf autoremove -y

Diff and inspect /etc/yum.repos.d/—purge any stale vendor .repo configs.

Practical Example: Web Server Migration

Consider a typical LAMP stack—after migration:

• Apache (httpd) may reference modules absent from AlmaLinux’s default repos. If /var/log/httpd/error_log shows:

  AH00534: httpd: Configuration error: No MPM loaded.
  

  then verify module paths and re-install as necessary.

• PHP versions may roll forward or backward according to available modules—pin, if needed, before migration.

• Test real traffic: curl from external hosts or probe with application monitoring.

Troubleshooting Table

More: AlmaLinux Migration Wiki

Closing Notes & Non-Obvious Detail

• Custom PAM or SELinux policies? Always pre-stage and verify after reboot. SELinux relabel with touch /.autorelabel && reboot if contexts are off.
• For clusters or HA workloads, migrate a single node first and fail over to test stateful workload recovery before full rollout.
• Sometimes leapp leaves behind stray centos-release files. These are mostly cosmetic but clean up for hygiene.

Migration between RHEL derivatives is never perfect—edge-case integrations (e.g., vendor monitoring agents, DKMS drivers) may require downstream package rebuilds. No universal script will cover every configuration.

For any environment where downtime is not an option, validate this process in a cloned staging environment with equivalent data and traffic. Migration is less about running a tool and more about understanding the operational state before and after.