/
.webp)
Generated by Master Biographer | Source for LinkedIn Content
The operations center of a mid-sized American bank, sometime in 2024. The core system — the one that processes every transaction, holds every account balance, manages every loan — has been running continuously since 1993. The servers hum quietly in a climate-controlled room. Nobody on the current team has ever touched the original code. They have been told, in no uncertain terms, not to.
The system is an IBM AS/400. It was designed in 1986. It was shipped in 1988. And on the day those engineers walked out the door, they took the only working knowledge of that codebase with them.
This is not a story about a failure. The system has not failed. It has run, without interruption, for over thirty years. That is, in a way, the entire problem.
In June 1988, IBM announced a new midrange computer system from its Rochester, Minnesota facility. They called it the Application System/400 — the AS/400. IBM's chief architect Frank Soltis, the man who would later be called "the Father of the AS/400," described what his team had built as something that had never existed before in commercial computing: a fully object-oriented system, all the way down to the operating system itself.
The AS/400 launched at prices ranging from $19,000 for the entry model to $229,500 for the top-end B60. An industry analyst called it "the most significant announcement since the personal computer." One early adopter reported the hardware was operational two hours after delivery. Within the first four months, IBM sold more than 25,000 machines — the most successful product launch in the company's history at that point.
By 1990, there were 111,000 installations. By 1994, 250,000. By 1997, 500,000. Annual revenue from the platform hit $14 billion in 1990. Those are mainframe numbers in a midrange body.
Here is the thing that explains everything — the longevity, the trap, all of it.
The AS/400 was built around something IBM called TIMI: the Technology Independent Machine Interface. TIMI is a virtual instruction set, a layer that sits between application code and the actual hardware underneath. When a programmer writes a program for the AS/400, it compiles into TIMI instructions — not into the native machine code of whatever CPU is sitting in the box at that moment.
This means that if IBM swaps out the underlying processor — which they did, dramatically, in 1995 when the platform transitioned from its original 48-bit CISC architecture to a 64-bit PowerPC — every application compiled before that transition continues to run. Automatically. No recompilation. The operating system simply regenerates the machine code from the stored TIMI instructions.
A program written and compiled in 1988 runs on a 2024 IBM Power Systems server without modification. Not because anyone maintained it. Because the architecture made that impossible to break.
"The first platform that was fully object-oriented, even down to the operating system." That was not marketing language. It was a structural decision that made the AS/400 uniquely difficult to replace, for reasons nobody fully appreciated until 20 years later.
The AS/400 was among the first general-purpose business computers to achieve C2 security certification from the NSA. In 1988. The IBM team that built it had, by their chief architect's own account, "largely lacked UNIX experience" — and the result was a security model completely alien to the rest of the computing world, one that turned out to be extraordinarily robust.
The UNIX world was building security on top of systems. The AS/400 built security into the object model from the ground up. Every piece of data — every file, every program, every region of allocated memory — is an encapsulated object managed by the operating system. You cannot access memory directly. You cannot bypass the object model. There is no "root."
This is why banks love it. And why it is genuinely difficult to attack.
The AS/400 was not supposed to exist.
In 1986, IBM's corporate leadership wanted a different machine. They had a vision for where midrange computing was going. The Rochester, Minnesota facility — where IBM's midrange teams worked — had a different idea. According to documented accounts, Rochester went ahead and built what they believed was right rather than what headquarters wanted. The book Frank Soltis later wrote about the AS/400 was titled, with a certain knowing pride: "Fortress Rochester."
"Within IBM," Soltis wrote, "Rochester is rarely regarded as a team player and is more often viewed as a competitor than an ally."
IBM approved over $1 billion in funding for Silver Lake — the AS/400's codename — in March 1986, named after a local pond outside Rochester. Two years later, the team delivered a system that would go on to generate more revenue than almost anything else IBM has ever made.
The team launched with something unprecedented: more than 1,000 packaged software applications announced on day one. By the time the first systems shipped two months later, there were 2,500 software packages available. The product ecosystem was ready before the hardware arrived. This was not an accident. Rochester had spent two years pre-selling the ecosystem.
The AS/400 became IBM's single most successful product. And Rochester, as a result, became very hard to control.
Today, over 100,000 companies run IBM i — the modern name for the AS/400 platform. Approximately 16,000 banks worldwide rely on it. It has a 41.6% market share in server hardware. In a 2024 survey, 43% of IBM i users said they run 76–100% of their entire business on the platform. Fifty-five percent said they are making no change or increasing their workload on it.
Chevron runs it. JP Morgan runs it. UPS runs it. The United States government runs it.
Migration projects exist. They are announced, scoped, budgeted, and initiated with regularity. And then, with remarkable frequency, they are quietly abandoned.
The reasons are structural:
The code is irreplaceable. Most AS/400 applications were written in RPG — Report Program Generator — a language designed specifically for the platform. RPG code is not portable. It does not run anywhere else. Migration means rewriting, not porting. And rewriting 30 years of business logic — including the edge cases, the workarounds, the undocumented behavior that the business has unconsciously built itself around — is not a software project. It is an archaeology project.
The dependencies are invisible. Over 30 years, organizations have built workflows, integrations, manual processes, and downstream systems that assume AS/400 behavior. These are not documented. They live in people's heads, in printed binders in filing cabinets, in the muscle memory of operations staff who have been doing the same thing the same way since 1997.
The risk is catastrophic. When TSB Bank attempted a legacy banking system migration in 2018, the project involved 85 subcontractors, took three years, and still failed spectacularly — locking 5.2 million customers out of their accounts for weeks. The CEO resigned. TSB was fined $62 million. That story is known to every CIO at every bank that runs a legacy core system. It is the reason migration proposals stall in boardrooms.
The system simply doesn't break. The AS/400 was built for 99.9%+ uptime. It delivers. When a system has been running without a production incident for a decade, the business case for replacing it is essentially "we should spend $50 million and two years on something that might fail so we can stop using something that has not failed." That argument rarely wins.
This is the trap in its purest form: the AS/400's greatest strength is the reason it cannot be replaced. Its backward compatibility means nothing ever forces a rewrite. Its stability means there is never a crisis that justifies migration spending. Its security means there is no breach that triggers a platform review. Every virtue of the system translates directly into a reason to stay.
Companies are not stuck on AS/400 because they are unsophisticated. They are stuck because a 1988 machine keeps passing every test.
There are an estimated 800 billion lines of COBOL code in daily production use globally. That number, from a Micro Focus survey of 1,104 IT professionals across 49 countries, is three times higher than previous estimates from 2017 (220 billion lines, per Reuters). The number is going up, not down.
Seventy to eighty percent of global business transactions touch COBOL systems at some point. Every ATM withdrawal. Most airline reservations. The majority of insurance claim processing. Social Security payments. The Federal Reserve.
COBOL was written in 1959. The AS/400 runs it natively.
In 2022, the IBM i Marketplace Survey found that 48% of IBM i professionals were between 56 and 66 years old. Another 7% were 67 or older. The ALL400s survey the same year found that the most common age bracket was 50–59, at 36.5%.
The typical RPG programmer — the person who writes the code that runs the AS/400 — was born around 1955. That makes them approximately 70 years old in 2025.
By 2030, by conservative estimates, 72% of RPG programmers will be deep into retirement territory. The article that coined the phrase "RPG Decade of Crisis" states plainly: "Most RPG programmers will be retired by 2025." Not 2030. 2025.
No university teaches RPG. No coding bootcamp covers it. The pipeline is not thin — it does not exist.
COBOL programmer salaries in the United States currently average $107,085 per year, with senior specialists earning $117,000 or more. These are not the salaries of people working in a dead language. These are the salaries of people who know something nobody else knows, who are needed by systems that cannot stop running, and who are running out of years.
The crisis is not "eventually there won't be anyone to write new code." The crisis is that when these engineers retire, the knowledge of how the existing code actually works goes with them.
Nobody wrote down the business logic. It was never intended to last this long. The engineers who built these systems in the early 1990s are not leaving documentation — they are leaving. And the organizations left behind are holding systems they cannot understand, cannot modify safely, and cannot replace.
The AS/400 keeps running. The humans who could interpret what it's running are disappearing.
IBM has not given up on IBM i. The platform is actively updated, running on modern Power Systems hardware. IBM i 7.5 was released in 2022. The operating system supports Python, Java, Node.js, PHP, and modern web frameworks alongside RPG and COBOL. IBM has spent years trying to position IBM i as a hybrid-cloud platform, not a legacy one.
The rebranding history tells this story in compressed form: AS/400 (1988) → AS/400e (1994) → eServer iSeries (2000) → System i (2006) → IBM Power Systems running IBM i (2008–present). Seven names in 20 years. One exasperated user suggested IBM should simply call it "Bruce" and be done with it.
The platform changed names. The fundamental architecture did not change. The programs from 1988 still run.
This is where the present-day story lives — not in migration, but in integration.
Companies are not migrating off AS/400. They are connecting it. The pattern emerging across banking, manufacturing, and distribution is not replacement but bridge-building: keep the AS/400 as the system of record, and connect it in real time to the modern systems that surround it — CRMs, cloud analytics, e-commerce platforms, customer data warehouses.
The problem is that AS/400 was not built to talk to a REST API. DB2 for i — the database at the heart of IBM i — does not naturally communicate with Salesforce or Snowflake or HubSpot. The data sits in the system. The business needs it to move.
This is the exact problem Stacksync was built to solve. Stacksync's IBM i connector bridges DB2 for i to over 200 modern systems — bi-directionally, in real time, without requiring any modification to the legacy code. The RPG applications keep running unchanged. The data they generate flows, in sub-second latency, into whatever modern system needs it.
One manufacturing customer achieved a 95% reduction in out-of-stock orders by connecting their IBM i inventory system to their e-commerce platform in real time. What had been estimated as a 6-month custom development project took 3 weeks. A bank reduced manual data entry by 85% by syncing their core IBM i banking system to their cloud CRM.
The AS/400 is not going anywhere. The question is whether the data it holds can participate in the modern architecture that has grown up around it. That gap — between a 1988 system with impeccable reliability and a 2024 ecosystem that runs on APIs — is where the real work happens.
1. A program compiled in 1988 runs on a 2024 server without modification.
The TIMI architecture stores virtual machine instructions alongside native code. If IBM changes the underlying processor, the OS regenerates the machine code automatically. This is why nothing ever forces a migration.
2. 16,000 banks worldwide currently run on it.
Not some banks. Not legacy banks. Sixteen thousand. That includes institutions processing millions of transactions per day on hardware and code that predates the World Wide Web.
3. The typical RPG programmer was born in 1955 and is running out of years.
72% of the IBM i developer workforce will be retirement-aged by 2030. No university teaches RPG. The knowledge inside these systems is not being transferred — it is being lost.
4. There are 800 billion lines of COBOL in production today — and the number is growing.
The 2017 estimate was 220 billion. The 2022 estimate is 800 billion. The world is not winding COBOL down. It is generating more of it.
5. Rochester built the wrong machine — on purpose.
IBM headquarters wanted a different product. The Rochester team, who later described themselves as "rarely regarded as a team player" within IBM, built what they believed in instead. The result became IBM's most profitable product and earned the name "Fortress Rochester."
6. It survived Y2K without breaking a sweat — because of a design decision made in 1988.
While other systems required emergency remediation to handle four-digit years, the AS/400 stored dates internally as integers representing days from a base date. It never used two-digit years. Y2K was not a crisis. It was a Tuesday.
IBM i sits at the center of a paradox every RevOps and data team eventually runs into: the most reliable system in the building is also the most isolated. The data is there. The CRM doesn't see it. The analytics warehouse doesn't see it. The customer success platform doesn't see it.
The AS/400 was not designed to be a data silo — it was designed before the concept of "data silo" existed. In 1988, it was the only system that mattered. In 2024, it is one system among dozens, and it is the one that doesn't speak the language the others use.
Stacksync's IBM i integration is a direct answer to this problem: real-time, bi-directional sync between DB2 for i and any modern system, no code changes to the legacy applications, no disruption to the platform's legendary uptime. The AS/400 keeps doing what it has always done. The data it generates stops being trapped.
The companies that figure this out are not replacing their AS/400. They are finally letting it talk.
Sources: IBM History Archive, IT Jungle, Midrange.com, ASNA RPG Crisis Decade, Micro Focus COBOL Survey, Enlyft Market Share Data, Stacksync IBM i Integration Blog, Frank Soltis "Fortress Rochester," TechMonitor AS/400 Pricing Archive, Post Bulletin Rochester, Programmers.io IBM i Research
