What are RHEL in-place upgrades?

When Red Hat Enterprise Linux (RHEL) customers want to update their application stack, get the newest security updates or are nearing the end of a RHEL life cycle (such as RHEL 7, which will reach end of maintenance on 30 June 2024), they usually want to get to the newest release. This post is the first of a series of articles about RHEL upgrades that we hope will help you plan for future upgrades. We'll begin by taking a look at RHEL in-place upgrades.

What problems do in-place upgrades solve?

Historically, upgrades required a fresh installation of the operating system coupled with redeploying all application stacks, databases and configurations. In-place upgrades solve this hassle while preserving existing customer workflows. Let’s first take a look at where in-place upgrades are the right choice for businesses in comparison to performing a fresh installation.

In-place upgrades vs. fresh installations

In-place upgrades can, in many cases, be performed by less-experienced system administrators. If your systems don't have complex or unusual configurations, you can run just a few commands across all of the machines that need to be upgraded, review the pre-upgrade analysis report and run any suggested remediation, if necessary.

Preserve configurations

Retaining control over the installed application is one of the most important features of in-place upgrades. It is possible to extend the upgrade process by specifying which custom repositories to use during the upgrade. Writing custom Leapp actors can also help migrate third-party applications with specific configurations. Organizations looking to modernize their environment will benefit from this control, allowing them to take care of custom application requirements. Finally, any remediation steps indicated during the pre-upgrade process can be automated using Ansible playbooks.

Reduce the need for advanced skills

In-place upgrades do not require previous knowledge of existing system configurations or installed applications, so entry-level administrators are able to do the upgrade. Risk of accidental deletion of applications or configurations is reduced by running the pre-upgrade analysis and applying suggested remediations. The administrator only needs to be able to understand the information in the report.

Retain subscriptions

Since no information about existing RHEL subscriptions is deleted during an in-place upgrade, all the subscriptions keep functioning.

Save time and resources

Clearly, in-place upgrades save time and valuable resources. They are a convenient way to extend the life of current hardware while modernizing the entire environment.

Reduce uncertainty

Pre-upgrade analysis is a useful tool on its own. If a customer is unsure, they can run the pre-upgrade analysis to generate an inventory of installed packages on the system with possible upgrade paths and remediation suggestions. This can be useful when deciding upon the correct upgrade approach.

Fresh installations 

All system data is wiped when you perform a fresh install of RHEL, including applications and configurations. This adds tremendous operating costs and requires additional expertise during the deployment.

Wipes out existing configuration

Configurations are deleted during the installation, and reapplying them all can be time consuming, especially if you are not using automation capabilities found in products like Red Hat Ansible Automation Platform.

Adds time and cost

You have to reinstall the operating system (OS) on possibly hundreds—or even thousands—of machines, including the redeployment of the entire application stack. This added work costs resources and time.

Machines have to be resubscribed

The wiped machines do not have the ability to retain existing RHEL subscriptions during the install. Every machine will need to be resubscribed in order to function properly.

So, are fresh installations ever good?

Fresh installations can be beneficial when you transition to new hardware, have a new application stack, or want new management and automation capabilities. Greenfield projects (projects that don’t rely on previous work), for example, can be good use cases for fresh installations. 

Availability and supported versions

When upgrading from the command line interface, all required packages can be installed via dnf or yum—by installing leapp-upgrade—a virtual package provided on all RHEL systems where Leapp is available. The leapp command then utilizes its subcommands to create the pre-upgrade report, after which the upgrade itself is available.

Customers can also run the pre-upgrade analysis in Red Hat Satellite, where they manage their machines. After running the pre-upgrade assessment and remediating the analyzed risks, all machines can be upgraded at once in the UI, too. See Leapp in Satellite for more information.

Multiple versions of RHEL are eligible for an upgrade. For a complete, up-to-date list of all supported upgrade paths, check out Supported in-place upgrade paths for Red Hat Enterprise Linux. The list is updated with each new RHEL release.

Regarding support on public clouds, we offer in-place upgrades for on-demand pay-as-you-go (PAYG) instances on Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform with Red Hat Update Infrastructure (RHUI). We also support upgrades for bring your own subscription (BYOS) instances on all public clouds that use Red Hat Subscription Manager for a RHEL subscription.

One thing to keep in mind is that direct upgrades over multiple major releases (e.g. RHEL 6 to RHEL 8) are not possible. The way you upgrade from version 6 to 8 is to first upgrade to RHEL 7, and then upgrade to RHEL 8.

Exact details of supported architectures and products, with more in-depth information on how to upgrade, can be found in the documentation below:

• Upgrading from RHEL 6 to RHEL 7
• Upgrading from RHEL 7 to RHEL 8
• Upgrading from RHEL 8 to RHEL 9 

Summary

In-place upgrades can solve several redeployment issues while saving cost and time. While fresh installs can still be used for greenfield projects, in-place upgrades are the clear winner when modernizing existing environments. In-place upgrades are also a crucial part of the RHEL ecosystem, so their ongoing support is to be expected, along with planned innovations.