Inventory the workload inside each VMware guest
A VMware cluster is a hosting environment, not one application. List every VM’s OS and release, database, application owner, data volumes, backup method and connections. Include templates, powered-off guests needed for recovery and services outside the cluster.
| Guest workload | Assessment guide |
|---|---|
| Linux application guest | Check the distribution and availability of Power application builds. |
| Windows application guest | Separate portable services from Windows-only components. |
| SAP HANA database guest | Qualify the HANA revision, Linux combination and Power configuration. |
| Oracle database guest | Choose a certified target platform and documented data-transfer method. |
| Vendor appliance or x86-only guest | Ask the supplier for a supported Power edition or retain another qualified platform. |
A virtual disk transfer does not convert the application
An x86 guest expects x86 instructions and its source virtual devices. Exporting an appliance or copying a VMDK does not create a Power boot environment. Plan a supported OS installation and application deployment on the target, then transfer application data through a qualified method.
PowerVM and other Power virtualization choices have their own supported OS and model requirements. Confirm the Power Linux release and virtualization combination or AIX target requirements after qualifying the software.
Treat packaged appliances as vendor products
A firewall, backup, monitoring or application appliance may bundle an x86-only OS and locked software. Obtain the supplier’s explicit target options rather than unpacking the appliance and assuming a port. Retain it on an approved platform or select a supported replacement if no Power edition exists.
Recreate VMware-dependent operations for the new workload
| Existing capability | What the conversion must prove |
|---|---|
| Backup and restore | Recover the new OS, application and data; a source VM snapshot is not the target backup plan. |
| High availability and restart automation | Replace required service behavior with qualified target mechanisms. |
| Networking, addresses and external services | Test load balancers, names, certificates and retained x86 dependencies. |
| Capacity and licensing | Use measured demand and target software terms instead of a vCPU-to-core ratio. |
Migrate application groups instead of isolated VM files
Schedule tightly connected application and database tiers together or test the temporary split. Define the system that owns writes during each stage. Rehearse business transactions and restore recovery before retiring source guests.
After an eligible workload is operating on Power, later Power capacity and OS changes belong in Upgrades. The initial x86 conversion remains part of Migration.
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.