What Power 9 End of Life Means for Your IBM i Applications
If your RPG, COBOL, or IBM i ERP applications run on Power 9 hardware headed toward end of life, here is the honest answer on what happens to the software, the OS, your licenses, and your ERP vendor relationship.
Jump to the exact AS400 software question you want answered.
The honest answer: your applications are built to survive this
If you're running RPG, COBOL, or IBM i ERP on Power 9 hardware and someone just told you it's going end of life, your first question probably isn't about the server. It's about your software. Will it still run? Do you have to rewrite anything? Here's the honest answer.
IBM i applications are famous for backward compatibility, and that reputation is earned. RPG and COBOL programs, Db2 for i databases, and the ERP systems built on top of them almost always move from one Power generation to the next without a single line of code changing. IBM has treated application continuity as a design principle since the AS/400 launch in 1988, and that commitment has carried through every hardware generation since, including the move from Power 9 to Power 10 and now Power 11.
That does not mean a Power 9 end of life notice is nothing to plan for. It means the planning conversation should center on the operating system release, the license entitlements tied to the old hardware, and vendor certification, not on whether your RPG programs are about to break. They are not.
- IBM i ... What the term covers, and why continuity matters more than trend-driven feature churn.
- RPG ... IBM's native IBM i language, still running most core transaction logic in production today.
- COBOL ... The other long-standing IBM i business language, often handling financial and transactional logic.
- Db2 for i ... The integrated database layer that moves with the partition during a hardware migration.
- EOSL (End of Service Life) ... The point IBM stops shipping patches and fixes, the real deadline behind a Power 9 end of life notice.
What IBM i OS version you actually need on Power 10 or Power 11
The part of this transition most likely to require real work is not your application code, it is your IBM i operating system release. Each new generation of Power hardware has a minimum supported IBM i release, and IBM periodically stops testing and shipping new Technology Refreshes for the oldest supported releases on the newest machines. If your Power 9 partition is still running an older IBM i release, moving to Power 10 or Power 11 hardware can mean an OS upgrade has to happen either before or during the hardware migration, not after.
This is the step buyers most often underestimate. An OS upgrade is a separate project from a hardware refresh, with its own testing checklist: custom exit programs, PTF levels, third-party software compatibility, and any job scheduling or security software that hooks directly into the operating system. Before committing to new hardware, confirm which IBM i release your applications currently run, which releases are supported on the target Power generation, and whether your current release is still inside its support window at all.
- IBM i Hardware Lifecycle Buyer's Guide ... Covers the hardware side of this same decision in more depth, including how to read IBM's withdrawal-from-marketing and end-of-service dates.
- IBM Power 11 Versus Power 10: The 2026 Buying Decision ... A closer look at how licensing, activated cores, and support horizon should factor into which Power generation you buy.
- LPAR (Logical Partition) ... A Power 9 to Power 10 or Power 11 migration is really a partition migration. See what moves with the LPAR and what has to be redefined.
License implications: why hardware end of life triggers a license conversation
IBM i software licensing is tied to the hardware it runs on, not to your organization in the abstract. The base operating system entitlement, and most third-party IBM i software, is priced against a processor group, sometimes called a P-group, that reflects the relative performance tier of the machine. P05, P10, P20, and higher tiers each carry a different license cost, and Power 10 and Power 11 systems map to their own processor group tables that do not simply mirror Power 9.
In practice, that means moving from Power 9 to Power 10 or Power 11 is rarely a clean, free transfer. Expect a conversation with IBM, and separately with every ISV whose software runs on the box, about re-issuing or repurchasing entitlements against the new processor group. Some vendors handle this as a straightforward re-key once the new machine's serial number is on file. Others treat it as a new purchase with trade-in credit for the old entitlement. Budget for this as part of the migration, not as a surprise line item after the hardware is already ordered.
- Get a full inventory of every IBM i software entitlement, IBM and third party, tied to the current Power 9 serial number
- Ask each vendor how they handle entitlement transfer to a new processor group, and what it costs
- Confirm whether your ERP or database tools license by processor group, by user count, or by a hybrid model, since the migration cost varies accordingly
- Modernization Preferred Partners ... Vetted partners for teams that want help scoping the hardware, OS, and license side of a Power 9 migration.
ERP and third-party software: verify certification, don't assume it
SAP S/4HANA, JD Edwards, and the custom or packaged IBM i ERP systems that run core operations are, generally, certified on current Power hardware. IBM and the major ERP vendors have strong incentive to keep that certification current, since IBM i's installed base skews heavily toward exactly this kind of long-lived, business-critical ERP workload.
"Generally certified" is not the same as "certified for your specific configuration." Before migrating, check your ERP vendor's supported platform matrix for the Power generation and IBM i release you are moving to, and do the same for any smaller third-party tools in the stack: EDI connectors, barcode and warehouse integrations, document management, job scheduling, and security or MFA software. Most of it moves cleanly. The exceptions tend to be older middleware, custom Java integrations pinned to a specific JVM version, or point-to-point interfaces someone built years ago and nobody has touched since.
- IBM i ERP Software Category ... Browse ERP and modernization paths for organizations running core operations on IBM i.
- Legacy IBM i ERP Platforms ... A glossary reference for what "legacy ERP" actually means in an IBM i context, and why continuity matters more than age.
- Database Replication, Mirroring, and Migration ... Tools for moving or mirroring Db2 for i data as part of a hardware and partition migration.
What actually breaks in a Power 9 to Power 10 or Power 11 migration
Very little, when the migration is planned properly. RPG and COBOL source does not need to be touched. Db2 for i databases move with the partition. The application logic your business depends on keeps running the way it always has.
What does occasionally break, or at least need attention, is narrower and more predictable than most teams expect: an IBM i release too old to be supported on the new hardware, a third-party integration pinned to a specific PTF level or Java runtime, hardware-specific device definitions for tape, terminals, or adapters that do not exist on the new box, and any script or job that references hardware resource names directly instead of through a logical device description. None of these are application rewrites. All of them are checklist items a competent migration plan catches before cutover, not after.
The real risk of staying on Power 9 too long
Nothing dramatic happens the day Power 9 hardware officially reaches end of life. Your applications keep running the next morning exactly as they did the day before. The risk is slower and more structural than that.
Once IBM stops actively testing new IBM i Technology Refreshes and PTFs against Power 9, new features and performance improvements simply stop arriving for that hardware. Eventually, security patches follow the same path, since IBM's testing and patching effort concentrates on currently supported hardware generations. For a business running regulated or audited workloads, an unsupported hardware and software combination can also become a compliance finding well before it becomes an actual outage. The honest planning horizon is not "how long will this keep running," it is "how long will this keep being patched and supported," and those two clocks stop at different times.
A natural moment to add AI capability without a rewrite
A hardware and OS refresh is also a convenient checkpoint to layer on newer capability without touching the applications underneath. Watsonx and similar platforms connect to IBM i through APIs, Db2 connectors, and secure data pipelines, adding natural language access and predictive analysis on top of RPG, COBOL, and ERP systems that keep running unchanged. That is a separate project from the migration itself, but it is worth putting on the roadmap while the hardware and licensing conversation is already open.
- AI for AS/400 Software: No Rewrite Required ... How watsonx layers onto existing RPG, COBOL, and ERP systems without modifying the underlying code.
Common questions about this Power 9 End of Life topic.
Will my RPG or COBOL applications run on Power 10 or Power 11?
Yes, in almost every case. RPG and COBOL applications, along with the Db2 for i databases underneath them, are designed for backward compatibility across Power generations. The far more common requirement is confirming your IBM i operating system release is supported on the new hardware, which may mean an OS upgrade alongside the hardware move.
Do I need to buy new IBM i software licenses when I move off Power 9?
You should expect a license conversation, even if it is not always a full repurchase. IBM i entitlements and most third-party IBM i software are tied to the processor group of the machine they run on. Moving to a Power 10 or Power 11 system, which maps to its own processor group tiers, typically requires IBM and your other software vendors to re-issue or reprice entitlements against the new hardware.
What IBM i version do I need for Power 10 or Power 11?
It depends on your current release and the specific machine type-model you are moving to. IBM sets a minimum supported IBM i release for each Power generation and periodically stops shipping Technology Refreshes for older releases on newer hardware. Confirm your current IBM i release, its support window, and the supported release list for your target hardware before finalizing a migration plan.
Are SAP, JD Edwards, and other IBM i ERP systems certified on Power 10 and Power 11?
Generally yes, since IBM i's installed base leans heavily on long-lived ERP workloads and vendors have strong incentive to keep certification current. But "generally certified" is not a substitute for checking your specific configuration against the vendor's supported platform matrix before migrating, especially for older customizations or middleware integrations.
Sources
All sections, listed like article footnotes.
- [1] The honest answer: your applications are built to survive this
- [2] What IBM i OS version you actually need on Power 10 or Power 11
- [3] License implications: why hardware end of life triggers a license conversation
- [4] ERP and third-party software: verify certification, don't assume it
- [5] What actually breaks in a Power 9 to Power 10 or Power 11 migration
- [6] The real risk of staying on Power 9 too long
- [7] A natural moment to add AI capability without a rewrite
- [8] Sources and Official References
Software catalog pages tied to this Power 9 End of Life topic.
IBM i Partition Reconfiguration
An Backup SnapShot add-on for reconfiguring target LPARs so copied IBM i partitions can support testing, training, pre-production, or similar secondary use cases.
IBM i Partition Management Central
An add-on for centrally managing multiple IBM i LPARs from a single controlling partition inside the Backup SnapShot continuity model.
Database Replication, Mirroring, and Migration
An replication and migration program for real-time synchronization between heterogeneous databases and platforms with one-way and two-way support.