CentOS Linux is a special case among migrations because it is not a cost decision, it is an end-of-life one. CentOS Linux 8 reached end of life at the end of 2021, and CentOS Linux 7 followed in mid-2024. Neither receives security or bug fixes any more, and CentOS Stream, the rolling preview of what will become the next RHEL, is deliberately not the stable, bug-for-bug rebuild that teams standardized on. Running an unpatched, out-of-support OS is a genuine compliance, audit, and security liability, which is why “what do we replace CentOS with?” became an urgent question rather than a nice-to-have.
The two natural successors
Both Rocky Linux and AlmaLinux were created specifically to fill the gap CentOS left: free, community-governed, and 1:1 compatible with RHEL, so your existing packages, scripts, and config management keep working. This is the closest thing to a like-for-like continuation of what CentOS Linux was. Rocky aims for strict bug-for-bug RHEL compatibility; AlmaLinux targets ABI compatibility and maintains the ELevate tooling for cross-major upgrades. For a CentOS estate, either restores you to a supported, patched, RHEL-compatible baseline.
CentOS 7 vs CentOS 8: different migrations
The version you are on changes the work substantially. CentOS 8 or Stream can be converted in place: Rocky’s migrate2rocky.sh and AlmaLinux’s almalinux-deploy.sh swap the distribution under a running system after a snapshot, no reprovisioning required. CentOS 7 is harder, because there is no in-place jump across a major version. You either use AlmaLinux’s ELevate (built on Red Hat’s leapp) to move 7 to 8 and then deploy fresh on 9, or you reprovision directly onto Rocky/Alma 8 or 9 via kickstart and redeploy your workloads with Ansible. Treat CentOS 7 hosts as rebuilds and budget accordingly.
The urgency is real but the effort is low, and the destinations are stable.
Establishing what you are actually running
CentOS estates have a particular characteristic: they grew informally. Because the OS was free and required no subscription to track, there is often no authoritative list of where it runs, and the inventory is the first real piece of work.
Start by searching more broadly than your server list. CentOS turns up inside virtual appliances shipped by vendors, as the base image of containers built years ago, on build agents someone stood up for a single project, and on hardware attached to laboratory or industrial equipment. A subscription-managed estate has a billing record to reconcile against; CentOS has nothing, so the only reliable methods are network scanning and querying your configuration management and container registries directly.
Sort what you find into three buckets, because they have genuinely different answers. Systems you control and can convert are the straightforward majority. Systems inside vendor appliances are the vendor’s problem, and the action is to open a ticket asking what their supported upgrade path is, since converting someone else’s appliance usually voids your support. Systems attached to physical equipment, where the operating system version is dictated by an instrument driver, may not be movable at all, and the honest answer for those is network isolation and compensating controls rather than migration.
Container images deserve their own pass. A FROM centos:7 in a Dockerfile is a one-line change to a supported base and one of the cheapest remediations available, but only if someone goes looking for it.
The compliance argument, and how to make it
Unlike most migrations on this site, this one rarely needs a cost justification. It needs a risk one, and that argument is more effective when it is precise rather than alarming.
The substance is straightforward. An end-of-life operating system receives no security updates, which means newly disclosed vulnerabilities stay unpatched permanently. That is not a theoretical exposure: vulnerability scanners will flag the systems, and the findings cannot be remediated, only accepted. Most security frameworks and many contractual obligations require running supported software, so unsupported systems tend to produce audit findings that recur every cycle until they are fixed.
The most effective way to present this is usually a single number: how many findings on the current scan report are unfixable because the platform is end of life. That figure reframes the work from a technical preference into a compliance backlog with an owner and a date, and it tends to unlock the scheduling conversation that a general argument about good practice does not.
It also helps to be clear about the alternative. The choice is not between migrating and staying still; it is between migrating on your schedule and migrating during an incident. The second is considerably more expensive. Each path below opens to a full cost model, a phase-by-phase plan, and an in-depth guide for that specific move.