Migrating from CentOS 7 / 8 to Rocky Linux 9 (or AlmaLinux 9): A Practical 2026 Playbook

Practical playbook CentOS migration · 16 min read · Updated May 2026

Two and a half years after CentOS 7 reached end of life (June 30, 2024) and over four years after CentOS 8 was abruptly cut short (December 31, 2021), many organisations still run unsupported CentOS hosts in production. The reasons are familiar: business systems built around the OS, expensive vendor recertification, conservative change windows, the comforting illusion that “it still works”. The reality is that the security patches stopped, the package archives are decommissioned, and a single unpatched glibc CVE can turn the host into a liability overnight. This playbook walks through the migration to Rocky Linux 9 (or AlmaLinux 9 — pick one; they are functionally interchangeable) using both the in-place ELevate path and the safer fresh-install path. We cover the pre-flight inventory you cannot skip, the gotchas between CentOS 7 / 8 and RHEL 9, and the post-migration validation that catches the silent failures.

Why still migrate in 2026

The numbers are unforgiving. CentOS 7’s last security update shipped in late June 2024. Every CVE landed since then is unfixed on the host you did not touch. The mirrors that still respond do so on community goodwill; the official Red Hat archive disappeared from the canonical URLs months ago. For workloads that handle payments, personal data, or anything subject to SOC2, ISO 27001 or PCI-DSS, running an EOL OS is a documented finding on every audit. Insurers have started carving out cyber coverage when the underlying OS is past EOL. The “if it ain’t broke” argument runs out at the audit table.

For CentOS 8 the story is worse because the cut-off was abrupt and the upgrade path to Stream changed the contract. Stream is rolling upstream of RHEL, not the stable downstream we used to call “CentOS”. Most organisations that ran CentOS 8 in production for stable use cases need to migrate to Rocky / Alma / RHEL, not stay on Stream.

Choosing the target: Rocky vs Alma vs RHEL

Three choices for a stable RHEL 9 equivalent in 2026.

Rocky and Alma are binary-compatible with each other and with RHEL. A package built for RHEL 9 installs cleanly on Rocky 9 and Alma 9 without rebuild. From an operational point of view the choice is governance: Rocky is community-foundation governed, Alma is CloudLinux foundation governed. Both have been stable since 2022. For most migrations, pick the one whose community fits your culture; technical capability is identical.

Two paths: in-place ELevate vs fresh install

You have two realistic migration strategies.

In-place ELevate

The AlmaLinux team maintains ELevate (github.com/AlmaLinux/leapp-data), a port of Red Hat’s Leapp tool that performs an in-place migration of an existing CentOS 7/8 host directly to Rocky 9, Alma 9, RHEL 9, or other RHEL-family targets. It analyses the system, flags blocking issues, then performs the upgrade in three reboots. ELevate works well for clean, vanilla installs. It works poorly for hosts with heavy third-party packages, custom kernels, or extensive manual configuration drift.

Fresh install + restore

Provision a new Rocky 9 / Alma 9 host, install applications from scratch (ideally via your configuration management), restore data from backup. Slower per-host but much more predictable, and forces you to actually have documented configuration management — which is the right state to be in.

The honest rule of thumb: use ELevate for hosts you have documented and tested, fresh-install for hosts that grew organically. Most production CentOS estates have a mix; the audit step below tells you which is which.

Pre-flight inventory and backup

rpm -qa --qf "%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n" | sort > /tmp/packages.txt
yum repolist                                # CentOS 7
dnf repolist                                # CentOS 8
yum list installed | grep -v "@base\|@updates" > /tmp/third-party.txt

sudo rpm -Va --nofiles --nomd5 --noscripts 2>/dev/null | sort > /tmp/drift.txt
sudo find /etc -type f -newer /tmp/install-marker 2>/dev/null > /tmp/changed-config.txt

sudo tar -czf /backup/etc-pre-migration.tar.gz /etc /var/spool/cron /root /home
sudo mysqldump --all-databases | gzip > /backup/mysql-$(date +%F).sql.gz
sudo -u postgres pg_dumpall | gzip > /backup/pg-$(date +%F).sql.gz
sudo tar -czf /backup/var-www-$(date +%F).tar.gz /var/www

sudo systemctl list-units --type=service --state=running > /tmp/services-running.txt
sudo ss -tlnp > /tmp/listening-ports.txt
sudo crontab -l > /tmp/root-crontab.txt
ls /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/ /etc/cron.weekly/ /etc/cron.monthly/ > /tmp/cron-jobs.txt

