Migrating from CentOS to Rocky Linux or AlmaLinux Step by Step

Millions of CentOS 7 and CentOS 8 machines are still running somewhere right now — past end of life, unpatched, and one public CVE away from an incident. The good news is that most of them do not need a reinstall. Both Rocky Linux and AlmaLinux maintain official script-based conversion tools that transform a CentOS system in place: swapping repositories, replacing distribution packages, and resyncing everything against the new build. Done carefully, the whole thing takes under an hour and preserves your data, users, and service configuration. Done carelessly, it is still risky — which is why step one is not a script.

Step 0: Back Up Before You Convert

A conversion rewrites repository definitions and replaces core packages. Treat it like a kernel upgrade you cannot undo.

sudo yum list installed > /root/pkg-inventory-$(date +%F).txt
sudo cp -a /etc /root/etc-backup-$(date +%F)
cat /etc/redhat-release
sudo reboot

Confirm the box boots cleanly before touching anything else. On a VPS, take a provider-level snapshot as well — if a conversion fails mid-flight, a restore beats a rebuild. Verify a couple of gigabytes of free disk space, and make sure every service the machine runs is written down somewhere other than your memory.

Path A: migrate2rocky for Rocky Linux

Rocky's official tool converts EL8 and EL9 systems — CentOS, CentOS Stream, AlmaLinux, and Oracle Linux — to the matching Rocky release.

curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/migrate2rocky/migrate2rocky.sh
sudo bash migrate2rocky.sh -r
sudo reboot

The script swaps in Rocky's repo definitions, removes CentOS-branded packages, installs the Rocky equivalents, and runs a full distro-sync so every package matches Rocky's build. Expect one long, verbose transaction; let it run to completion and read the summary at the end rather than assuming success from a quiet terminal. Run it inside tmux or screen — the sync is long enough that a dropped SSH session mid-conversion is a real risk, and the script does not resume from the middle.

Path B: almalinux-deploy for AlmaLinux

AlmaLinux ships its own converter, which validates the system before modifying anything and aborts early if the machine is in a state it cannot fix.

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

The tool covers the EL8 and EL9 families as sources — CentOS, CentOS Stream, Rocky, and Oracle Linux. It validates disk space, boot configuration, and installed packages before touching anything, and prints a detailed log you can attach to a change ticket. CentOS 7 is a special case: use the ELevate project first to jump to EL8, then convert to your chosen rebuild. Check each project's supported-source table before you start; the tools are updated as new minor releases land, and yesterday's blog post may already be stale.

Verify the Conversion

After the reboot, prove the identity change and that package integrity survived:

cat /etc/os-release
sudo dnf distro-sync -y
rpm -qa --qf '%{VENDOR}
' | sort | uniq -c
sudo systemctl --failed

You want os-release naming the new distribution, a vendor histogram dominated by exactly one distribution vendor (plus Fedora Project entries for EPEL packages), and an empty failed-unit list. Leftover CentOS-branded packages usually mean the script did not finish — rerun it rather than hand-pruning the remnants.

What a Conversion Does Not Cover

The scripts swap the distribution, not your operational debt. Out-of-tree kernel modules and DKMS builds may need recompiling against the new kernel. Custom repo files pointing at dead mirrors will keep failing until you update them. Application data, databases, and hand-edited configs come along untouched — which is the point — but a conversion is not a version upgrade either: CentOS 7 to EL9 is two staged hops, each with its own testing burden and its own rollback plan.

Takeaway: snapshot, script, distro-sync, verify — in that order, every time, and never on the only copy of a production machine. Practice the whole flow on a disposable instance first: Netbay VPS instances deploy in under 60 seconds, so the rehearsal costs minutes, not a weekend — netbayhosts.in.