AS400 to IBM Power 11 Partners
(888) 682-5335

Linux on Power upgrades by distribution and release

Which Linux release can your Power workload use?

Match RHEL, SLES or Ubuntu to your current Power model and application requirements. Compare a supported OS upgrade with a rebuild or replacement before scheduling the change.

Find my distribution and release Find my current model

Record the Linux distribution and the exact release

Keep /etc/os-release, uname -r and uname -m with the system inventory. Older distributions may use a vendor-specific release file. Use lscpu, where available, to confirm processor and byte order.

Record whether the workload runs in a PowerVM partition, a KVM guest or directly on the server. The supported distribution level can differ between those arrangements.

Linux release families: processor baselines are only the first check
Installed or desired releasePower planning question
RHEL 7 or olderIdentify big-endian versus little-endian packaging and qualify the supported upgrade sequence.
RHEL 8Eligible Power 8 configurations can run it; RHEL 9 needs Power 9 or later.
RHEL 9Requires Power 9 or later; RHEL 10 raises the processor baseline.
RHEL 10Requires Power 10 or later and the correct model/virtualization certification.
SLES 11 / 12Check release, service pack and byte order before selecting a later SLES target.
SLES 15Match the exact service pack to the server and its supported upgrade sources.
SLES 16SUSE supports Power 10 or later; Power 9 execution does not establish support.
Ubuntu LTSPower 8 stops at 20.04 LTS; newer LTS releases need a qualified newer processor.

RHEL 7 and earlier: establish the architecture first

An older release can use ppc64 big-endian or ppc64le little-endian packages. Keep that distinction with the installed minor release and repositories. A package upgrade does not convert the application’s byte order.

Red Hat documents staged major-release upgrades and limits Leapp to supported combinations. Do not assume RHEL 7 can jump directly to RHEL 9, or that an older Power CPU can run the later target.

Read Red Hat’s major-upgrade guidance.

RHEL 8: check the next release against the processor

RHEL 8 has eligible Power 8 deployments. RHEL 9 requires Power 9 or later, so a Power 8 owner cannot solve that requirement with an in-place package upgrade. Confirm the exact minor releases and model certification before choosing Leapp.

Keep third-party repositories and kernel modules in the assessment. An upgrade report can identify inhibitors that must be resolved before the production change.

Read Red Hat’s Power platform limits · Review the RHEL upgrade process

RHEL 9: Power 9 is a minimum, not a complete certification

RHEL 9’s Power baseline is little-endian Power 9. Model support and supported source/target minor releases still need checking. Application and SAP certifications can impose a narrower combination.

A move from RHEL 9 to RHEL 10 also changes the processor requirement. A Power 9 host does not meet the RHEL 10 minimum.

Read RHEL 9 architecture requirements.

RHEL 10: plan for Power 10 or later

Red Hat specifies little-endian Power 10 or later for RHEL 10. Use the certified server and virtualization arrangement with a supported installation or upgrade level. A Power 8 or Power 9 system therefore needs a hardware change for this target.

Confirm application binaries and database support before selecting RHEL 10 as the destination. Use a fresh-install/data-migration plan when the current environment cannot meet a supported in-place combination.

Read RHEL 10 architecture requirements.

SLES 11 and 12: keep service pack and byte order together

SLES 11 big-endian and later little-endian systems are different migration starting points. Record the installed service pack and application package architecture. SUSE does not support a big-endian-to-little-endian in-place upgrade.

Use a new qualified environment and an application/data transfer when the architecture changes. For same-architecture upgrades, use the target release’s supported source and service-pack combinations.

Read SUSE upgrade methods and architecture limits.

SLES 15: the service pack changes the upgrade question

The major number alone is insufficient. Record the exact SLES 15 service pack and whether the installation is SLES for SAP Applications. Check the target service pack’s prerequisites and the IBM model map.

For a SLES 16 goal, include the newer supported processor baseline in the hardware decision. Staying on an eligible SLES 15 combination and replacing the hardware are separate choices.

Read SLES 15 SP7 release notes · Review supported SLES service-pack upgrades

SLES 16: distinguish execution from vendor support

SUSE specifies Power 10 or later for supported SLES 16 deployments. Its release notes state that running on Power 9 does not establish support. Match the exact server and virtualization arrangement before choosing this target.

Review removed packages and application certification as part of the change. A compatible CPU does not establish a supported in-place upgrade from every older service pack.

Read the SLES 16 release notes.

Ubuntu LTS: sequence releases and respect the Power baseline

Canonical identifies Ubuntu 20.04 LTS as the last version for Power 8. Power 9 and Power 10 are supported from Ubuntu 22.04 LTS, and Power 11 support starts with eligible Ubuntu 24.04 LTS levels. Confirm the exact model and installation image.

For current installations on 22.04, 24.04 or 26.04 LTS, keep the point release and application support with the hardware check. Ubuntu’s normal LTS release-upgrade sequence moves to the next sequential LTS. A hardware generation jump does not let an in-place OS upgrade skip that sequence. A fresh installation with a workload transfer is a separate option.

Read Canonical’s Power support statement · Read Ubuntu release-upgrade guidance

Older Linux releases need a recovery and application inventory

Keep vendor installation media and a readable backup before changing old repositories or package levels. Identify third-party binaries and source availability. Establish a supported destination from the application and distribution requirements, then decide how the data can move.

ppc64, ppc64le and byte order change what can be copied

ppc64 commonly identifies a big-endian Power Linux environment; ppc64le identifies little-endian Power Linux. Confirm actual byte order with the system tools rather than inferring it from the machine age. Ubuntu uses the ppc64el package-architecture spelling.

Changing byte order can require rebuilding native applications and using a database-supported export/import or conversion method. A copied root filesystem is not an architecture conversion. Containers also need an image built for the destination architecture.

An x86 Linux binary is a different architecture again. If a workload includes x86-built components, confirm a Power build or plan application porting before moving it.

IBM Linux on Power application porting guidance · Plan the architecture change

Choose a supported in-place upgrade or a tested rebuild

Use the distribution’s supported upgrade tool and exact source/target combination when the hardware and architecture qualify. Otherwise prepare a fresh environment and move the application and data using a supported method.

In both cases, test a recoverable backup and the business application before scheduling the outage. Include repositories, drivers and subscription access in the scope.

Build the Linux migration plan · Discuss Linux release and hardware choices

Sources and release checks

Guidance checked October 21, 2026. Midland catalog identities stay with their exact model. Hardware eligibility, software maintenance and application certification need separate checks for the installed configuration.