CentOS Linux 8 reached end of life on December 31, 2021, and CentOS Linux 7 on June 30, 2024. The CentOS Project's comparison of Linux and Stream records those dates and explains the distinction between the projects.
If either version remains in production, start with an inventory and a supported destination. An operating system continuing to boot is not evidence that it still receives the maintenance your organization needs.
Choose a destination by workload
RHEL, a community distribution with an appropriate support arrangement, or a rebuilt application on another supported platform may each be suitable. Compare the application vendor's certified configurations, lifecycle, patch coverage, support contract and your team's operating skills.
Do not assume that all community distributions are unsupported or that a subscription alone covers every application. Record which organization owns the operating system, application and integration support in each option.
Conversion and rebuild are different approaches
Red Hat's Convert2RHEL FAQ describes supported conversions for selected distributions, versions and architectures. Check the current matrix before choosing this route.
A conversion replaces distribution components; it is not automatically an upgrade to a newer major release. Converting a CentOS 7 system to RHEL 7 still requires a plan for the target's lifecycle and any appropriate extended coverage. Consult the RHEL lifecycle policy for the selected release.
A clean rebuild can be preferable where the application needs modernization or the existing server has accumulated undocumented changes. It also provides an opportunity to standardize configuration and separate application data from the operating system.
Prepare a representative pilot
Before conversion or rebuild:
- Record applications, repositories, third-party packages and integrations.
- Confirm target support and required subscriptions.
- Back up configuration and data, and demonstrate recovery.
- Test the procedure on a representative non-production copy.
- Measure the outage and define rollback criteria.
Check business functions after the change, not only whether the server starts. Include authentication, scheduled jobs, monitoring, backup agents and application connections.
Make maintenance part of the migration
A supported target still needs an operating process. Assign patch ownership, maintenance windows and a way to test important updates before broad deployment. Backported fixes can reduce version churn, but no patching strategy removes the need for application validation.
Use the migration to document hardening choices, access controls and monitoring. Apply those choices consistently, with exceptions recorded rather than left to individual servers.
Plan the rollout
Group systems by dependencies and business impact. Migrate a small wave, review the result and update the runbook before expanding. Keep an inventory of systems awaiting work and the exposure or support arrangements in place during the transition.
Before confirming the destination, compare RHEL, Ubuntu and SUSE support and certification requirements against the applications you need to retain.
BustanTech provides RHEL assessment, deployment and maintenance services. Contact us to discuss the current estate, supported destinations and a migration plan.