RHEL is excellent, but its per-system subscription costs add up across a fleet, and Red Hat’s 2020 decision to turn CentOS into the upstream CentOS Stream removed the free, bug-for-bug RHEL rebuild that many teams quietly depended on. Rocky Linux (from the Rocky Enterprise Software Foundation) and AlmaLinux stepped in as 1:1, binary-compatible RHEL rebuilds. This is one of the lowest-risk migrations on this site, but “low risk” is not “no thought.”
What Rocky actually is
Rocky Linux is built to be bug-for-bug compatible with RHEL: same packages, same versions, same ten-year lifecycle per major release, no license fee. Software certified for RHEL runs on Rocky unchanged. AlmaLinux is an equivalent rebuild; the migration mechanics below apply to either, so pick on governance and community fit rather than technical difference.
What you give up
You are giving up the Red Hat subscription and everything attached to it: official 24×7 support and SLAs, Red Hat Insights, Satellite, and vendor certifications for some layered products. If a third-party application contractually requires “RHEL” specifically, confirm whether the vendor supports rebuilds before you convert. For teams that want a safety net, commercial support for Rocky is available (e.g., CIQ); many run it purely community-supported.
Two migration paths
In-place conversion is the headline feature. The migrate2rocky script swaps RHEL/CentOS (and other Enterprise Linux rebuilds) to Rocky in place:
curl -O https://raw.githubusercontent.com/rocky-linux/rocky-tools/main/migrate2rocky/migrate2rocky.sh
chmod +x migrate2rocky.sh
./migrate2rocky.sh -rIt replaces the distro packages and GPG keys, then you reboot into Rocky. Convenient, fast, and reversible only via your backup, so snapshot first.
Reprovisioning is the cleaner option for critical hosts: build fresh Rocky systems from a kickstart or image and redeploy configuration and apps via Ansible. It costs more up front but gives you a known-good, drift-free baseline and a trivial rollback (the old host is untouched).
How to decide between them
The deciding question is how much you trust the state of the existing host. A stateless app server that Ansible already owns end to end is a good in-place candidate: if the conversion goes wrong you rebuild it anyway. A long-lived host with years of hand-applied config, unmanaged packages, and undocumented tweaks is exactly where an in-place converter can leave you with a subtly broken system that is hard to diagnose. Those hosts are better rebuilt clean, which also forces you to capture their configuration in code for the first time. A reasonable fleet policy is: convert the cattle, reprovision the pets.
The steps that actually matter
- Back up / snapshot every host before converting.
- Test on non-production first, a representative app server, not just a bare box.
- Convert with migrate2rocky (or reprovision), then reboot.
- De-register from Red Hat:
subscription-manager unregisterand remove RHSM/Insights agents so you stop consuming entitlements. - Validate package set, enabled repos (EPEL works the same), third-party repos, Secure Boot if used, and that all services come back.
What to check before you sign off a host
Do not call a converted host done until you have checked, on the host itself:
- OS identity:
/etc/redhat-releaseand/etc/os-releasereport Rocky, and the running kernel is the standard RHEL-compatible kernel. - Repositories: the Rocky base and AppStream repos are enabled, EPEL and any third-party repos still resolve, and no orphaned RHSM repo definitions remain.
- Packages: no packages are still owned by Red Hat GPG keys, and nothing critical was removed during the swap.
- Services: every service that was running before the conversion comes back after a reboot, not just after the conversion completes.
- Agents: backup, monitoring, and security agents re-check-in, and any RHSM or Insights agents are gone.
- Boot: if you use Secure Boot, the machine boots cleanly with the Rocky shim and kernel signatures on your actual hardware.
If you need to back out
There is no in-place “undo” for the converter, so your rollback plan is the snapshot you took beforehand. For an in-place conversion, rollback means restoring the pre-conversion snapshot of that host, which is why you never batch-convert a whole rack in one window. For a reprovisioned host, rollback is even simpler: leave the old RHEL host powered on but drained, cut traffic back to it, and delete the new Rocky host. Keep both options live through hypercare rather than decommissioning the source the moment the new system answers.
Freeing the entitlements
The savings do not materialise until you actually free the entitlements. After each host is validated on Rocky, run subscription-manager unregister, remove the RHSM and Insights packages, and confirm in the Red Hat portal that the per-socket entitlement is released back to the pool. Track this per host: it is common to convert a fleet, forget the de-registration step on a subset, and keep paying for entitlements no live system is using. Only once the entitlement count drops does the modelled saving become real.
A few things that catch people out
- Do the conversion in a maintenance window, it touches core packages.
- Layered Red Hat products (some add-ons and certifications) may not be supported on a rebuild; inventory them first.
- If you used Satellite or Insights, plan a replacement (e.g., a local mirror plus Ansible) rather than discovering the gap later.
- Check for RHEL-specific subscriptions baked into automation that will now fail silently.
So, should you convert?
RHEL → Rocky Linux is a high-confidence, low-cost migration: a binary-compatible OS with a ten-year lifecycle and an in-place converter. The real decisions are operational, snapshot before converting, test on non-prod, reprovision critical hosts instead of converting them, and confirm any RHEL-only vendor support before you commit. Model the per-system subscription savings in the calculator above, and treat them as illustrative until you confirm your support strategy.