Record Solaris release, updates and architecture
| Current environment | Record before assessing Power |
|---|---|
| Solaris 10 | Update and patch level, SPARC or x86, zones and application/database builds. |
| Solaris 11 | Exact release and Support Repository Update, CPU architecture and package inventory. |
| Solaris zones and SPARC logical domains | Guest boundaries, shared resources, application owners and recovery dependencies. |
Solaris 10 applications need their own target builds
List the application release and supplier before choosing AIX or Linux. Identify compiled libraries, shell assumptions, cron jobs and database clients. Retain recoverable source software and license records while the new build is tested.
For an application available only as a Solaris binary, a vendor replacement build or a source-code conversion is a prerequisite. An archive of the original executable does not solve target compatibility.
Solaris 11 features need replacement designs
Record the installed SRU rather than only “Solaris 11.” Oracle documents both SPARC and x86 platforms for Solaris 11.4; those architectures require separate identification in the conversion inventory.
Identify ZFS layouts and snapshots, SMF services, privileges, naming services and network settings used by the workload. The target needs tested equivalents for the behavior the application relies on. A filesystem snapshot is not a cross-platform database conversion.
Treat zones and logical domains as workload inventories
A zone boundary can hide a shared database, filesystem, address or scheduler. Map those connections before dividing the move into batches. Plan a new supported OS installation on Power; do not treat a zone image or SPARC virtual disk as a Power boot image.
Choose the Solaris workload
| Workload | Conversion focus |
|---|---|
| Oracle Database on SPARC or x86 | Record the exact Oracle source platform; processor architecture changes the byte-order question. |
| SAP application or database tier | Qualify the complete SAP and database combination before a system copy. |
| Native applications and shared libraries | Rebuild for AIX or Power Linux and test platform-specific assumptions. |
| Java and web services | Check runtime support and replace native or Solaris-specific dependencies. |
Test what the Solaris workload actually does
Test identity mapping, file permissions, scheduled jobs, message queues, database clients and backup recovery alongside the application screens. Reconcile financial or operational outputs with the source system. Use measured demand and the approved target OS to select a Midland Power model.
Rehearse the conversion and recovery with the teams that own upstream and downstream systems.
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.