The IBM i source inventory that makes the quote useful
Begin with the system you actually run. A catalog maximum describes what a model could support, while the installed inventory shows the resources and software your applications depend on.
| Inventory item | What belongs in the plan |
|---|---|
| Machine type, model and processor feature | Record the complete identity and serial number; include activated cores and the IBM i allocation. |
| IBM i release and fixes | Record each partition’s release, technology refresh and PTF groups, plus console access. |
| Applications and program objects | List business software and custom programs; identify source availability and the vendor-supported target release. |
| Data and restore size | Record used storage, database and integrated-file-system content, plus measured save/restore times. |
| Storage, adapters and virtual I/O | Record internal disks, SAN LUNs, tape, console and VIOS mappings. Qualify what can be reused. |
| Software entitlements and keys | Identify IBM and third-party entitlements, software maintenance and serial-number-bound keys. |
| Business connections | Record interfaces, scheduled jobs, printers and external endpoints with an owner for each test. |
| Allowed outage and recovery decision | Agree the permitted downtime, business acceptance owner and the point at which rollback is still safe. |
Machine type, model and processor feature
Record the complete identity and serial number; include activated cores and the IBM i allocation.
The processor feature matters when configurations of the same model have different IBM i limits or software tiers. Keep the source identity separate from the proposed destination quote.
IBM i release and fixes
Record each partition’s release, technology refresh and PTF groups, plus console access.
Use DSPSFWRSC, DSPPTF and WRKPTFGRP to collect software information. A successful login does not demonstrate that an OS upgrade has its required fixes.
Applications and program objects
List business software and custom programs; identify source availability and the vendor-supported target release.
Include licensed software, Java dependencies and external services alongside RPG and COBOL applications. Moving native IBM i programs does not inherently mean rewriting them; release changes and unavailable vendor builds still need testing.
Data and restore size
Record used storage, database and integrated-file-system content, plus measured save/restore times.
A transfer estimate must include the complete recovery set and changed data during the final switch. A fast network does not remove the time needed to restore objects, validate the application and release the system to users.
Storage, adapters and virtual I/O
Record internal disks, SAN LUNs, tape, console and VIOS mappings. Qualify what can be reused.
Old adapters and tape drives may not be supported on the new system. Confirm a readable save medium and the boot/console arrangement before relying on existing recovery equipment.
Software entitlements and keys
Identify IBM and third-party entitlements, software maintenance and serial-number-bound keys.
Rehosting software can change the serial number, processor tier and licensed core allocation. Request replacement keys and confirm any overlap period before the rehearsal. A formal model conversion can have different terms.
Business connections
Record interfaces, scheduled jobs, printers and external endpoints with an owner for each test.
A green system status does not prove the business process works. Give the application owner a test covering an ordinary order or transaction through its downstream interfaces.
Allowed outage and recovery decision
Agree the permitted downtime, business acceptance owner and the point at which rollback is still safe.
Measure the final save, transfer, restore and acceptance work in a rehearsal. Set a go/no-go deadline early enough to recover the agreed service if the migration must stop.
Sequence the IBM i release and hardware changes
Compare the installed release with both machines’ release mappings. If both can run the same release at the needed code levels, evaluate moving first and upgrading the OS later. If the releases do not overlap, establish the documented upgrade or recovery sequence before ordering the destination.
Check direct OS upgrade sources and IBM’s previous-release recovery documentation.
For example, Power 8 can run 7.4 but not 7.5. Selected Power 11 models can run 7.4 with their required fixes. That gives the assessment a possible common-release option; it does not establish adapter reuse, software transfer rights or live mobility.
Size and license the IBM i destination
Compare the application’s busy periods with the IBM i processor allocation. Review memory and storage response separately so the replacement addresses the bottleneck. Keep space for the rehearsal and any parallel production period in the equipment plan.
Select an IBM i migration method around the outage
The method must fit the actual source release and destination configuration. A product name alone does not establish that every object or storage arrangement is covered.
Save and restore: measure the full recovery
Use a complete, readable recovery set and the procedure for the source and target releases. Include system and user information required by that procedure. Rehearse the restore on the destination and inspect the restore logs before estimating downtime.
Tape, virtual tape and virtual optical approaches have different attachment and boot requirements. Compare Midland tape options with the target’s supported recovery devices.
Replication-assisted migration: copy first and switch later
Replication can move the initial data while production continues, then reduce the amount left for the final outage. The assessment must establish which objects are covered and how the final changes become consistent.
IBM i Migrate While Active has its own release, fix, storage and entitlement requirements. Other high-availability tools have vendor-specific coverage. Neither choice is a general promise of zero downtime.
Live partition mobility: qualify the whole configuration
Live partition mobility moves an eligible running partition between compatible systems. IBM i requires a supported virtual-I/O arrangement; source and target processor compatibility, shared storage and software levels must also qualify. It does not install a newer IBM i release.
Do not treat live mobility as the default way to jump several hardware generations. Keep it separate from a save/restore migration until the full prerequisite review passes.
Review IBM i virtualization capabilities and qualifications.
Staged legacy migration: make each step recoverable
An older OS may require intermediate software releases or another system that can run a needed release. Plan the hardware and licensed software for each stage. Preserve recovery media and confirm program-conversion requirements before changing the original environment.
Midland describes experience with multistep OS upgrades and migrations involving multiple physical systems. Scope that work from the installed configuration; it is not a blanket direct-migration promise.
Build the migration scope with Midland
Send the source model and release with a short description of the business change. We can use that starting point to discuss the destination configuration and the migration work that belongs in the quote.
Discuss the IBM i migration scope · Prepare the rehearsal and cutover · Return to IBM i migration
Sources and compatibility checks
Technical guidance checked October 21, 2026. A hardware release mapping describes which releases can run; support coverage and software entitlement are separate checks.