Move the AIX 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 AIX release controls the software preparation
| Current release or architecture | Next check |
|---|---|
| AIX 7.3 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| AIX 7.2 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| AIX 7.1 | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
| AIX 5.3 / 6.1 and earlier | Establish whether the destination can run this level, or whether OS preparation or a rebuild is needed first. |
Collect the AIX 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, processor mode and I/O | Record the exact machine, partition settings and the devices owned directly or supplied by VIOS. |
| AIX release, TL and SP | Keep oslevel -s with installed filesets, interim fixes and application certifications. |
| Root volume group and system backup | Record the rootvg layout, boot disks and a tested mksysb recovery method. |
| Application data volumes | Inventory separate volume groups, filesystems and database recovery requirements. |
| Clusters and business interfaces | Record PowerHA or other cluster levels, external endpoints and the owner of each acceptance test. |
| Licenses and software keys | Qualify processor-based entitlements, serial-bound software and any overlap period. |
Model, processor mode and I/O
Record the exact machine, partition settings and the devices owned directly or supplied by VIOS.
Physical adapter ownership and VIOS mappings can change the target AIX minimum. Record the current HMC and firmware levels before qualifying a live or restart-based move.
AIX release, TL and SP
Keep oslevel -s with installed filesets, interim fixes and application certifications.
A major release number does not identify the destination enablement. Include middleware and third-party drivers in the TL/SP review. An AIX OS migration installation belongs to the software-upgrade task even when it is combined with this hardware move.
Root volume group and system backup
Record the rootvg layout, boot disks and a tested mksysb recovery method.
mksysb protects the root volume group. Separate application volume groups and database consistency need their own recovery plan. Verify the destination can boot the restored AIX level and has the required device support.
Application data volumes
Inventory separate volume groups, filesystems and database recovery requirements.
Record the storage identifiers and filesystem mount points, then test the application-supported recovery sequence. A database backup or replication process must leave the target data consistent at the switch.
Clusters and business interfaces
Record PowerHA or other cluster levels, external endpoints and the owner of each acceptance test.
A cluster move changes more than one operating-system image. Plan the supported rolling or outage-based procedure, shared storage visibility and the acceptance tests that prove failover still works.
Licenses and software keys
Qualify processor-based entitlements, serial-bound software and any overlap period.
A different server or resource allocation can change software entitlement. Request the applicable keys before rehearsal and confirm the terms for keeping both environments available during the move.
Choose an AIX workload transfer method
| Method | What it covers and what to qualify |
|---|---|
| mksysb and NIM recovery | Recover rootvg to an eligible system; include device support and separate data-volume recovery. |
| Alternate-disk OS preparation | Prepare a qualified OS change while retaining a fallback rootvg; transfer to another server is a separate step. |
| Live partition mobility | Only an eligible PowerVM/VIOS, processor-mode, storage and software combination can move live. |
| Application or database migration | Use application-supported recovery or replication when an image move is unsuitable. |
AIX system restore: rootvg is only part of the workload
Use a tested mksysb and the supported NIM or installation/recovery method for the source and target. Confirm the AIX level can boot on the destination and that its device support matches the new I/O.
Recover separate application data volumes using their own consistent recovery method. Check boot configuration and application startup before estimating the outage.
Alternate-disk preparation: separate the OS step from the move
IBM documents NIM alternate-disk migration and related alternate-rootvg approaches for qualified OS changes. They can retain the original rootvg for fallback. The exact source release, NIM resources and target maintenance levels must qualify.
Preparing another rootvg does not move application data to a different server. Keep the hardware transfer and final data-consistency work in the migration plan.
Live AIX 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 AIX
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 AIX 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 AIX 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 AIX migration with Midland · Compare AIX 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.