RHEL Migration Checklist for Enterprise Linux Servers

What You Will Know After Reading This

• Why running RHEL 7 or CentOS 7 past June 30, 2024 leaves you without standard security errata, and what that means for PCI DSS, ISO/IEC 27001 and SOC 2 audits.
• How to run leapp preupgrade, read /var/log/leapp/leapp-report.txt, and separate hard inhibitors from advisory findings.
• How to map deprecated packages before the jump: Python 2 to Python 3, SHA-1-signed RPMs, legacy network-scripts, and unsigned third-party kernel modules.
• What changes underneath you: SELinux policy and boolean shifts, the move to NetworkManager keyfiles, and firewalld’s nftables backend replacing raw iptables rules.
• How to build a rollback path with LVM snapshots, Boom boot entries, ReaR images or hypervisor snapshots before you type leapp upgrade.

Table of Contents

• The Core Enterprise Reality: The Danger of Legacy Linux Deployments
• The Skimmable Migration Path Matrix: In-Place vs. Side-by-Side
• The Leapp Upgrade Lifecycle: Visual Architecture
• The Ekfrazo 5-Stage RHEL Migration Checklist
• Where Linux Migrations Fail: Hidden Dependencies and Network Outages
• Qualification Matrix: When to Upgrade In-Place vs. Re-Platform
• How Ekfrazo Delivers Secure, Governed Linux Automation
• Frequently Asked Questions

The Core Enterprise Reality: The Danger of Legacy Linux Deployments

Short answer: A RHEL migration checklist exists because RHEL 7 and CentOS 7 stopped receiving standard security errata on June 30, 2024. Every unpatched kernel CVE since then is an open audit finding on those hosts.

RHEL 7’s standard 10-year lifecycle ended on June 30, 2024. CentOS Linux 7 reached end of life the same day, with no paid extension at all. Red Hat sells an Extended Life Cycle Support (ELS) add-on for RHEL 7, but only for hosts already on RHEL 7.9, and it covers selected critical and important fixes, not new hardware enablement or feature work (Red Hat ELS announcement).

The operational consequences compound quickly:

• Compliance exposure. PCI DSS v4.0 Requirement 6.3.3 and ISO/IEC 27001 Annex A 8.8 expect timely patching of known vulnerabilities. An OS without vendor errata fails that control by definition.
• Toolchain drift. RHEL 7 ships glibc 2.17, kernel 3.10 and Python 2.7. Current builds of monitoring agents, EDR sensors, database clients and container runtimes increasingly target glibc 2.28+ and drop RHEL 7 builds.
• Upgrade debt. Leapp only moves one major version at a time. A RHEL 7.9 host must go to RHEL 8.10, then to RHEL 9, and then to RHEL 10. Every quarter of delay adds another hop to the eventual programme.
• Hardware ceiling. RHEL 10 raises the x86 baseline to x86-64-v3. Older CPUs that run RHEL 7 today may never run RHEL 10, which turns some in-place plans into hardware refresh plans.

A disciplined rhel migration checklist turns that debt into a sequenced, testable programme: inventory, Leapp pre-upgrade scans, dependency remediation, controlled execution and post-upgrade validation, with a rollback path at every stage.

Planning a Mass Enterprise Server Upgrade? Stop guessing which legacy applications will break. Request a RHEL migration assessment to audit your infrastructure with Ekfrazo’s senior Linux architects.

The Skimmable Migration Path Matrix: In-Place vs. Side-by-Side

Short answer: Choose in-place Leapp upgrades for standard, well-documented hosts on supported paths. Choose side-by-side rebuilds with Ansible and Terraform when tech debt, hardware limits or architecture changes make in-place risk unacceptable.

Supported paths are from Red Hat’s RHEL 7 → 8, RHEL 8 → 9 and RHEL 9 → 10 documentation. Leapp cannot skip a major version.

Scenario: an in-place upgrade fails mid-execution with no snapshot

Consider a RHEL 8.10 database host running a vendor backup agent with a proprietary kernel module. The team runs leapp upgrade --reboot on Saturday night without a block-level snapshot.

