Record the installed Linux distribution and release
Capture the OS release, kernel, package architecture and application versions on each source guest or server. HPE ProLiant, Dell and Lenovo x86 hardware can host similar Linux workloads, but the brand does not determine application portability.
| Current distribution | Record before choosing the Power release |
|---|---|
| Red Hat Enterprise Linux | Major/minor release, subscription, enabled repositories and SAP or other special edition. |
| SUSE Linux Enterprise Server | Major release, service pack, modules, extensions and SLES for SAP edition if used. |
| Ubuntu Server | LTS or interim release, package sources and support arrangement. |
| Other distributions or unmaintained releases | Exact distribution and dependency list; decide whether a supported rebuild is acceptable. |
RHEL source and Power target releases are separate checks
An x86 RHEL application may have a ppc64le build, an x86-only build or no vendor-supported Power edition. Check the actual application release and its repositories. Use the Power Linux release guidance to qualify the target model and OS; the source minor release does not establish target eligibility.
SLES service packs and extensions belong in the inventory
Record the service pack and all required modules, including SAP-specific components when present. Verify that drivers, database clients and management agents are available for the chosen Power release. A matching SLES name is only the beginning of that check.
Ubuntu packages need matching architecture support
Check the selected Ubuntu release against the target model and required packages. A third-party repository that serves amd64 may not provide ppc64el packages. Vendor support for the application can be narrower than the base distribution’s hardware support.
Other Linux sources may require a distribution change
For community rebuilds, old releases or a vendor appliance, identify who owns support for the complete target. Replacing the distribution, application version and architecture together needs a tested compatibility plan. A vendor appliance should use its supplier’s approved migration method.
Check the application and data separately
| Workload component | What changes |
|---|---|
| Compiled applications and native modules | Use Power builds or rebuild from source; x86 executables are not Power executables. |
| Java, Python, PHP and modern .NET | Qualify the runtime and every native dependency. |
| Container images | Provide and test the target Power image variant. |
| PostgreSQL and MySQL data | Select a supported transfer procedure and qualify target extensions/plugins. |
| SAP HANA | Use SAP-specific platform, revision and certified-configuration checks. |
| SQL Server on Linux | Microsoft’s Linux edition remains x64; choose retained x86 or an approved engine conversion. |
Build a new Power Linux installation and measure it
Install the selected supported distribution, deploy the qualified application and transfer its data through the chosen procedure. Keep the source recoverable while you test production-like load, backup, restore and external services.
Size the Power partition from measured CPU, memory and I/O demand plus required growth. Source x86 core count alone is not an equivalent Power configuration. Prepare the sizing evidence before requesting the server quote.
Plan the Power destination with Midland
Use the assessment to decide which workload belongs on Power before comparing hardware. Midland’s Power model catalog supplies the server identities; software eligibility and measured workload demand decide the configuration.
Prepare the conversion inventory and Bring your current OS, application and database versions to Midland.
Sources and release checks
Technical guidance checked October 21, 2026. Confirm the exact application edition, OS release and target architecture with its vendor before ordering. Older technical papers explain migration methods; they do not establish current certification.