The ELevate in-place migration

ELevate runs as a Python tool that walks the host through a pre-upgrade analysis, an upgrade reboot, and post-upgrade reconciliation. The procedure for CentOS 7 → Rocky 9 (or Alma 9) in 2026:

sudo yum install -y http://repo.almalinux.org/elevate/elevate-release-latest-el7.noarch.rpm
sudo yum install -y leapp-upgrade leapp-data-rocky    # for Rocky target
# Or: sudo yum install -y leapp-upgrade leapp-data-almalinux  # for Alma target

sudo leapp preupgrade

sudo leapp upgrade
sudo reboot

cat /etc/os-release          # confirm Rocky 9 / Alma 9
uname -r                     # new kernel
sudo dnf check-update        # routine package updates available?
sudo dnf upgrade -y          # apply them
sudo systemctl --failed      # any service failed to start?

The fresh-install path

Provision a new Rocky 9 or Alma 9 host, install applications, restore data, switch the DNS or floating IP. The steps:

1. Provision the new host with the same specs as the source (or larger). Apply baseline hardening — see our Ubuntu hardening checklist (the principles apply equally to RHEL family with command substitutions).
2. Install applications from configuration management (Ansible, Salt, Puppet, Chef). If you do not have configuration management, this is the moment to introduce it — at minimum a simple Ansible playbook documenting what gets installed.
3. Restore data from backup. Database first, application files second, configuration last.
4. Validate as in the next section.
5. Cut over traffic. DNS change, load balancer reweight, or floating IP move. Keep the old host running for 24 to 72 hours as a fallback.
6. Decommission the old host once stable.

Post-migration validation

Whichever path you used, validate against the documentation you generated in pre-flight.

• Every running service from /tmp/services-running.txt is still running. Cross-check with systemctl --failed.
• Every port from /tmp/listening-ports.txt is still listening. Cross-check with ss -tlnp.
• Every cron job runs at least once. Tail /var/log/cron (CentOS 7) or journalctl (Rocky 9).
• Application smoke tests pass. The same end-to-end flow you would test on a deploy.
• External monitoring confirms the host. Uptime, TLS certificate, security headers — our Cyber Audit Suite covers this in 20 seconds.
• Backup the new host. Migrations sometimes break the existing backup hooks (paths changed, permissions different); confirm the next scheduled backup actually runs.

Common breaks and fixes

network-scripts removed

RHEL 9 removed /etc/sysconfig/network-scripts/ifcfg-* as the source of truth. Network configuration lives in NetworkManager keyfiles at /etc/NetworkManager/system-connections/. Migrate via nmcli or install the compatibility shim NetworkManager-initscripts-ifcfg-rh if you need to retain the legacy files temporarily. See our network configuration article for the translation patterns.

Python 2 gone

RHEL 9 ships Python 3.9 as the default and Python 3.11 as the alternate. Python 2 is not available. Any in-house scripts still on Python 2 must port — use 2to3 as a starting point but expect manual cleanup. The official Python migration guide covers the common cases.

iptables replaced by nftables (mostly)

iptables still exists on Rocky 9 but is the nft shim. Existing rule files load and work, but performance characteristics change at scale. See our firewall comparison for the migration patterns from iptables to native nftables.

Podman replaces Docker (almost)

RHEL 9 ships Podman 4.x by default. Docker is available via the Docker repository but is no longer the default container runtime. Most docker commands work via the podman alias (alias docker=podman); compose files load via podman-compose. Differences: Podman is daemonless and rootless-friendly; networking semantics differ slightly.

SELinux stricter defaults

RHEL 9 SELinux policies are tighter than RHEL 7. Custom applications that worked on CentOS 7 may hit AVC denials on Rocky 9. Use ausearch -m AVC -ts recent to find them, then audit2allow to generate the local policy module. Do not blanket-disable SELinux to “fix” the issue; that turns the host into a juicier target.

Older glibc symbols dropped

Some C libraries from CentOS 7 may not link cleanly on Rocky 9 due to glibc symbol versioning. Recompile from source, or use the compat-glibc packages if available. Statically linked binaries continue to work.

Database major version mismatch

CentOS 7 shipped MariaDB 5.5 and PostgreSQL 9.2; Rocky 9 ships MariaDB 10.5 and PostgreSQL 13. A logical backup (mysqldump, pg_dumpall) is portable; a raw filesystem copy is not. Always migrate databases via the logical route unless you have very strong reasons.

FAQ

Related on PeopleAreGeek