Move the Linux workload you already run
Start with the actual source machine and the software it runs. Several processor generations may be skipped when the verified configuration allows it; that does not establish a direct OS upgrade or live move.
The source Linux release controls the software preparation
| Current release or architecture | Next check |
|---|---|
| RHEL 10 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| RHEL 9 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| RHEL 8 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| RHEL 7 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| SLES 16 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| SLES 15 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| SLES 11 / 12 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| Ubuntu LTS | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| ppc64, ppc64le and byte order | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
Collect the Linux source inventory
A system backup and a processor count do not describe the whole application. Keep the installed configuration and recovery method together so the equipment quote includes the work needed to move the business service.
| Inventory item | What to retain |
|---|---|
| Model, boot firmware and hypervisor | Record the exact machine and whether the workload uses PowerVM, KVM or a bare-metal installation. |
| Distribution, release and kernel | Keep the full distribution level with repositories, subscriptions and required kernel modules. |
| Architecture and application binaries | Record ppc64 or ppc64le, byte order and vendor builds; include container image architecture. |
| Application and database recovery | Record data locations, consistency requirements and the application-supported transfer method. |
| Storage, networking and accelerators | Record multipath, interface mappings and any GPU or accelerator driver/runtime dependencies. |
| Business tests and outage allowance | Name the test owner and measure recovery plus application checks in a rehearsal. |
Model, boot firmware and hypervisor
Record the exact machine and whether the workload uses PowerVM, KVM or a bare-metal installation.
An OPAL or KVM image cannot be assumed to boot as a PowerVM client. Qualify the destination firmware, virtual devices and installation method before choosing image-based recovery.
Distribution, release and kernel
Keep the full distribution level with repositories, subscriptions and required kernel modules.
A distribution upgrade tool supports defined combinations. Preserve third-party repository configuration and confirm packages exist for the target Power architecture. A kernel change can also require new storage or accelerator modules.
Architecture and application binaries
Record ppc64 or ppc64le, byte order and vendor builds; include container image architecture.
A ppc64 big-endian application may need a new ppc64le build and supported data conversion. A container image also has an architecture. Confirm the target image and database format rather than treating the root disk as portable.
Application and database recovery
Record data locations, consistency requirements and the application-supported transfer method.
Use a tested database backup/restore, replication or export/import method that matches the source and target versions. File copying alone does not establish consistency for a running database.
Storage, networking and accelerators
Record multipath, interface mappings and any GPU or accelerator driver/runtime dependencies.
Device names and network mappings can change on the destination. GPU and accelerator workloads need the supported driver, runtime and interconnect combination; a newer CPU does not replace those dependencies.
Business tests and outage allowance
Name the test owner and measure recovery plus application checks in a rehearsal.
Choose representative transactions with known results. Include scheduled work and external interfaces so a successful boot is followed by a meaningful business acceptance check.
Choose a Linux transfer method around compatibility
| Method | When to qualify it |
|---|---|
| Fresh install and application/data recovery | The architecture, distribution or device arrangement changes. |
| Image-based recovery | The source image, kernel, boot method and destination devices are compatible. |
| Application/database replication | The final outage must be shorter than the initial data transfer. |
| Live virtual-machine move | The complete hypervisor and source/target configuration supports it. |
Changing Linux architecture needs a workload conversion plan
A big-endian-to-little-endian change is not an ordinary package update. Confirm native application builds and database conversion requirements. Keep the original system recoverable while a separate target is built and tested.
PowerVM, KVM and bare-metal environments also have different boot and device expectations. Qualify a new installation when the image cannot be restored in a supported way.
Fresh installation and application/data recovery
Install a qualified Power distribution and the required application build. Restore the application configuration and data using supported methods. Recreate services and security settings deliberately, then run the agreed business tests.
Use the target distribution’s repositories and subscriptions. Revalidate any scripts or monitoring integrations that depended on older package names or system behavior.
Image-based recovery: prove the image can boot
Qualify the CPU baseline, byte order, kernel and boot firmware before restoring an OS image. Match the disk, network and multipath drivers to the destination. A successful backup job does not prove that the image can start the new system.
Live Linux moves need an exact configuration check
Check the supported hypervisor, processor compatibility mode and storage/virtual-I/O requirements for both systems. Firmware and management levels can add prerequisites. A live move does not install a newer OS release or convert application architecture.
Keep a restart-based transfer option in the plan until the complete configuration is qualified. Do not promise zero downtime from a shared Power processor name.
Application and database transfer for Linux
A logical backup/restore or supported replication method can separate the application from an old OS image. Establish which data and objects the method covers. Agree how changes are synchronized into a consistent final state.
Check database version, application certification and license requirements independently. Measure initial copy and final synchronization in the rehearsal.
Rehearse the Linux move with the business application
- Build or recover the destination using the qualified method.
- Inspect system and application recovery logs and resolve omissions.
- Run representative transactions and test external interfaces.
- Measure the final synchronization, restart and acceptance work.
Keep the rehearsal isolated from live business endpoints so copied systems cannot submit duplicate work. Use the results to set the outage window and the decision deadline.
Agree Linux cutover and rollback before production changes
Name the person who can accept the target and the deadline for returning to the source. Preserve the original recovery set and any alternate boot environment until the acceptance decision permits retirement.
After the target receives new transactions, restarting the source or selecting an old root disk does not merge those changes. Establish reconciliation or supported reverse synchronization before relying on rollback.
After go-live, verify backup and scheduled processing on the destination. Retire the old environment only after acceptance and retention requirements are met.
Discuss the Linux migration with Midland · Compare Linux upgrade choices · Return to all Power migration choices
Sources and release checks
Guidance checked October 21, 2026. Midland catalog identities stay with their exact model. Hardware eligibility, software maintenance and application certification need separate checks for the installed configuration.