1. The system reboots into the Leapp upgrade initramfs and starts the RPM transaction. Halfway through, the transaction fails on a conflicting third-party package.
2. The host is now in a mixed state: some packages are el9, some el8, and the bootloader points at a kernel whose modules are incomplete.
3. Leapp has no built-in rollback. With no LVM snapshot, VM snapshot or ReaR image, the only recovery is a rebuild from bare metal plus a database restore from last night’s backup.
4. Recovery time stretches from a planned 2-hour window to 12–24 hours. Every transaction since the last backup needs replay or reconciliation.

The fix is cheap compared with the outage: take an LVM snapshot with a Boom boot entry (supported for RHEL 8.8/8.10 → 9) or a hypervisor snapshot, test the rollback once in staging, and record the recovery time objective before the change board approves the window.

The Leapp Upgrade Lifecycle: Visual Architecture

Short answer: Every Leapp in-place upgrade follows seven gates, from snapshot to application validation. A failed gate loops back to remediation; it never proceeds to leapp upgrade.

+-------------------------------+
| 1. Server Snapshot & Backup   |  LVM snapshot + Boom entry / VM snapshot / ReaR ISO
+---------------+---------------+
                |
                v
+-------------------------------+
| 2. Repository Registration    |  subscription-manager register / attach
|    (Subscription Manager)     |  enable BaseOS + AppStream (or Satellite CV)
+---------------+---------------+
                |
                v
+-------------------------------+
| 3. leapp preupgrade           |  /var/log/leapp/leapp-report.txt
|    (Identify Blockers)        |  /var/log/leapp/leapp-report.json
+---------------+---------------+  /var/log/leapp/answerfile
                |
                v
+-------------------------------+        inhibitors remain?
| 4. Remediate SELinux /        | <-----------------------------+
|    Kernel Modules / Packages  |                               |
+---------------+---------------+                               |
                |  re-run leapp preupgrade -------------------->+
                |  (zero inhibitors)
                v
+-------------------------------+
| 5. leapp upgrade              |  downloads target RPMs, builds
|                               |  RHEL-Upgrade-Initramfs boot entry
+---------------+---------------+
                |
                v
+-------------------------------+
| 6. Reboot into New RHEL       |  RPM transaction runs in initramfs,
|    Kernel                     |  SELinux relabel, second reboot
+---------------+---------------+
                |
                v
+-------------------------------+        validation fails?
| 7. Post-Migration App         | ---------> lvconvert --merge /
|    Validation                 |            revert VM snapshot
+-------------------------------+

Read the diagram top to bottom: no host reaches step 5 until a fresh leapp preupgrade run reports zero inhibitors, and every host keeps a rollback route open until step 7 signs off.

The Ekfrazo 5-Stage RHEL Migration Checklist

Short answer: The Ekfrazo RHEL migration checklist runs five gated phases: inventory and backup, Leapp scanning, dependency remediation, controlled execution, and post-upgrade validation. No host advances while a gate is red.

Phase 1: Inventory, Subscription Management, and Baseline Backups

Good linux migration planning starts with knowing exactly what runs on each host and who owns it.

• Record OS minor version, kernel, CPU microarchitecture, boot mode (BIOS/UEFI), storage layout and application owner for every host.
• List non-Red Hat packages, which are the most common source of upgrade failures:

cat /etc/redhat-release; uname -r
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | grep -vi 'red hat'
[ -d /sys/firmware/efi ] && echo UEFI || echo BIOS

• Confirm registration and remove locks that block Leapp’s repository mapping:

subscription-manager status
subscription-manager release --unset
dnf versionlock clear        # RHEL 8; use yum on RHEL 7
dnf update -y && reboot      # land on the latest minor: 7.9, 8.10, 9.6 or 9.8

• Take a restorable baseline. For RHEL 8.8/8.10 → 9 with root on a single LVM volume, Red Hat documents an LVM snapshot plus a Boom boot entry (Red Hat: Managing system upgrades with snapshots). Separate /var or /usr file systems and RHUI cloud images need VM snapshots or ReaR instead.

lvcreate -s rhel/root -n root_snapshot_before_changes -L 25g   # thick LV; size to expected change
boom profile create --from-host
boom create --backup --title "Pre-upgrade RHEL 8" --rootlv rhel/root_snapshot_before_changes

Phase 2: Pre-Upgrade Auditing (Running and Analyzing the Leapp Scan)

