IBM i 7.4 out of support on 30 September 2026: who does what

On 30 September 2026 IBM changes the service level of IBM i 7.4. From that day the release no longer receives fixes under ordinary maintenance: it keeps running, it keeps carrying production, and it stops receiving security fixes unless you pay for a separate contract.

The question we get asked most often is whether the system will stop. It will not. On 1 October the ERP starts up like every other day. The right question is a different one, and it is less about IT than it sounds: how long can you keep a system that runs orders, warehouse and invoicing in production when it no longer receives security patches? In 2026, with NIS2 working its way into supply contracts, that is a compliance question before it is a technical one.

This article lays out the verifiable facts: the dates, the compatibility matrix between release and hardware, and the three possible paths with their costs. None of the three is “migrate everything now”.

TL;DR

• 30 September 2026: IBM i 7.4 leaves standard support. The release had already been withdrawn from marketing on 30 April 2026.
• The system does not stop working. It stops receiving security PTFs under the ordinary regime. A paid extension contract is available which, according to IBM partner communications, runs to 30 September 2029, at a cost that is a multiple of standard maintenance.
• The matrix governs everything else: IBM i 7.5 runs on Power9, Power10 and Power11. IBM i 7.6 runs only on Power10 (minimum firmware FW1060) and Power11. Anyone on Power8 has 7.4 as their last possible release: upgrading the operating system means changing hardware.
• Anyone on Power9 has a double problem that is less visible: they can move to 7.5, but their machine left standard hardware support on 31 January 2026. The OS upgrades, the iron underneath does not.
• IBM i 7.5 and 7.6 have no announced end date, and IBM commits to at least 12 months of notice. Getting to 7.5 buys real time, not a six-month reprieve.
• A clean release upgrade, with assessment, testing and a cutover window, takes 90 to 180 days for a mid-size installation. Starting today gets you there before 30 September only in a simple scenario. For everyone else the real deadline has already passed, and the choice is between a paid extension and running exposed.

What “end of standard support” actually means

IBM has stopped using the phrase end of support for these transitions and speaks of a change in service level. That is not cosmetic: it describes what happens more accurately.

From 30 September 2026 on IBM i 7.4:

• No new PTFs, including security ones. Fixes already published remain downloadable, new ones do not arrive.
• No new Technology Refresh. 7.4 stops at the functionality it has today.
• Technical support only inside an extension contract, paid for and separate from ordinary software maintenance.
• Application software is untouched. Your RPG business system keeps running exactly as it does now.

The difference between “end of support” and “end of life” matters because it sets the urgency. There is no date on which the machine switches off. There is a date beyond which every vulnerability discovered in the operating system stays open on your system indefinitely, unless you pay.

Why this is a compliance topic in 2026

A few years ago an unpatched AS/400 was an internal risk decision. Now it is a decision someone else evaluates on your behalf.

NIS2 and the Italian decree implementing it (Legislative Decree 138/2024) require covered entities to have vulnerability management and update measures, and extend that requirement to the supply chain. If you supply an essential or important entity, the questionnaire that lands on your desk contains a question about how you patch the systems that handle the customer’s data. “The system has been out of support since 2026 and receives no fixes” is an answer you can give once, with a plan attached. Not two years running.

The same mechanism applies to certifications your customers hold and you do not: an ISO 27001 audit at a customer reaches the systems of suppliers inside the perimeter. We covered this in detail in NIS2 for Italian software houses, and the mechanism is identical when the system in question is an IBM i.

The matrix: which release you can install on your machine

This is the part that decides everything, and in the Italian installed base it is the least known. IBM i does not upgrade freely: every release has a minimum processor generation requirement.

The two rows that matter are the bold ones.

IBM i 7.5 is not supported on Power8. Anyone with a Power8 machine has reached the end of the road on the software side: no release upgrade is possible without replacing the server.

IBM i 7.6 is not supported on Power9 or any earlier generation. Anyone on Power9 can get to 7.5, which is supported and has no announced end date, but no further.

And here comes the piece almost nobody factors in: Power9 scale-out servers left standard hardware support on 31 January 2026, seven months before the software deadline we are discussing. Anyone on a Power9 who upgrades to 7.5 ends up with a supported operating system and an unsupported machine, which means no preventive maintenance, no machine code updates and no guarantee on spare parts unless there is an extension contract.

The three real situations, and what to do in each

In the Italian installed base we see, three configurations cover almost every case.

