Build the non-IBM source inventory
| Inventory item | Evidence to gather |
|---|---|
| Source OS and hardware | Server model, processor architecture, exact OS/update level and recovery media. |
| Applications and dependencies | Versions, source/installers, vendor support, runtimes, agents and interfaces. |
| Databases and data volumes | Engine/version, features, size, change rate and recovery requirements. |
| Measured workload and licenses | Peak demand, business deadlines, growth and the target entitlement review. |
| Availability and retained systems | Outage limits, recovery targets and all services that stay elsewhere. |
The OS and workload decide the conversion work
Record the actual architecture and release on each source system rather than using the cabinet brand. For example, a Windows/SQL Server guest and a Linux web guest on the same HPE host can have different outcomes. Identify the team responsible for each service and the connections between them.
Choose the current-OS guide and workload guide before requesting a destination model.
Approve a feasible target before the production purchase
- Obtain the exact supported application, database, OS and Power architecture combination from the responsible suppliers.
- Build a proof of concept with representative data and the dependencies the workload actually uses.
- Measure function, response time, batch deadlines and recovery against agreed acceptance criteria.
- Approve the complete move, a split deployment or a replacement application only after the evidence supports it. Retain the current platform if no acceptable Power outcome is established.
A proof of concept should expose uncertainty early. Record unsupported modules and required code changes instead of treating them as work the production migration will somehow resolve.
Size Power from measured work and qualified software
Gather peak and typical CPU demand, memory working set, I/O latency, throughput, database growth and business processing deadlines. Use the approved application’s sizing method where available, including SAP-specific sizing for SAP workloads. Compare performance on a representative target.
An x86 socket, core or VMware vCPU is not a fixed Power capacity unit. Review database and application license terms for the actual target configuration. Then use Midland’s Power model catalog and the AIX or Linux release guide to qualify server and OS choices.
Plan the connections when part of the workload stays elsewhere
A split design may keep Windows, SQL Server or an x86-only appliance while moving an eligible tier to Power. Define network latency, authentication, certificates, shared files and support ownership. Test the effects of either side being unavailable.
Include the retained systems in capacity, licensing, backup and recovery costs. Retiring the source hardware is a separate decision from moving one of its application services.
Design target availability and recovery explicitly
List the outage the business can accept and the data loss it can tolerate. Select qualified clustering, replication and backup methods for the new OS and application. Source hypervisor HA or a storage snapshot does not automatically provide those capabilities on the new target.
Restore the target from backup and test failure/restart behavior. Include DNS, identity, file services, external APIs and retained databases in the recovery sequence.
Define data checks the business can recognize
Reconcile object coverage, transaction totals, balances, dates, encodings and representative reports. Test jobs, procedures, permissions and interfaces in addition to row counts. Capture agreed checks before conversion so failures have a clear owner and acceptance rule.
For an engine change, compare application behavior under the new SQL dialect and transaction rules. A copied database file or matching data size does not prove business equivalence.
Rehearse conversion and recovery at useful scale
Repeat the proposed deployment and data-transfer procedure in a controlled environment. Time initial copy, conversion, synchronization, validation, application startup and user acceptance. Use realistic data volume and change rates when judging whether the outage fits.
Keep a runbook, named decision owners and the tested restore procedure. If the rehearsal fails its criteria, fix the cause and repeat it before scheduling production.
Control the final transaction handover
- Confirm recovery copies and readiness of the new application, database and external services.
- Stop or redirect source writes according to the rehearsed plan and capture the transaction boundary.
- Complete final synchronization and business validation before enabling destination writes.
- Release the destination to users, monitor agreed checks and retain the source under the approved recovery plan.
Do not run both systems as independent writable production copies unless the application’s approved design explicitly reconciles those writes.
Account for new destination transactions before reverting
Before the destination accepts writes, a failed acceptance test may allow a return to the unchanged source under the runbook. After new transactions arrive, returning to the old copy can lose or duplicate business activity.
Define how those transactions would be recovered, replayed or reconciled and who authorizes the decision. Reverting a VM snapshot or switching DNS alone does not solve post-cutover data recovery.
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.