CentOS 7 reached end of life on June 30, 2024. That date passed quietly for many teams — no immediate disasters, no servers catching fire — and so a non-trivial number of small engineering operations are still running CentOS 7 today, telling themselves they’ll deal with it soon. “Soon” is now. Running an unpatched RHEL-derivative in 2026 is not a calculated risk; it is operational debt accumulating interest at a rate you’ll eventually have to pay in the worst possible circumstances. This CentOS migration guide for small teams is about making the migration concrete: the actual options, the honest trade-offs, the technical steps, and the specific gotchas that turn a routine migration into a weekend incident.
What Actually Happened to CentOS
The history matters because it explains why the options look the way they do now, and because a lot of teams made decisions based on a misread of the situation. The short version: Red Hat killed what CentOS was.
CentOS was a free, community-maintained rebuild of Red Hat Enterprise Linux (RHEL). For a decade, it was the default answer for teams that wanted enterprise Linux stability without paying RHEL’s licensing costs, which start around $350 per year per server for the Standard subscription. In December 2020, Red Hat announced that CentOS would become CentOS Stream — a rolling-release distribution that sits upstream of RHEL rather than downstream. CentOS Stream gets new packages before they land in RHEL, not after. It is development territory. It is not what teams running production databases wanted.
The consequences were immediate. CentOS 8, which should have been supported until 2029, was cut off at the end of 2021 — eight years early. CentOS 7 kept its original June 2024 end-of-life date. CentOS 9 Stream exists, but it is not a CentOS replacement in any meaningful sense; it is a perpetual pre-RHEL testbed, and Red Hat is transparent about this. Using CentOS Stream in production is a legitimate choice, but it is a fundamentally different choice than the old CentOS. You are opting into a rolling release with faster changes and no long-term stability guarantee.
The community response was predictable and fast. Within months of the announcement, two forks launched: Rocky Linux (led by Gregory Kurtzer, one of CentOS’s original founders) and AlmaLinux (backed by CloudLinux). Both promised to be what CentOS used to be: bug-for-bug compatible RHEL rebuilds, free forever, community-governed. Both have largely delivered on that promise. The question of which one to use is now genuinely difficult to answer on technical grounds alone.
The Real Options in 2026
If you are migrating off CentOS 7 or CentOS 8 in 2026, your realistic options fall into two categories: stay in the RHEL ecosystem, or leave it. Each has legitimate justifications. What is not justified is staying on CentOS 7 without a patch source.
Staying in the RHEL Ecosystem
AlmaLinux 9 is the RHEL 9 rebuild maintained by the AlmaLinux OS Foundation, a nonprofit. CloudLinux Inc. provides funding and resources. AlmaLinux introduced a subtle but important distinction in 2023: rather than claiming binary compatibility with RHEL, they now target ABI compatibility. In practice this means the vast majority of RHEL-certified software works fine, but AlmaLinux is no longer a strict one-to-one rebuild in the way it originally was. For most workloads this distinction is invisible. AlmaLinux 9 supports x86_64, aarch64, ppc64le, and s390x, which matters if you have a mixed hardware fleet. Support runs through May 2032 for AlmaLinux 9.
Rocky Linux 9 is the RHEL 9 rebuild maintained by the Rocky Enterprise Software Foundation (RESF), a public benefit corporation. Rocky explicitly targets binary-level compatibility with RHEL, meaning its RPMs are built from the same source code Red Hat releases. Rocky is what Gregory Kurtzer built to be the direct successor to what CentOS promised. It supports the same architectures as AlmaLinux and has the same end-of-life target. Rocky 9 support runs through May 2032.
RHEL itself is worth mentioning because Red Hat’s free developer subscription now allows up to 16 production servers at no cost. For small teams, this is legitimately worth considering: you get full RHEL, official support is available if you need it, and you sidestep the “is this truly compatible” question. The catch is that the free tier does not include phone support, and the licensing model can become complex as your fleet grows beyond 16 servers.
Leaving the RHEL Ecosystem
Ubuntu Server LTS is the most common destination for teams leaving RHEL. Ubuntu 24.04 LTS (Noble Numbat) has standard support through April 2029 and extended security maintenance through April 2034 with Ubuntu Pro, which is free for up to five machines. The package ecosystem is enormous, documentation is pervasive, and the server tooling for automation (cloud-init, netplan, systemd) is mature. The trade-off is that Canonical’s decisions do not always align with what enterprise administrators want — snap packages have been a persistent irritant on server installations, and some package versions differ enough from RHEL to require workflow changes.
Debian 12 (Bookworm) is the correct choice if you value stability, predictability, and organizational independence above all else. Debian is run by a volunteer community with no corporate owner making product decisions. Package versions are conservative — deliberately so. You will not be running the latest versions of anything, but what ships in Debian stable has been rigorously tested. Support for Debian 12 runs through June 2028 with long-term support extending further. If your servers are running stable, non-bleeding-edge software (PostgreSQL, Nginx, standard Python versions), Debian is hard to argue against.
AlmaLinux vs. Rocky Linux: The Honest Comparison
A significant amount of online commentary treats the AlmaLinux versus Rocky Linux choice as if it carries major technical weight. For most small teams, it does not. The packages are functionally identical. The kernel versions track RHEL closely in both cases. Boot behavior, systemd configuration, SELinux policy, firewalld defaults — these are effectively the same across both distributions. You will not notice a performance difference.
The decision should come down to two factors: governance preference and your existing hosting relationships.
Rocky Linux’s governance structure positions it as a fully community-driven project with corporate sponsorship but community control. If the memory of Red Hat taking over CentOS and redirecting it is still fresh for you, Rocky’s explicit commitment to community governance is meaningful. CIQ, the company that provides commercial Rocky Linux support, is a significant backer, but the RESF structure is designed to prevent any single entity from taking control.
AlmaLinux has deeper roots in the shared hosting and VPS industry. Many major providers — CloudLinux itself, cPanel, many data center operators — have standardized on AlmaLinux. If you are moving servers at a hosting provider, or if you rely on control panels with panel-specific packages, there is a reasonable chance the hosting environment has better support and testing depth for AlmaLinux. Check your provider before you decide.
The practical recommendation: pick one, document the choice, and move on. The engineering time you would spend deeply evaluating these two distributions would be better spent on the migration itself.
Why Many Teams Are Moving to Ubuntu or Debian Instead
There is a real migration pattern among small engineering teams that the RHEL ecosystem does not talk about loudly: a substantial fraction of teams that used to run CentOS are ending up on Ubuntu or Debian. The reasons are worth being honest about.
First, talent. Engineers who learned Linux on Ubuntu are more common than engineers who learned on CentOS, and this gap has widened as cloud computing normalized Ubuntu as the default server image on AWS, GCP, and Azure. A small team of two or three engineers may simply operate more fluently on Debian-based systems. That is not a technical argument, but it is a real operational one.
Second, tooling and documentation density. The density of blog posts, Stack Overflow answers, and vendor documentation targeting Ubuntu versus RHEL-based systems is not even close. Ubuntu gets more of everything. For a team without a dedicated systems engineer, the probability that a problem you encounter has a documented solution is meaningfully higher on Ubuntu.
Third, the RHEL ecosystem’s recent history created trust damage that AlmaLinux and Rocky have not fully repaired — not through any fault of their own, but because the question “what happens if this project also changes direction in five years?” is now a reasonable one to ask. Ubuntu’s track record of maintaining LTS commitments is long. Debian’s is longer. Rocky and AlmaLinux have four years of track record.
The counterargument for staying in the RHEL ecosystem is also real. If you run software certified for RHEL — commercial databases, ERP systems, security tools with vendor support terms tied to RHEL variants — staying in the ecosystem avoids renegotiating support agreements. If your team already has deep SELinux and RPM expertise, the retraining cost of moving to Debian-based systems is non-trivial. If you are in a regulated environment where change control is expensive, picking Rocky or AlmaLinux means a much shorter conversion path from CentOS.
The Migration Playbook
Whether you are going to AlmaLinux, Rocky, Ubuntu, or Debian, the structure of a competent migration follows the same stages. Skipping any of these stages is how migrations become incidents.
Stage 1: Pre-Migration Audit
Before you touch anything, document what is actually running on the server. This sounds obvious, but production servers accumulate history, and the server you think you understand has almost certainly diverged from any documentation you have. Run rpm -qa to get a full package list and save it. Run systemctl list-units --type=service --state=running to inventory running services. Check /etc/cron.d, /var/spool/cron, and /etc/cron.daily for scheduled jobs. Document all listening ports with ss -tlnp. Export your current firewalld rules or iptables ruleset.
Pay particular attention to any packages installed from third-party repositories: EPEL, Remi, IUS, SCL, and any vendor-specific repos. These are the most common source of post-migration package incompatibilities. Third-party repos built for CentOS 7 will not automatically have CentOS-replacement equivalents, and some packages may require finding new upstream sources or compiling from source.
Stage 2: Test in a Snapshot or Clone
If your infrastructure allows it — and on any modern virtualized or cloud environment it should — take a snapshot or clone the server before beginning. If you cannot snapshot, spin up a VM with the same package list on your target distribution and test your application stack against it. Discovering that a specific version of a Perl module or a custom Apache module does not behave identically on the target OS should happen in a test environment, not on the live server.
Stage 3: The Actual Conversion (RHEL Path)
For in-place migration from CentOS 7 to AlmaLinux 8 or Rocky Linux 8, both projects provide migration scripts that swap the base packages and repositories without reinstalling the operating system. AlmaLinux provides almalinux-deploy.sh; Rocky Linux provides migrate2rocky.sh. Both scripts are available from their respective GitHub repositories and have been run on hundreds of thousands of servers.
The general process is: download the script over HTTPS, verify the SHA256 checksum, run it as root. The script swaps the GPG keys, replaces the repository files, reinstalls the base packages, and reboots. On a clean CentOS 7 installation with standard packages, this typically completes in under 30 minutes. On a server with heavy customization, third-party packages, or packages installed from non-standard sources, expect complications.
One important note: direct in-place migration from CentOS 7 to AlmaLinux 9 or Rocky Linux 9 is not officially supported. The major version jump (7 to 9) requires going through 8 first, or doing a fresh install. If your target is version 9, the cleanest path is usually a fresh installation with manual data migration rather than chaining two in-place upgrades.
Stage 4: The Actual Migration (Ubuntu/Debian Path)
There is no equivalent in-place migration path from CentOS to Ubuntu or Debian. These are different package management ecosystems, different filesystem layout conventions, different init system configurations. You will do a fresh installation on a new server (or a wiped system) and migrate your application and data manually. This is actually a feature disguised as a limitation: it forces you to rebuild from a clean, known-good state, which is often healthier than carrying forward years of accumulated cruft.
The migration checklist for this path is: provision the new server, install application dependencies, migrate data (rsync for files, pg_dump/mysqldump for databases), replicate your cron jobs and systemd units, update configuration files for any path or package name differences, then cut over DNS or update load balancer targets. Test at each step before the cutover.
The Gotchas That Trip People Up
Experience migrating CentOS servers reveals a consistent set of problems that catch teams off guard. Knowing about them in advance turns them from incidents into expected work.
SELinux Policy Differences
If your CentOS server was running with SELinux in enforcing mode — as it should be — and you are migrating to AlmaLinux or Rocky, the SELinux policies are similar but not identical across major versions. Custom SELinux policies written for RHEL 7 may not apply cleanly to RHEL 9 equivalents. Plan for an ausearch and audit2allow pass after migration to catch any denials that your custom configuration previously handled. If your CentOS server had SELinux set to permissive or disabled, fix that on your new installation — do not carry the permissive setting forward as a migration shortcut.
Firewall Configuration
CentOS 7 used firewalld by default. AlmaLinux 9 and Rocky Linux 9 also use firewalld, but zone behavior and some service definitions have changed between versions. More importantly, if you are migrating to Ubuntu, the default firewall is ufw, not firewalld — and the configuration syntax is entirely different. Your existing firewall rules will not transfer automatically. Export them explicitly, then re-implement them on the new system from scratch. This is not an opportunity to copy-paste; it is an opportunity to audit whether all those rules are still correct.
Network Interface Names
Older CentOS 7 servers, particularly physical machines or older VMs, may be using legacy network interface names like eth0 instead of predictable interface names like enp3s0. Modern distributions default to predictable names. If you have scripts, firewall rules, or application configurations referencing eth0 explicitly, they will break silently after migration unless you account for this. Inventory all interface references before starting.
DNS Resolver Changes
RHEL 9-based systems (and therefore AlmaLinux 9 and Rocky 9) default to systemd-resolved and use /etc/resolv.conf as a symlink to the systemd-resolved stub. If your CentOS 7 server had manually configured /etc/resolv.conf with specific nameserver entries, those entries will be silently ignored or overwritten post-migration unless you configure systemd-resolved explicitly. Applications that depend on specific DNS resolution behavior — internal DNS servers, split-horizon configurations, custom search domains — need to be re-validated after migration. Ubuntu also uses systemd-resolved by default and has the same behavior.
Python and Scripting Runtime Versions
CentOS 7 shipped with Python 2.7 as the system Python, and while Python 2 reached end of life in January 2020, a remarkable amount of internal tooling was never ported. If your operation scripts, automation, or monitoring agents depend on Python 2, this is the forcing function to finally deal with it. AlmaLinux 9 and Rocky 9 do not ship Python 2 by default. Ubuntu 24.04 does not ship Python 2 at all. Audit your scripts before migration, not after.
When to Rebuild Instead of Migrate In-Place
The in-place migration tools work, but they are not always the right answer. There is a clear heuristic: if a server has been running for more than three years without a rebuild, you should strongly consider treating the migration as a full rebuild rather than an in-place conversion.
Servers that have been running for years accumulate state: configuration drift, manual changes undocumented anywhere, packages installed for debugging that never got removed, cron jobs added by a contractor who left eighteen months ago, file permission changes whose purpose nobody remembers. An in-place migration carries all of this forward. A rebuild from scratch gives you a server whose state you actually understand.
The rebuild argument is even stronger if you do not have your server configuration in code. If your current CentOS server is the canonical source of truth for its own configuration — meaning you could not reproduce it from an Ansible playbook, a Terraform module, or similar — the migration is your opportunity to fix that. Rebuild the server using infrastructure-as-code tooling, and treat the old server as the documentation for what you need to replicate.
The practical test: can you answer the question “what is running on this server and why?” for every installed package, every running service, and every cron job? If not, the in-place migration will carry those unknowns onto your new system. A rebuild forces you to answer those questions explicitly.
Cost Implications: RHEL Licensing vs. Free Alternatives
The financial picture is straightforward enough that it rarely justifies extended analysis, but teams sometimes overcomplicate it.
AlmaLinux, Rocky Linux, and Debian are free, full stop. There are commercial support options available — CloudLinux and CIQ offer paid support for AlmaLinux and Rocky respectively, and Canonical offers Ubuntu Advantage (now called Ubuntu Pro) with formal SLAs — but the base operating systems cost nothing. For a small team with three to ten servers, the practical cost of migrating to any of these is engineering time, not licensing fees.
RHEL licensing at Red Hat’s standard rates runs roughly $350 to $500 per server per year for a standard subscription. At ten servers, that is $3,500 to $5,000 annually. For a small team, that is real money. The free developer subscription covering up to 16 servers closes this gap significantly, but carries the implicit risk that Red Hat could change the terms of the free tier — as they have done before with CentOS. Teams that choose RHEL should factor in the possibility of future cost changes.
The hidden cost that often gets underestimated is engineering time for the migration itself. A careful migration of a single production server — including audit, testing, execution, and post-migration validation — should be budgeted at four to eight hours of senior engineer time for a straightforward application. Complex servers with many interdependencies, custom kernel modules, or legacy software can take significantly longer. For a team with ten servers, assume two to four weeks of elapsed calendar time if you are doing this carefully alongside normal work.
Frequently Asked Questions
Can I still get security patches for CentOS 7 in 2026?
Not from the official CentOS project. CentOS 7 EOL was June 30, 2024. TuxCare (formerly CloudLinux’s extended lifecycle service) and a few other vendors offer paid extended lifecycle support for CentOS 7, providing security patches for a fee. This is a stopgap, not a long-term solution. If you are using an extended lifecycle service to stay on CentOS 7, set a hard deadline for completing migration — paying for patches on EOL software does not reduce the underlying risk of running aging software.
Is CentOS Stream a viable production platform?
It depends on your tolerance for change and your workload type. CentOS Stream 9 is a rolling pre-RHEL release, which means packages update more frequently than a point-release distribution. For development environments, staging, or workloads that are not sensitive to minor package version changes, it is reasonable. For production databases or applications where you need to control upgrade timing carefully, the rolling nature of Stream is a liability. Most teams running production servers should use AlmaLinux, Rocky, or a Debian-based alternative rather than Stream.
What about Oracle Linux?
Oracle Linux is a legitimate RHEL rebuild with solid compatibility and Oracle’s backing. Its main liability for small teams is governance: Oracle is a corporation with its own commercial interests, and their track record of making enterprise decisions that conflict with community interests is long enough to give pause. The same argument against RHEL’s terms-of-service risk applies here with perhaps greater force. AlmaLinux and Rocky have cleaner governance structures for teams prioritizing independence.
Do I need to migrate CentOS Stream servers?
CentOS Stream 8 reached end of life in May 2024. CentOS Stream 9 is actively maintained and will continue to receive updates, but it will end of life when RHEL 9 does, currently projected for May 2032. If you are on Stream 9 and comfortable with its rolling-release nature, no immediate action is required — but you should have a migration plan before 2030 at the latest, and you should be testing your applications against periodic Stream updates to avoid surprise breaks.
The teams that handle CentOS migration cleanly are the ones that treat it as an infrastructure improvement project, not an emergency remediation. The ones that struggle are the ones that waited until after a security incident to care.
Migration fatigue is real in small teams, and the immediate consequence of running CentOS 7 past its EOL date is often invisible — the server keeps working, no alarms fire, and the urgency fades. The risk is cumulative and non-linear: every month on unpatched infrastructure is another month of exposure to vulnerabilities that will never be patched. The migration is finite. The exposure is not. Pick your target distribution, schedule a maintenance window, and run the playbook.
Michael Sun covers infrastructure, security, and the operational realities of running production systems at small scale. He has worked on server migrations across RHEL, Debian, and BSD environments over the past decade.
If you wish for to grow your knowledge just keep visiting this web page and be updated with the latest information posted here.