You are on Power10 or Power11 with IBM i 7.4

This is the fortunate situation, and it is more common than people think: many companies changed hardware in the past three years without touching the release, because an OS upgrade requires a downtime window and the iron does not.

What to do: a release upgrade to 7.5 or straight to 7.6. This is a technical project, not a transformation project: no code rewriting, no change in application logic. The things that break are almost always the same three: programs using deprecated interfaces, external integrations tied to version-specific libraries, and scheduled jobs that depend on undocumented behaviour.

Realistic timing: 60 to 120 days across assessment, testing on a separate partition, fixing whatever emerges, and the cutover window. With an existing test environment you land at the low end.

Cost: the cheapest of the three cases, and still a project. The dominant line item is testing time, not licensing.

You are on Power9

What to do: the technical path is 7.5, and it is fine. But the real decision is not about software: it is about hardware, which has been out of standard support since January 2026.

The two options are buying the hardware maintenance extension and staying on 7.5 for a few years, or combining the hardware change and the release change into a single project and landing on Power10 with 7.6. The second costs more in one go and closes the question for a full cycle. The first pushes the spend forward and has to be done again.

The criterion we use: if the company’s business plan involves keeping the current system beyond 2029, combining almost always wins. If instead a system replacement project is already planned for the next 24 to 36 months, spending on new hardware for a system that is on its way out is money that does not come back: take the extension and keep the budget for the real project.

You are on Power8

This is the situation that demands a decision, and the 30 September deadline highlights it rather than creating it.

On the software side the road ends: 7.4 is the last installable release. On the hardware side, Power8 has been out of support for years. The options are three and worth facing directly:

1. Extension contract on 7.4 and a frozen system. High recurring cost, no new functionality, and an end date anyway: according to IBM partner communications the extension runs to 30 September 2029. It makes sense as a declared 12 to 24 month bridge towards something, not as a strategy.
2. Hardware change to Power10 and a jump to 7.5 or 7.6. This puts the system back into a supported cycle without touching the applications. It is the path that keeps a working AS/400 alive when the company has no reason to abandon it.
3. Application modernization, that is, tackling the problem upstream rather than downstream. It is the longest path, and it gets decided on the cost of maintaining the skills and on the flexibility the business needs over the next decade.

What does not work is the undeclared fourth option, staying on 7.4 without an extension and hoping nothing happens. It works until a customer questionnaire arrives, or an audit, or a vulnerability that makes the news.

What doing nothing costs

This is the question always missing from proposals, and the only one that makes the comparison decisive.

The cost of delay is not zero and it is not even constant: it grows.

Year 1: the extension contract, a multiple of ordinary software maintenance. A new budget line that did not exist before.

Year 2: the same line, plus the rising cost of finding skills. The market of people who can administer IBM i is not expanding, and the age bracket of those who have done it for twenty years is the one approaching retirement. The hourly rate for specialist work on an unsupported release is already higher than on a supported one, for the plain reason that fewer people will touch it.

Year 3: opportunity cost is added. Every new integration (a customer portal, an EDI flow, an agent that reads ERP data) on an unsupported system takes more work, because functionality that is native in recent releases is missing and because no third-party vendor guarantees compatibility with a release IBM no longer supports.

The cost that never amortises: the day a known and unfixable vulnerability becomes the reason you lose a tender or exit a supply relationship. It is not a cost you can budget, and it is the one that decides.

What has not changed, and needs saying

There is a lot of commercial messaging using this deadline to sell full migrations. It is worth putting in writing what 30 September 2026 does not mean.

It does not mean the AS/400 is a dead technology. IBM released 7.6 in 2025 and Power11 in 2025, and continues to invest in the platform. A new release and a new processor generation are not the signals of a product on its way out.

It does not mean you have to abandon RPG. Application code is untouched by a release change. Anyone presenting a rewrite as a necessary consequence of the support change is joining two conversations that have no technical relationship.

It does not mean you have to go to cloud. Moving an IBM i onto third-party infrastructure is a cost model decision with its own trade-offs, and it deserves evaluation on its own terms. One piece of hygiene: plenty of material in circulation still cites Skytap as an option on Azure. Skytap was acquired by Kyndryl and the service now has a different name, so treat material that does not know this with suspicion, because it is probably not current on anything else either.

It does not mean you must decide by September. You must decide by September only if the goal is to avoid paying for the extension. If the budget for the extension exists, the real deadline becomes your plan, not IBM’s.