leapp preupgrade changes nothing on the host. It simulates the upgrade and writes a report you can triage.

# RHEL 7.9
subscription-manager repos --enable rhel-7-server-extras-rpms
yum install -y leapp-upgrade

# RHEL 8.10 / 9.x
dnf install -y leapp-upgrade

leapp preupgrade --target 9.6     # set the target minor explicitly

• Read /var/log/leapp/leapp-report.txt for humans and /var/log/leapp/leapp-report.json for automation. Findings are ranked high, medium, low and info; inhibitors stop the upgrade outright.
• Extract inhibitors across a fleet:

jq -r '.entries[] | select(((.groups // []) + (.flags // [])) | index("inhibitor")) | .title' \
  /var/log/leapp/leapp-report.json

• Answer the questions Leapp records in /var/log/leapp/answerfile, for example on RHEL 7 → 8: leapp answer --section remove_pam_pkcs11_module_check.confirm=True.
• Typical inhibitors: loaded kernel drivers removed in the target release, RSA/SHA-1-signed packages (RHEL 8 → 9), unsupported encrypted volumes (only LUKS2 with a Clevis TPM 2.0 token is supported for 8 → 9), network or FCoE multipath storage, Ansible Automation Platform installed on the host, and x86-64-v2 CPUs on the 9 → 10 hop.
• At fleet scale, run the same scan through Red Hat Insights pre-upgrade analysis tasks or the infra.leapp Ansible collection, and aggregate the JSON into a single inhibitor backlog.

Phase 3: Remediating Application Dependencies and Deprecated Packages

Most of the engineering effort lives here. Fix each inhibitor at its source, then re-run leapp preupgrade until the report shows zero inhibitors.

Phase 4: Executing the RHEL Upgrade Steps and Kernel Reboot

Run the upgrade only inside an approved window, with out-of-band console access (iDRAC, iLO, vSphere/KVM console) in case networking does not return.

1. Re-run leapp preupgrade immediately before the window and confirm zero inhibitors.
2. Stop application services cleanly and confirm the latest backup or snapshot.
3. Run leapp upgrade --reboot (add --target to match the preupgrade scan).
4. The host boots the RHEL-Upgrade-Initramfs entry, runs the RPM transaction, relabels SELinux and reboots again. Watch the console and /var/log/leapp/leapp-upgrade.log.
5. Confirm the new release: cat /etc/redhat-release and uname -r.
6. For a RHEL 7 host, complete Phase 5 on RHEL 8.10, then repeat Phases 2–5 for the hop to RHEL 9.

Phase 5: Post-Upgrade Validation (SELinux, Firewalld, and Workload Testing)

Leapp sets SELinux to permissive during the upgrade, so the host is not production-ready until you restore enforcing mode (Red Hat: Applying security policies).

ausearch -m AVC,USER_AVC -ts boot          # fix denials first
sed -i 's/^SELINUX=.*/SELINUX=enforcing/' /etc/selinux/config && reboot
getenforce                                 # expect: Enforcing

firewall-cmd --state && firewall-cmd --list-all-zones
nft list ruleset
nmcli device status
update-crypto-policies --show              # RHEL 9 DEFAULT restricts SHA-1 signatures
rpm -qa | grep -E '\.el7|\.el8'            # leftover packages from the source release

• Run application smoke tests, database integrity checks, scheduled job dry-runs, and monitoring and backup agent heartbeats.
• Get written sign-off from the application owner, then delete the rollback snapshot (boom delete, lvremove) and remove leftover Leapp packages.

Where Linux Migrations Fail: Hidden Dependencies and Network Outages

Short answer: Most failed RHEL upgrades trace back to four causes: third-party kernel modules, legacy network configuration, ABI shifts in glibc or Python, and stricter crypto policy. Leapp flags some; testing catches the rest.

1. Third-party kernel modules break on first boot

EDR sensors, backup agents, HBA and multipath drivers, and GPU stacks often ship out-of-tree modules built for one kernel series. After the jump from kernel 4.18 to 5.14, the module fails to load. Storage paths disappear or the host fails to boot. Leapp reports known removed drivers, but it cannot vouch for a vendor module it has never seen.

