Start with how the application is built
| Application type | What must be established |
|---|---|
| Packaged vendor application | A supported target release, OS, architecture and database combination. |
| Native C, C++ and compiled modules | Source, compiler/toolchain and all required target libraries. |
| Java, Python, PHP and other managed runtimes | A supported runtime plus compatible native dependencies and drivers. |
| Modern .NET services | A supported Power runtime and removal or retention of Windows-only dependencies. |
| Containerized applications | Power architecture images for the application and all supporting components. |
Get the supplier’s target combination in writing
Ask for the exact application edition and release supported on AIX or Power Linux, its database requirements and the migration procedure. A product being available for “Linux” does not establish a ppc64le build. Include agents, license services, reporting tools and third-party modules.
If no supported Power edition exists, assess retaining that component, replacing the application or funding a source-code port. A replacement needs a business decision about features and data conversion; it is not an automatic part of the server purchase.
Rebuild native code and test its platform assumptions
Collect source, build scripts, compiler versions and dependencies. Review assembly instructions, OS APIs, word sizes, byte-order assumptions and binary file formats. Build with a supported target toolchain and resolve missing libraries before load testing.
A successful compilation is an early checkpoint. Compare calculations, file exchange, error handling, multithreading and batch output with the production source. Preserve a reproducible build and a tested recovery copy.
Portable source can still depend on native software
Java bytecode or interpreted source may travel more easily than a compiled x86 application. The runtime, JNI libraries, Python wheels, PHP extensions and database drivers can still require platform-specific builds. Inventory them explicitly and test the complete service.
Check the vendor-supported runtime version, startup options, certificate stores and authentication. A language name alone does not certify the packaged application.
Modern .NET needs its own Power runtime decision
Qualify the selected runtime and Linux distribution together. Red Hat documents ppc64le among its .NET 8 architectures; use current support and maintenance information to select the production release. Check native NuGet dependencies and platform-specific APIs.
For .NET Framework or Windows-only services, use the Windows conversion assessment. A modern runtime does not automatically port classic ASP.NET, COM or other Windows dependencies.
Build and test the Power container image
A container packages software for an OS and architecture; it does not erase those requirements. Docker documents separate architecture variants in a multi-platform image. Confirm a linux/ppc64le variant for every required base image and component, or build and support one.
Check init containers, sidecars, proprietary agents and native plugins as well as the main service. Build-time emulation is not evidence of production vendor support or performance. Test on the intended Power configuration and orchestration platform.
Make the application proof of concept decide the next step
Run representative transactions against the intended database and external systems. Define acceptance for function, elapsed time, resource use, observability and recovery before the test. Record failures and unsupported components before estimating the full conversion.
Use the result to approve, narrow or stop 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.