Mistakes we see at this stage

1. Discovering the hardware matrix mid-project. The most expensive and most frequent error. An upgrade to 7.6 gets under way and two months in someone discovers the machine is a Power9 and does not support it. Checking the processor generation and firmware level is the first thing to do, before any planning, and it takes ten minutes.

2. Confusing the software deadline with the hardware one. They are two different contracts, with two different dates and potentially two different service providers. Many companies on Power9 are looking at September 2026 without noticing that the iron has been uncovered since January.

3. Upgrading the release without a test environment. On a system that carries invoicing, a cutover without a rehearsal is a risk you cannot justify to save a test partition. If the machine has no capacity for a separate partition, that is already an answer to the question “do we need new hardware”.

4. Not inventorying the integrations. The operating system almost always upgrades fine. What breaks is at the edges: third-party software attached to the system, backup tooling, print drivers, connectors into the document management system. Inventorying integrations is the part of the assessment people tend to skip and it is the part that generates the surprises.

5. Treating it as an IT decision. The choice between paid extension, hardware change and modernization depends on the company’s five-year business plan, not on the technical preference of whoever administers the system. Where the decision stays inside IT, the option chosen is almost always the one that minimises immediate friction, which is rarely the one that minimises total cost.

FAQ

Does my AS/400 stop working on 30 September 2026?

No. There is no shutdown mechanism and no expiring licence. The system keeps running exactly as before. What changes is that IBM stops publishing fixes for that release under the ordinary regime, security fixes included.

How much does the support extension cost?

IBM does not publish a price list, and the figure depends on configuration and existing contract. The order of magnitude circulating in the technical community is a substantial multiple of standard software maintenance. The real figure for your case comes only from your IBM reseller, and it is worth asking now rather than in September, because it is the number that makes the three options comparable.

Can I jump straight from 7.4 to 7.6?

That depends on hardware, not on the starting release. On Power10 with adequate firmware, or on Power11, yes. On Power9, no: the path is 7.5. On Power8, you cannot go to either 7.5 or 7.6 without changing the machine.

How long does a release upgrade take?

For a mid-size installation with a mature application environment, 90 to 180 days from the start of the assessment to production. The typical split is a third analysis and integration inventory, a third testing and fixing, a third preparation and cutover window. Anyone with an existing test partition and documented integrations lands at the low end. Anyone with neither lands at the high end, and the reason is that the time goes into reconstructing what is attached to the system.

What if we are thinking of replacing the ERP anyway?

Then the paid extension is almost always the right bridge, and September becomes a budget detail rather than an event. Replacing an ERP on AS/400 takes years, not months: we put the numbers for each strategy in the article on how long an AS/400 migration takes. Spending on new hardware for a system that will be gone within 24 months is the decision people later regret.

Does the RPG code have to be rewritten?

No, not for this. An OS release change does not require application code changes, except in the limited case of programs using deprecated interfaces. If someone ties a code rewrite to the support deadline, they are combining two projects that have no technical relationship, and the second costs one or two orders of magnitude more than the first.

How do I find out which Power generation I have?

The machine model tells you, and it is on the label or in the system information. If in doubt your reseller knows, and it is the first piece of information to retrieve: without it, any reasoning about what to do is guesswork.

What to do in the next six weeks

30 September 2026 is not a dramatic deadline and it is a real one. It stops no system, but it closes a door: from that day an IBM i 7.4 without an extension contract is a system that no longer receives security fixes, inside a regulatory context that has stopped treating that as an internal detail.

The useful thing to do in these six weeks is much smaller than the future of the information system: find the Power generation of the machine, ask the reseller for the extension cost, and inventory what is attached to the system. With those three pieces of information the decision takes one meeting. Without them, it gets postponed another year, which is what has happened for the last three.

If you have an IBM i in production and want to work out which of the three situations you are in, let’s talk. Half a day of assessment produces the matrix for your case and the cost of the three paths, and commits you to nothing.

For more: the AS/400 migration guide for the five strategies available when the decision is to modernize, the AS/400 cloud migration page, and the legacy systems modernization pillar.

Sources: IBM documentation on planning an upgrade to IBM i 7.6 and to IBM i 7.5 for hardware requirements, and IT Jungle for the announcement of the 7.4 withdrawal. Dates verified as of 15 August 2026: these are product communications, so it is worth re-checking them before committing spend.