Control: require the vendor’s support statement for the target release before scheduling the host, and test on a cloned VM with identical drivers.

2. Interfaces stay down after reboot

Hosts that still use network-scripts, ifup hooks or teamd configurations lose their custom behaviour on RHEL 9, where the network-scripts package no longer exists. On the 9 → 10 hop, ifcfg files themselves are on the way out in favour of NetworkManager keyfiles. Bonding, VLAN tagging and static routes are the usual casualties, and the result is a host reachable only through its console.

Control: convert every profile with nmcli connection migrate on the source release, reboot once, and confirm connectivity before the upgrade window.

3. Databases and middleware crash on glibc or Python shifts

A database client compiled against glibc 2.17, or an ops toolkit that calls /usr/bin/python, can fail silently after the upgrade. Collation changes between glibc versions can also corrupt PostgreSQL text indexes unless you reindex. Python 2 cron jobs simply stop running.

Control: inventory every runtime dependency in Phase 1, rebuild or re-certify binaries, and plan REINDEX windows for databases with text indexes.

4. TLS and SSH connections fail under RHEL 9 crypto policy

The upgrade keeps your existing system-wide crypto policy, but newly built RHEL 9 peers, HSM clients and partner endpoints may still present SHA-1 certificates or sub-2048-bit keys. Integrations break at the handshake, often days later when a certificate renews.

Control: scan certificates and SSH keys before the programme starts. Use DEFAULT:SHA1 only as a documented, time-boxed exception.

3 Questions Infrastructure Directors Must Ask Before Approving a RHEL Upgrade

1. What is the tested rollback time for this host? Not “we have backups”, but a measured restore from the snapshot or image taken for this change.
2. Does the latest leapp preupgrade report show zero inhibitors, and who signed off the high-severity findings? Every remaining risk should have a named owner.
3. Which third-party agents and kernel modules run on this host, and has each vendor certified the target RHEL release? No certification, no window.

Qualification Matrix: When to Upgrade In-Place vs. Re-Platform

Short answer: Upgrade in-place when the host is standard, vendor-supported and on a Leapp path. Re-platform side-by-side when the host carries heavy tech debt, needs new hardware or boot mode, or is moving to containers.

Side-by-side builds pay off when the new host comes from code: Ansible roles, rhel-system-roles, Terraform modules and image pipelines turn each rebuilt server into a repeatable artefact. That is the same discipline we apply in CI/CD pipeline engineering and cloud automation.

How Ekfrazo Delivers Secure, Governed Linux Automation

Short answer: Ekfrazo runs RHEL migrations as automated, auditable programmes: Ansible-driven Leapp waves, inhibitor backlogs with named owners, tested rollback, and ISO/IEC-aligned change evidence for every host.

Ekfrazo’s delivery model connects Customer Experience (CX), Employee Experience (EX) and Operational Experience (OX). A RHEL migration sits squarely in OX: customer-facing services and internal teams both depend on infrastructure that is supported, patched and automated. When the OS layer is out of support, every CX and EX commitment above it carries hidden risk.

Our enterprise Red Hat automation and infrastructure services cover the full programme:

• Discovery and inventory. Automated collection of OS, kernel, CPU microarchitecture, third-party packages and application ownership across the estate.
• Fleet-wide Leapp scanning. leapp preupgrade runs via Ansible and Red Hat Insights, with JSON reports aggregated into one inhibitor backlog ranked by business impact.
• Path decisions per host. In-place, side-by-side or retire, using the qualification matrix above and documented approval.
• Wave execution. infra.leapp playbooks, pre-staged answer files, LVM or VM snapshots, and out-of-band console access for every window.
• Governed validation. SELinux enforcing, firewalld and nftables review, crypto-policy checks and application sign-off, retained as change evidence for ISO/IEC 27001 and SOC 2 audits.

Move Your Linux Estate Back Onto Supported Ground

Ekfrazo’s senior Linux architects will scan a representative sample of your servers, map every Leapp inhibitor, and give you a host-by-host plan: in-place, re-platform or retire, with rollback and timelines.

Request a RHEL migration assessment

Frequently Asked Questions

Short answer: These five answers cover what infrastructure leaders ask most about RHEL migration checklists, upgrade paths, timelines, rollback and fleet-scale planning.