Start with the OS you run today
HPE is a server brand, not an operating system. An HP-UX database, a Linux application and a Windows VM need different conversion work even when the cabinets carry the same logo.
| Current environment | Inventory first | Conversion focus |
|---|---|---|
| HP-UX on HPE Integrity or HP 9000 | Record 11i version, update and Itanium or PA-RISC architecture. | Qualify an AIX or Linux application build and a database transfer. |
| Solaris on Sun/Oracle or x86 systems | Record Solaris release, patch or SRU level and SPARC or x86 architecture. | Replace Solaris-specific services and qualify the application on its new OS. |
| Linux on HPE, Dell, Lenovo or other x86 servers | Record distribution, release, kernel and x86_64 packages. | Build a supported Power Linux environment and test its applications. |
| Windows Server on x86 systems | Record Windows version, application stack and database edition. | Separate portable application tiers from Windows-only dependencies. |
| VMware-hosted Windows or Linux guests | Inventory the OS and workload inside every guest. | Rebuild eligible workloads for Power; keep or replace x86-only guests. |
Then choose the workload
A single server may run a database, application services and scheduled integrations. Assess those parts together, then decide which can move and which need a different destination.
| Workload | What the guide resolves |
|---|---|
| Oracle Database and Oracle-backed applications | Qualify the database platform, application certification and transfer method together. |
| SAP applications and SAP HANA | Separate infrastructure migration, database change and an S/4HANA business conversion. |
| PostgreSQL, MySQL and SQL Server data | Distinguish same-engine data transfer from changing the database engine. |
| Custom applications, Java, .NET and containers | Check source code, runtime builds, native dependencies and target images. |
| Conversion assessment, rehearsal and cutover | Prove the target works and the business can recover before switching production. |
Conversion and Power upgrades are separate decisions
A Power upgrade starts with a workload already running on Power. This section starts with another processor architecture or OS and asks whether its software and data can be rebuilt for Power. A faster server does not make the source application compatible.
Power upgrades covers existing Power capacity and OS changes. Power workload migration covers existing IBM i, AIX and Power Linux moves. A non-IBM conversion may include an application upgrade, but it still needs its own compatibility and data tests.
Choose an outcome the business can support
| Possible outcome | When it fits |
|---|---|
| Rebuild the complete workload | The application, database and supporting tools have approved Power builds. |
| Move one tier and retain another | A portable service can move while a Windows or x86-only dependency stays elsewhere. |
| Convert or replace the application | The current software has no suitable Power build and the business approves a replacement. |
| Retain the workload on its current platform | Required support, functionality or recovery tests do not qualify the Power proposal. |
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.