IBM i is not an obsolete system: the objections one by one

Whoever proposes replacing an IBM i rarely brings an analysis. They bring an impression: the screen is green, the language is called RPG, and the machine was called an AS/400 when the person proposing it was in primary school. From there they conclude the system is old, and from its being old they conclude it should be replaced.

Those are two leaps of logic, and neither holds. But nor do the answers usually offered by the platform's defenders, because they are articles of faith: "it is rock solid", "it never goes down", "nobody who knows it leaves it". A finance director is right not to be convinced.

This article takes the objections one at a time, says what is true in each, and arrives at the question that matters: not whether the platform is old, but which workloads it is still the best choice for. And which it is not.

"It is an old system"

The name is old. The system is not.

The latest release is from 2025 and requires Power9 processors or later: anyone installing it is putting last year's operating system into production on recent hardware. Between major releases come two technology refreshes a year, adding function to the system, the database and the compilers. The RPG written today has completely free-form syntax, procedures, qualified structures and pointers: it resembles the column-based code of 1990 no more than today's C# resembles the C of that era.

What confuses people is that the interface can still be the same. A 5250 session works as it did thirty years ago, and it is seen every day, while the architecture underneath is seen by nobody. It is like judging a car by its dashboard.

The right question is not "how old is it" but "is it receiving investment". That answer is verifiable in ten minutes, and the end of this article says how.

"Nobody uses it any more"

This is the weakest objection, because it is checkable. A system nobody uses does not get a new release that forces a hardware change — that decision is only taken for an installed base that genuinely upgrades. It does not have a catalogue of business software still on sale and under maintenance. It does not have companies building their own product on top of it.

The opposite of what you hear from the other side is also true, though: it is not as widespread as it once was. It is a niche platform, concentrated in particular sectors — manufacturing, distribution, insurance, small and mid-sized banks — and in companies with a core business system that has been stable for decades. Anyone choosing it from scratch today is rare. Anyone who has it and keeps it is nearly always right, and that is the case the rest of this article is about.

"You cannot find people"

This objection is true, and it is the most serious of them all. No point dancing around it: the people who know this platform average over fifty, universities do not teach it, and replacing those who retire is hard.

But it has to be compared with the alternative, not with an ideal world.

Replacing the application means a multi-year project, with the failure rate every business system rebuild carries — which is high, and documented by a long series of cases that ended badly. It means losing the detailed rules accumulated over twenty years, the ones nobody wrote down anywhere and which get rediscovered in production one at a time. And it means ending up with a system that needs more people than the old one, because nearly every alternative requires managing operating system, database, middleware and application platform separately.

There is also a fact those raising the objection do not weigh: the platform can be learned. A competent Java developer becomes productive in RPG and SQL within a few months, because the hard part is not the language but the business domain — and they would have to learn that anyway, on the new system too. The staffing problem is real and it is a succession management problem, not a technology one.

"It is closed, proprietary, and locks you in"

Partly true, and it is worth saying which part.

The hardware comes from one vendor, the operating system comes from one vendor, and there is no plan B for moving everything elsewhere over a weekend. That is a real constraint and belongs in the reckoning.

But the honest comparison is not with a world without constraints. A company moving its business system onto one cloud provider's managed services has a constraint of exactly the same nature, with the difference that on IBM i the data sits in a standard database queryable in SQL, and the programs are sources you own. The lock-in is on execution, not on the data.

And in other respects the platform is far less closed than people believe. Python, Node.js, Git and Bash run on it, the database is queried in standard SQL over JDBC and ODBC, programs are exposed as REST services through configuration. A modern application written elsewhere can use the logic that lives here without knowing it is written in RPG.

"It does not integrate with anything"

This was true twenty years ago. Today it is simply wrong, and anyone arguing it is describing a stagnant installation, not the platform.

A current IBM i exposes its programs as web services, is queried in SQL from any language, reads and writes IFS files anyone can pick up, sends mail, calls external services. The technologies are everybody's technologies.

It has to be said just as plainly that many installations do none of this. Not because they cannot, but because nobody was ever given the job. Confusing the two levels — the platform and what that particular company does with it — is what makes the discussion sterile: the system that "does not integrate" is nearly always a system nobody ever integrated.

"It is insecure because it is old"

Here the objection is inverted with respect to the architectural reality, and that deserves explaining rather than simply denying.

On this system everything is an object with a declared type, and the system enforces that type. A data file cannot be executed: not because a permission is missing, but because the operation does not exist for that object type. At security levels 40 and 50 — 40 is the default on new systems — the system also stops programs using unsupported interfaces to step around the controls.

The practical consequence is that an entire class of attack does not work here. Malware written for Windows or Linux does not run: it is not compatible with anything. Many techniques that elsewhere rely on passing off as code something written as data have no purchase in this architecture.

