Chapter 2. Planning an upgrade

An in-place upgrade is the recommended and supported way to upgrade your system to the next major version of RHEL.

Consider the following before upgrading to RHEL 8:

  • Operating system - The operating system is upgraded by the Leapp utility under the following conditions:

    • The latest available RHEL 7 version of the Server variant is installed, which currently is:

      • RHEL 7.9 on the 64-bit Intel, IBM POWER 8 (little endian), and 64-bit IBM Z architectures and, when on SAP HANA, on the 64-bit Intel architecture
      • RHEL 7.6 on architectures that require kernel version 4.14: IBM POWER 9 (little endian) or 64-bit IBM Z (Structure A)


        The IBM POWER 9 (little endian) and 64-bit IBM Z (Structure A) architectures have reached end of life. The final upgrade path for these architectures is from RHEL 7.6 to RHEL 8.4. Later releases to the in-place upgrade, including new upgrade paths, features, and bug fixes, will not include these architectures.

        See Supported in-place upgrade paths for Red Hat Enterprise Linux for more information.

    • Minimum hardware requirements for RHEL 8 are met.
    • You have access to up-to-date RHEL 7.9 and the target operating system (OS) version (for example, RHEL 8.6) content. See Preparing a RHEL 7 system for the upgrade for more information.
  • Applications - You can migrate applications installed on your system by using Leapp. However, in certain cases, you have to create custom actors, which specify actions to be performed by Leapp during the upgrade, for example, reconfiguring an application or installing a specific hardware driver. For more information, see Handling the migration of your custom and third-party applications. Note that Red Hat does not support custom actors.
  • Security - You should evaluate this aspect before the upgrade and take additional steps when the upgrade process completes. Consider especially the following:

    • Before the upgrade, define the security standard your system needs to comply with and understand the security changes in RHEL 8.
    • During the upgrade process, the Leapp utility sets SELinux mode to permissive.
    • In-place upgrades of systems in Federal Information Processing Standard (FIPS) mode cannot be fully automated by Leapp. If your scenario requires upgrading RHEL 7 systems running in FIPS mode, you must:


      To ensure that all cryptographic keys conform to the FIPS 140-2 standard, start a new installation in FIPS mode instead of performing an in-place upgrade of an already deployed system. Use the following steps only if the security policy of your company allows this alternative upgrade process and if you can ensure the regeneration and reevaluation of all cryptographic keys on the upgraded system.

      1. Disable FIPS mode in RHEL 7.
      2. Upgrade the system using Leapp. You must follow the pre-upgrade, upgrade, and post-upgrade instructions as in any other in-place upgrade.
      3. Enable FIPS mode in RHEL 8. See Switching the system to FIPS mode in the RHEL 8 Security hardening document for details.
      4. Re-generate cryptographic keys on your system. See Appendix C, Locations of cryptographic keys in RHEL 8 for more information.
    • After the upgrade is finished, re-evaluate and re-apply your security policies. For information about applying security policies that have been disabled during the upgrade or newly introduced in RHEL 8, see Applying security policies.
  • Storage and file systems - Always back up your system prior to upgrading. For example, you can use the Relax-and-Recover (ReaR) utility, LVM snapshots, RAID splitting, or a virtual machine snapshot.


    File systems formats are intact. As a result, file systems have the same limitations as when they were originally created.

  • High Availability - If you are using the High Availability add-on, follow the Recommended Practices for Applying Software Updates to a RHEL High Availability or Resilient Storage Cluster Knowledgebase article.
  • Downtime - The upgrade process can take from several minutes to several hours.
  • Satellite - If you manage your hosts through Satellite, you can upgrade multiple hosts simultaneously from RHEL 7 to RHEL 8 by using the Satellite web UI. For more information, see Upgrading Hosts to Next Major Red Hat Enterprise Linux Release.
  • SAP HANA - If you are using SAP HANA, follow How to in-place upgrade SAP environments from RHEL 7 to RHEL 8 instead. Note that the upgrade path for RHEL with SAP HANA might differ.
  • Public clouds - The in-place upgrade is supported 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). The in-place upgrade is also supported for Bring Your Own Subscription instances on all public clouds that use Red Hat Subscription Manager (RHSM) for a RHEL subscription.
  • Language - All Leapp reports, logs, and other generated documentation are in English, regardless of the language configuration.
  • Boot loader - It is not possible to switch the boot loader from BIOS to UEFI on RHEL 7 or RHEL 8. If your RHEL 7 system uses BIOS and you want your RHEL 8 system to use UEFI, perform a fresh install of RHEL 8 instead of an in-place upgrade. For more information, see Is it possible to switch the BIOS boot to UEFI boot on preinstalled Red Hat Enterprise Linux machine?
  • Known limitations - Notable known limitations of Leapp currently include:

    • Encryption of the whole disk or a partition, or file-system encryption currently cannot be used on a system targeted for an in-place upgrade.
    • No network-based multipath and no kind of network storage mount can be used as a system partition (for example, iSCSI, or NFS).
    • The in-place upgrade is currently unsupported for on-demand PAYG instances on the remaining public clouds (Huawei Cloud, Alibaba Cloud) that use Red Hat Update Infrastructure but not RHSM for a RHEL subscription.
    • The in-place upgrade is not supported for systems with any Ansible products, including Ansible Tower, installed. To use a RHEL 7 Ansible Tower installation on RHEL 8, see the How do I migrate my Ansible Automation Platform installation from one environment to another? Knowledgebase solution.

See also Known Issues.

You can use Red Hat Insights to determine which of the systems you have registered to Insights is on a supported upgrade path to RHEL 8. To do so, go to the respective Advisor recommendation in Insights, enable the recommendation under the Actions drop-down menu, and inspect the list under the Affected systems heading. Note that the Advisor recommendation considers only the RHEL 7 minor version and does not perform a pre-upgrade assessment of the system. See also Advisor-service recommendations overview.