Is IBM i legacy?
Usually the wrong question, and answering it wrongly is how organisations spend seven figures solving a problem they didn't have.
This page is the evidence for that, including the parts that don't flatter the platform. If you're making the case internally and need something to forward, this is it.
What people believe, and what is actually true
It's the AS/400: decades-old hardware running decades-old software.
The name AS/400 was retired in 2000. The current operating system is IBM i 7.6, released in 2025, running on Power11 processors. IBM ships a Technology Refresh roughly twice a year. 7.6 TR2 and 7.5 TR8 both landed in July 2026.
IBM is winding the platform down. There's no future in it.
IBM i 7.5 and 7.6 have no announced end-of-support date. IBM's published cadence is three years between major releases, seven years of support and three of extended support, which puts the current release into the mid-2030s, with Power generations mapped out well beyond that. It is one of the more transparent long-term roadmaps in enterprise computing.
There's no real database. It's flat files.
Db2 for i is a full SQL relational database built into the operating system. Stored procedures, triggers, views, constraints, JSON functions, temporal tables. It is reachable by ODBC and JDBC from anything on your network, exactly like any other enterprise database.
RPG is a dead language nobody writes any more.
Free-form RPG is a modern procedural language with embedded SQL, subprocedures and service programs. It reads much like any other. The problem isn't the language. It's that a lot of code was written in the 1980s and never modernised, which is a decision, not a constraint.
It only runs green screens. You can't do web.
The Apache HTTP Server ships with the operating system. Python, Node.js, Java, PHP and Git all run natively in PASE, the AIX-compatible runtime inside IBM i. We run a full modern Python web stack there ourselves, serving HTTPS and reading Db2 over a local connection.
It's an island. It can't talk to the rest of the business.
This is the most damaging one, and it has its own section below.
"IBM i can't do APIs" is simply false
This myth does more commercial damage than all the others combined, because it's the one used to argue that you must leave the platform to integrate with anything else. That argument rests on a false premise.
- Exposing REST APIs, built into the OS. Integrated Web Services (IWS) publishes an existing RPG or COBOL program as a REST or SOAP service without changing its source. It ships with IBM i at no extra cost.
- Consuming REST APIs from RPG. IBM ships copybooks for calling HTTP services directly from RPG. Open-source toolkits handle JSON parsing and generation; Db2 itself has JSON functions in SQL.
- Stored procedures as the integration boundary. Any SQL client (.NET, Java, Python, an integration platform, a BI tool) can call IBM i business logic through a stored procedure over ODBC or JDBC.
- Anything Java, Node or Python can do, IBM i can do. All three run normally in PASE, which means Kafka clients, cloud SDKs, message queues, webhooks and everything else in those ecosystems. Java has run natively on the platform for decades.
- .NET runs on the same machine, without buying one. Power hardware runs Linux partitions alongside the IBM i partition, and .NET runs on Linux on Power. So a .NET application can sit next to your IBM i, on the same physical box, reaching Db2 over the internal network. No new hardware, nothing in a public cloud.
- Enterprise messaging. IBM MQ runs natively. So does file-based integration, SFTP, and scheduled exchange with anything that speaks a standard protocol.
The honest part: the platform has been able to do all of this for years, and a great many shops still don't, because the skills to build it have been the bottleneck, not the technology. "We can't" almost always means "nobody here has had the time or the experience to." That is a fixable problem, and a much cheaper one than migration.
Where the platform genuinely does fall short
Anyone who tells you it has no drawbacks is selling something. These are real and they belong in your decision, but each one has a way of being managed, and they point in a consistent direction.
The skills market is thin and getting thinner.
Experienced IBM i developers are hard to find, expensive to hire and frequently close to retirement. Succession is a genuine risk and it does not solve itself.
Shrink the dependency in phases rather than in one jump. Start with a deliberate mix: business rules stay in RPG, everything new is written in a mainstream language your team can hire for. The RPG surface then reduces service by service, on your schedule, as there is reason to.
Nothing you have invested in is thrown away, and you are not betting the business on finding RPG developers indefinitely. Capture the undocumented rules while the people who know them are still here. That is the part that genuinely cannot be recovered later.
The ecosystem is small.
Compared with mainstream stacks there are fewer off-the-shelf libraries, fewer integrations that work out of the box, and a much smaller pool of people to ask when something breaks.
You do not have to solve it on IBM i. The application tier runs in a mainstream ecosystem (Java, .NET, Python, Node) with every library and integration that comes with it, while the data and the rules stay where they are.
The small-ecosystem problem only constrains you if you insist on doing everything in RPG. We don't.
Cloud-native patterns aren't native.
Containers, orchestration and the tooling around them are not how this platform works. You can reach them from it, but you are working against the grain.
Run those parts where they belong. A Linux partition on the same Power hardware, or a cloud VM, connected to IBM i through the stored-procedure boundary. Containers and orchestration where they earn their place; the system of record left in the shape that suits it.
Hybrid by design. The alternative, forcing a transactional core into a cloud-native shape, is a large programme with a poor record.
Cost per core is high.
Power hardware and IBM i licensing are expensive next to commodity x86. The comparison narrows once you account for how much one machine does and how little administration it needs, but the sticker price is real.
Stop growing the expensive tier. Presentation, integration and reporting move to cheaper Linux or cloud compute; only the core transactional workload stays on Power. Future growth then lands on the inexpensive side of the line.
And an honest caveat: if the workload is genuinely small, the economics may favour leaving. That is a legitimate finding and we would tell you so.
Single-vendor concentration.
One vendor, one hardware line, one operating system. That brings coherence and stability; it also means your options are narrower than on an open stack.
Move the replaceable parts off the dependency. The application tier is open components on ordinary hardware, delivered as source. Each service that moves outside the boundary reduces the concentration a little further.
It does not disappear, but it shrinks steadily, through changes you can reverse, rather than through one irreversible migration.
So what actually is legacy?
In almost every shop we look at, it is not the machine, the operating system or the database. It is three things:
The interface. A green screen cannot give the business customer self-service, supplier access, mobile, or multi-factor authentication. That is a genuine constraint and it is usually what prompted the question in the first place.
The undocumented business rules. Thirty years of decisions exist only in the code and in the heads of two or three people. That is the real risk in the building, and migrating the system elsewhere doesn't remove it. It multiplies it, because now the rules have to be rediscovered and reimplemented.
The skills concentration. Fewer people each year understand how it works. Also real, also not solved by a platform change. A rewrite needs those same people to explain what to rewrite.
None of the three is an argument about Power hardware or IBM i. All three are arguments about an application that stopped being invested in. A different platform doesn't fix any of them; it just changes where they live and adds a migration to the bill.
What this means for the decision in front of you
There are perfectly good reasons to leave IBM i. A packaged application your business has outgrown. A group-wide consolidation. An acquisition that settles it for you. Those are business decisions and we would not argue with them.
What we would question is leaving because the platform is "old", because that premise doesn't survive contact with the facts above, and it is an expensive thing to be wrong about.
We are not advocates for the platform. We have no stake in you keeping it, and we would say the same about any technology: a decision this expensive should rest on what the business needs, not on what a language looks like or how old a name sounds. If the honest answer is that you should leave, that is a perfectly good answer. It just deserves to be reached on the facts.
The cheaper path, and usually the better one: modernize the interface, expose the business logic as services, document the rules while people are still here to explain them, and keep the system that already runs your business correctly.
Check any of this
Release and support positions are published by IBM on its IBM i platform support pages. Technology Refresh contents and the longer-range roadmap are covered in the independent trade press, notably IT Jungle. Integrated Web Services is documented in IBM's own product documentation.
We would rather you verified this than took our word for it. It is a stronger argument when you have checked it yourself.