Every year or two, someone in a budget meeting asks whether IBM i is end of life. Usually they've just read a headline about a support date, or a vendor has told them the platform is on its way out.
The short answer is no. IBM released IBM i 7.6 in April 2025 and hasn't announced an end date for it or for 7.5. What did end, on 30 September 2026, was standard support for IBM i 7.4. If that's the release you run, you have a decision to make. It's a much smaller decision than "replace the platform," and it's worth separating the two before anyone starts pricing a migration.
- IBM i is not end of life. IBM released version 7.6 in April 2025 and hasn't set an end date for 7.5 or 7.6.
- IBM i 7.4 left standard support on 30 September 2026. A paid Service Extension runs from 1 October 2026 to 30 September 2029.
- For most 7.4 shops the choice is upgrade, pay for time, or plan a move, and the first two are usually enough.
- The bigger risk is the RPG code: what it does, and how many people still understand it.
The dates, from IBM's own lifecycle page
These come from IBM's release life cycle page, checked on 7 October 2026. Third-party summaries get these wrong often enough that it's worth reading IBM's page yourself.
- IBM i 7.6: generally available 18 April 2025. No end date announced.
- IBM i 7.5: generally available 10 May 2022. No end date announced.
- IBM i 7.4: generally available 21 June 2019. Standard support ended 30 September 2026. IBM's paid Service Extension runs from 1 October 2026 to 30 September 2029.
- IBM i 7.3: generally available 15 April 2016. Past standard support, with a paid Service Extension listed through 30 September 2028.
- IBM i 7.2: generally available 2 May 2014. Its Service Extension ended 30 April 2026.
For 7.5 and 7.6, IBM says it will give at least 12 months' notice before changing the service level. So nobody on those releases is facing a surprise this year.
What the 7.4 date means in practice
Nothing switches off. Your system kept running on 1 October exactly as it did the day before.
What changed is the support behind it. Under standard support, IBM ships fixes for the release. After the end date, you get that kind of cover only by paying for the Service Extension. Ask IBM or your business partner exactly what the extension includes and what it costs for your configuration, because that's the number your decision turns on.
The date also starts showing up in places outside IT. Auditors ask about unsupported software. Customers send vendor-risk questionnaires that ask the same thing. Some regulators now ask for it directly: New York's DFS cybersecurity rule requires covered firms to track the support expiration date of every asset. We cover that in more detail in the risks of running end-of-life software.
Your options if you run 7.4
Upgrade to 7.5 or 7.6. For most shops this is the cleanest path, and it keeps you on a release with no announced end date. Check two things first. One is whether your hardware supports the release you want, because an operating system upgrade can quietly turn into a hardware purchase. The other is whether every third-party product you run is supported on the new release.
Pay for the Service Extension and plan. This buys you until 30 September 2029. It's a reasonable choice if an upgrade can't happen this year. Just treat the three years as time to plan, and don't let them turn into three more years of not deciding.
Plan a move off the platform. Sometimes that's the right call. It's also the most expensive and the riskiest of the three, and you can't scope it honestly without knowing what your RPG code actually does. If a migration is on the table, read what to find out before you rewrite a legacy system first.
The harder problem is usually the code, and the people
An OS upgrade keeps IBM supporting the platform. It does nothing about the application on top of it.
In a lot of IBM i shops, that application is decades of RPG and CL code. It holds business rules nobody has written down anywhere else: pricing exceptions, eligibility checks, the month-end logic finance depends on. Some of it is in old fixed-format RPG that newer developers find hard to read. Often the people who understand it best are also the ones closest to retirement.
That's the risk worth planning around. The release date has a known answer. The question of what your code does, and who will understand it in five years, doesn't, until somebody reads it. If one person holds most of that knowledge today, start capturing it now, whatever you decide about the release.
Where the 30-day assessment fits
Whether you upgrade, extend or move, you'll decide better if you know what's in the codebase. The 30-day assessment gives you that. It's fixed in scope, at a price agreed before we start. Over 30 days we go through your RPG and CL code and the architecture around it, map how the programs, files and integrations fit together, find the hidden architectural debt, and flag the security and compliance gaps.
The report says in plain language what is broken and what it would take to fix it. Your team can act on it. If you'd rather we do the modernization work, that's a separate project with its own scope and price.