But it is not invulnerable, and claiming so does harm. The real risks exist and there are three, all configuration rather than platform:

• profiles with *ALLOBJ handed to people who do not need it, nearly always because they were created by copying an existing one;
• public authority at *CHANGE — the factory setting — which causes no trouble while only the menu-driven application is used, and becomes a problem the day somebody connects over ODBC;
• IFS directories shared over the network, the one place where ransomware launched from a Windows PC can encrypt data on this system. It is not attacking the system: it is attacking shared files, as it would on any other network drive.

A well-configured IBM i is harder to compromise than the average system. An IBM i left as it came from the factory, with ten *ALLOBJ profiles and security PTFs three years out of date, is not.

"It costs too much"

The per-processor cost is high, and there is no sense denying it. Hardware and licences cost more than an x86 server running Linux, core for core.

The sensible comparison, though, is not on list price but on what it takes to run the same work. On this platform the operating system, the database, the transaction manager, security and the backup tooling are the same thing: there is no DBA and sysadmin and middleware administrator, no database to keep in step with the operating system, no four maintenance contracts and four upgrade windows to synchronise.

In practice a mid-sized IBM i is administered by one person, often part-time. That is where the arithmetic changes, and it is the line that never appears in the comparison table because it does not come with an invoice.

The other side deserves the same honesty: if the workload is small, the numbers do not add up. A machine with this architecture makes sense when there is a transactional core to serve, not for running three light applications.

When it genuinely is the best choice

With the objections out of the way, the useful question remains. There are profiles where this platform is not "still acceptable": it is technically superior to the alternatives, and these are they.

The transactional core of a company that has to stay standing. Heavy writing, data that must be consistent at all times, and an hour of downtime measured in revenue not earned. Database inside the operating system, native journaling, integrated commitment control: consistency is not a layer added on top, it is the floor the machine is built on.

Where IT staff are few. A manufacturer with four hundred employees and two people in IT does not have the skills to run a Kubernetes cluster, a replicated database, an update pipeline and the security of all of it — and never will, because it is not their business. A system that asks for little maintenance and does not stop is, for that company, the rational choice rather than the nostalgic one.

Where the business logic is worth more than the code. Twenty years of accumulated rules are an asset, not a debt: they contain every special case that actually arose. Rewriting them means losing them and rediscovering them in production. This argument holds as long as that code can still be changed at a reasonable cost — if nobody can touch it any more, the argument lapses, and the discussion becomes a different one.

Where the load is predictable. Cloud elasticity is paid for, and it serves those with unpredictable peaks. A business system with a known load growing five per cent a year has nothing to gain from elasticity and pays only for the complexity it brings.

Where compatibility over time has economic value. A program compiled in the nineties runs on a current Power system. No other commercial platform offers that guarantee, and anyone who has built twenty years of development on it knows what it is worth — it is why system upgrades here do not turn into application projects.

When it is not

An article stopping there would be a brochure. The cases where the platform is the wrong choice exist and they are clear.

A new product, especially one sold as a service to many customers. The ecosystem, the per-processor cost model and the availability of people all play the other way.

Analytics and machine learning workloads. The libraries, the accelerators and the skills are elsewhere, and there is no reason to force it. The sensible route is taking the data to where it gets processed, not moving the processing here.

Where you have to grow horizontally and fast. This architecture scales vertically very well and horizontally it does not. A workload that has to go from ten instances to a thousand within an hour wants another platform.

Where the company has to hire quickly and in numbers. If the plan needs twenty developers within a year, the difficulty of finding them stops being an annoyance and becomes the deciding constraint.

Where the application is already dead. If the code can no longer be changed, if whoever understood it has gone and nobody knows why it does what it does, the platform is not the issue: the software is, and it has to be rebuilt. Where to rebuild it is a later question, and the answer may well be "elsewhere".

How to check for yourself

This is a site about IBM i, so it is an interested party, and readers are right not to take its word. Four checks, all within anybody's reach:

1. Support dates and releases are on IBM's official release life cycle page. It says which releases are supported today and until when: the quickest way to know whether a platform is alive or in maintenance.
2. The technology refreshes. IBM publishes the contents of each one. Reading a recent one tells you, better than any opinion, whether the product is getting investment or only fixes.
3. Your own system. WRKPTFGRP says what level the PTFs are at, DSPSYSVAL SYSVAL(QSECURITY) what security level you run at. If the answer is "PTFs from 2021 and security at 30", the problem is not the platform.
4. The software market. Look up whether business software is still sold for this platform, and by how many companies. It is the economic signal hardest to fake.

The objection this article does not answer is the one serious one: who will work on it in fifteen years. That is a legitimate question, and the answer is not technological — it is that skills get built if somebody decides to build them. In the meantime, replacing a system that works because of a problem arriving in fifteen years is an expensive way of bringing it forward.