# End dates are coming for CentOS Stream 8 and CentOS Linux 7

We’ve got an important message for Developers, Administrators, and Users.

## Time flies when you’re building RPMs…

...and install images... and containers... and cloud images... and so much more!

Time files when planning system migrations too - so **start planning now**!

But, before we get there, **OS migration time is a wonderful opportunity to test out your disaster recovery plans!** Often, without much extra work, you can treat an OS migration like a system loss and validate your documentation, provisioning, configuration, fail-over, and backup systems against something besides a set of test hosts. It is hard to test these in production, but you could test them in pre-production with this migration.

## CentOS Stream 8 End of Builds: May 31, 2024

We expect this to correspond roughly to the release of RHEL 8.10. CentOS Stream 8 is where new features are developed for RHEL 8. With the release of RHEL 8.10, RHEL 8 will be considered [largely feature complete](https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_2_Phase).

When we announced CentOS Stream we noted that it was designed to serve "as the upstream (development) branch of Red Hat Enterprise Linux." With RHEL 8 transitioning to Maintenance phase, CentOS Stream 8 has fulfilled its purpose.

After May 31, 2024, CentOS Stream 8 will be archived and no further updates will be provided.

There are a few good options for planning your migrations.

Migration/Upgrade options:
* Migrate to CentOS Stream 9
* [Convert to RHEL 8](https://www.redhat.com/en/blog/fastest-road-centos-linux-red-hat-enterprise-linux), there are no cost licenses for use under [some conditions](https://developers.redhat.com/products/rhel/overview)
* Convert to another operating system in the Enterprise Linux ecosystem. Several projects have derived new operating systems from the CentOS and RHEL sources

Don't forget to review [the RHEL Lifecycle](https://access.redhat.com/support/policy/updates/errata#RHEL8_and_9_Life_Cycle) to help select the right option for your systems!

The packages will be archived on vault.centos.org after May 31, 2024.

## CentOS Linux 7 End of Life: June 30, 2024

RHEL 7 reaches [End of Maintance on June 30, 2024](https://access.redhat.com/support/policy/updates/errata#Life_Cycle_Dates). After June 30, 2024, there will be no updates published for CentOS Linux 7.

If you want to stay within the RHEL ecosystem, you’ll need to decide if you want to move to a RHEL8 or a RHEL9 based distribution. You should carefully read each of these to help select the right platform for your systems:

* [The RHEL Lifecycle](https://access.redhat.com/support/policy/updates/errata#RHEL8_and_9_Life_Cycle)
* [Considerations for RHEL8](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/considerations_in_adopting_rhel_8/index)
* [Considerations for RHEL9](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/considerations_in_adopting_rhel_9/index)

The packages will be archived on vault.centos.org after June 30, 2024.

You can also [convert to RHEL7](https://www.redhat.com/en/blog/fastest-road-centos-linux-red-hat-enterprise-linux) and purchase [Extended Lifecycle Support](https://www.redhat.com/en/resources/els-datasheet) if you are unable to migrate your system before June 30, 2024.

## DO NOT FORGET TO MIGRATE YOUR CONTAINERS!

Always remember to **update your containers regularly**. Even though it is an image, it still has components that might contain (ha ha) security issues.

You may want to review the [Red Hat Enterprise Linux Container Compatibility Matrix](https://access.redhat.com/support/policy/rhel-container-compatibility) as you look at how best to perform these updates and establish a regular update strategy.

One of these days, someone out there will find a vulnerable container hooked up to an autoscaler. On that day, the cluster will scale up the vulnerable containers *so the folks exploiting it get good performance*! What’s worse, if this container is on a paid cloud service, not only is it compromised, but somebody will need to pay off the extra costs generated by cloud-native compromised containers at scale.

**Remember**: always set resource limits and autoscaler limits on your containers!
**Remember**: containers are Linux systems too, update them regularly!