The demo is good. It’s always good. Someone from the vendor types “show me Acme’s open orders that shipped late” into a chat box and the box answers in a sentence. The room relaxes. Somebody says “wow.” The deal moves a stage.
Then somebody asks what’s underneath, and the answer, once the slide is stripped off it, is a program written in the early eighties on an IBM midrange box that nobody has been brave enough to touch since the Clinton administration.
ERP is where this is loudest, and it’s the same move everywhere else: warehouse management, timekeeping, expenses, point of sale, dealer systems, core banking, property management, construction accounting. Take a forty year old application. Put a browser in front of it and call that cloud. Put a model in front of the browser and call that AI. Issue a press release.
It doesn’t work, and it doesn’t fail because the models are bad. It fails for reasons that are fundamentally structural, and structural problems don’t respond to a better prompt.
What’s under there
Start with Infor, because it’s the purest case. Koch Industries bought the last of it from Golden Gate Capital in April 2020 and owns it outright. Infor sells Baan, which Jan Baan founded in the Netherlands in 1978. It sells BPCS, which SSA wrote in RPG for the AS/400. It sells MAPICS, which IBM first released in 1977 and Infor bought in 2005, now branded XA and still written in RPG. It sells System21 from the UK, SyteLine from Ohio, Movex from Sweden, Lawson from Minnesota. Almost none of the code in those products was written by Infor. It bought all of it.
Infor is the biggest example and it’s a long way from the only one. Epicor Eclipse runs on a MultiValue database and Pick BASIC, a data model from the sixties. Sage 100 is MAS 90, which State of the Art shipped in 1985, with a new name on it. QAD shipped MFG/PRO in 1984 on Progress 4GL and Thoma Bravo took the company private for $2 billion in 2021. Oracle let Premier and Extended support for JD Edwards World, written in RPG in the seventies, lapse in April 2025, and there are still enough customers running it on IBM i to support a third party maintenance market. Then come the roll-ups (Aptean, ECI, Constellation and its hundreds of subsidiaries), all built on the same idea, which is buy sticky vertical software and never sunset anything.
Now step outside ERP. Kronos was founded in 1977, and Workforce Central, its timekeeping product, relied on client-side Java applets until 2017. Supermarket lanes across America still run Toshiba’s 4690, an operating system descended from the IBM 4680 that shipped in 1986; Toshiba renamed it TCx Sky in 2018 and closed it to new customers, and stores keep running it under support contracts. Reynolds and Reynolds, which sits in the back office of thousands of car dealerships, started as a business forms printer in 1866 and still sells ERA, the dealer system it launched in 1987. Jack Henry’s SilverLake, the core banking system for 520 banks, is an RPG application running on IBM i today. Timberline, the construction accounting standard since 1971, now ships as Sage 300 CRE.
Here’s the detail most people outside these accounts have never seen. For a large share of the midrange products, the “web version” is a screen scraper. IBM’s HATS, LANSA’s aXes, Seagull’s J Walk. The green screen program still runs on the box. Middleware captures the 5250 screen and renders it as HTML, with the source code untouched, which is the entire selling point. That shipped as modernization. The client server generation did the same trick with Citrix: the fat Windows client never went away, it got published to a browser tab, and the sales deck started saying cloud.
So when the agent gets announced, look at the whole stack, top to bottom.
| Layer | What it is | Added | Why it’s there |
|---|---|---|---|
| 6 | Agent or Chatbox | 2024 onward | The thing in the press release |
| 5 | Language model | 2024 onward | Translates English into calls against layer 4 |
| 4 | API or web portal wrapper | 2010s | Lets the vendor say “we have APIs” |
| 3 | Screen scraper or Citrix (HATS, aXes, J Walk) | 2000s | Lets the vendor say “web enabled” |
| 2 | Green screen or fat Windows client | 1980s to 1990s | The only interface the logic was ever built for |
| 1 | RPG, 4GL or stored procedure core | 1970s to 1980s | Where every rule that matters actually lives |
The agent is just the newest layer in a forty year habit of not touching the bottom one.
What they announced
None of this is hypothetical, so here are the announcements in their own words.
Infor shipped Velocity Suite in April 2025, then Industry AI Agents in October 2025, built on AWS with Amazon Bedrock. Its April 2026 release claims an agent library above 100, adds an Agentic Orchestrator with native Model Context Protocol support, and bundles the whole thing with implementation services under a flat fee. Epicor launched Prism in September 2025 and called it the industry’s first ERP AI agent, priced on outcomes. Prism now carries 18 or more prebuilt agents and is embedded directly in Kinetic and Prophet 21, which are Vantage and the old Array Technologies Progress product respectively. At Insights in May 2026 Epicor added Lux, an agentic design system, and the Prism Agent Foundry, and gave the strategy a name: Cognitive ERP, described as the shift from a system of record to a system of outcomes.
Read Epicor’s own description of what the agents do and you’ll find the concession sitting in plain sight. The agents take pre-approved actions, with human oversight. That’s the read path with a person standing on the write path, which is exactly what the architecture forces, and the press release says so.
Now check the arithmetic
Infor is owned by Koch. Epicor is owned by CD&R. Aptean, ECI and QAD are all private equity. None of them publish a development budget, so none of these announcements can be audited. Jack Henry is the exception, because it’s listed on Nasdaq and has to file, and its numbers are worth walking through precisely because it’s the most honest actor in this piece.
From the fiscal 2025 10-K, for the year ended 30 June 2025. Total revenue was $2.375 billion. Research and development expense was $162.8 million, which Jack Henry’s own table puts at 7% of revenue. Capitalized software was another $172.4 million. Add them and total development spend runs about $335 million, call it 14% of revenue, across roughly 7,240 employees.
Now look at what that $335 million has to cover. Four separate core platforms: SilverLake, CIF 20/20, Core Director and Symitar. The Banno digital platform. Card processing, payments, fraud, imaging, treasury. Annual regulatory and compliance updates across all of it. And the Jack Henry Platform, which the 10-K describes as a public cloud-native, API-first platform the company is “developing into a fully functional modern alternative for existing core functions.”
Read that phrase again. In its fiftieth year of business, the modern alternative to the core is still being developed. The core that 520 banks actually run on is the RPG one.
For scale, Shopify spent $1.53 billion on research and development in 2025, about 13% of $11.55 billion in revenue, on one platform roughly twenty years old. The percentages are close. The absolute numbers are not. Shopify’s development budget is over four times Jack Henry’s entire spend, and it isn’t split across four cores plus a rewrite plus fifty years of compliance debt.
That’s the arithmetic at a company that discloses. Apply the same question to a private roll-up with a hundred acquired products and no filing obligation, and ask how much of the development budget reaches any single forty year old codebase after the AI demo is built. Then ask how many engineers have read the RPG.
The argument for doing it anyway
The other side deserves its case made properly, because it’s better than they usually make it.
Bad software is a soft target for a chat interface. If it takes eleven clicks across three screens to answer a question an operator asks forty times a day, a chat box over the reporting database is a genuine improvement for almost no engineering. The bar is on the floor.
There’s no metering to fight. NetSuite meters SuiteScript in usage units and terminates a script that runs past its budget, and it caps concurrent integration calls per account. A 1985 midrange app does none of that, because nobody built a throttle. You get ODBC and a schema, and a model that can read two thousand tables and write correct SQL against them is a solved problem now.
And switching cost in the mid-market is effectively infinite. A two hundred million dollar distributor on SyteLine has two people in IT and no replatforming budget. Same for the community bank on SilverLake, same for the dealer group on ERA. Telling them to rip out the core is a fantasy dressed up as advice. They’ll take the layer because the alternative on offer is nothing.
All of that is true. It still fails.
Reading is easy. Writing is fatal.
Direct SQL against these systems is fine for reading. It’s catastrophic for writing, and everything hangs on that.
The rules that make the data mean anything aren’t in the database. They’re in RPG, in 4GL, in stored procedures that fire when a human posts through a screen. Allocation, reservation, GL posting, tax, costing. Write an order row directly and you get a record that exists, never allocates, never touches the ledger, and shows up five weeks later as a variance nobody can trace.
The same failure has a different name in every category. In a warehouse system, an agent that writes a pick confirmation without running the task engine leaves stock committed to a location that no longer holds it. In timekeeping, a direct write to the punch table skips the rounding and overtime rules, which is how a payroll error becomes a wage and hour claim. In expenses, it skips the policy check, and the auditor finds it later.
So the agent gets read access and the write path stays human. What shipped is a dashboard with a chat box. Dashboards were never the expensive problem.
There’s no install base. There are a thousand snowflakes.
Every customer on these systems has their own database, their own version, their own fork, and their own consultant-written modifications from 2011 that nobody has read since the consultant left. The vendor can’t ship one agent across the base because there isn’t a base. There are a thousand instances sharing a brand name.
That’s why the demo works and the rollout stalls. The demo runs against the vendor’s canonical model. Your instance has three hundred custom fields and a workflow that fires on a field the demo has never heard of. Cost per deployment never falls, so it stays a services project forever, which is a fine business and a terrible product.
The system never saw the thing you’re asking about
This is the one that no model improvement fixes, and it’s the one to put in front of any vendor selling you an agent on forty year old software.
These systems were built to record the consequence of work. The work itself never entered them. The ERP was designed when an order was a document that became an invoice and inventory sat in one building. The timekeeping system was built to produce a payroll file, so it recorded the punch and skipped the shift swap behind it. The warehouse system was built to confirm a pick, so it recorded the transaction and had no field for the reason the picker walked past the bin twice.
Commerce stopped looking like the picture any of them were drawn from. Split shipments, partial cancels, marketplace orders where the customer record belongs to Amazon, carrier exceptions, returns that arrive before the RMA exists, availability promises made in real time across four locations and two 3PLs. None of it ever entered the system, because the system was never asked to watch for it.
Put the best model in the world on top of a 1980s application and it still can’t reason about a lifecycle the database never saw. That’s a data problem. More compute doesn’t fix it.
Meanwhile, the data that is in there is stale in ways the operators have learned to compensate for. They pad the on-hand because the cycle count is three weeks old. They fix the payment terms at invoice. They keep the spreadsheet the system can’t replace, and they’ve kept it for nine years. Automate on top of that and you remove the person who was quietly repairing the data, without anyone ever writing down what they were repairing. The errors don’t show up at launch. They show up a quarter later, in the close.
Follow the money
The strongest evidence that no rewrite is coming has nothing to do with technology.
Koch owns Infor. Thoma Bravo took QAD private in 2021. Aptean was assembled by Vista out of CDC Software and Consona in 2012 and is now led by TA Associates, with Insight Partners and Charlesbank alongside. ECI is co-controlled by Leonard Green and Apax. Constellation has told its shareholders in writing that it prefers to buy businesses outright and own them forever. These assets were bought as maintenance annuities, and a maintenance annuity does not fund a five to eight year, cash negative rewrite of a thirty year old core.
So the AI announcement is the substitute for the rewrite. It ships in two quarters, prices as an upsell on the same annuity, and fits in a press release. The actual answer is a decade of engineering that nobody in the capital structure wants to pay for. That’s why the announcements keep coming and the products keep being dashboards.
What to do instead
Ripping it out is the wrong answer for almost everyone. The ledger is the ledger, the close works, the auditors know it, and replatforming a core system is career risk with no upside.
The move is narrower. Stop asking a system of record to be the operating system for the work. It never was, and a chat box on top doesn’t make it one. Put the operational data model where the events actually happen. In commerce that’s between the selling channels, the fulfillment network and the ledger. Capture the lifecycle as it occurs, at the speed it occurs, with every state transition intact. Handle the exceptions there, where the data is complete and current. Then post clean financial truth back to the system of record, which is the one job it has always done well.
The old system stays. It just stops pretending to be the system of action.
Ten minutes that save you a year
Five questions. Ask them in the first meeting, before the demo, and they’ll sort the built from the announced in any category.
Can the agent write, and through what path? If the answer involves direct database access, ask what enforces the rules that normally fire when a person posts through the screen. If a human approves every write, you’re buying a dashboard.
What do you spend on development, and how much of it reaches my product? Public companies have to tell you. Private ones don’t, which is itself an answer. Ask how many engineers work on the codebase under the agent, not on the agent.
What’s the data latency, end to end, measured on a live customer instance? The architecture diagram doesn’t count. Ask for the number.
How many production customers run this, and how close are their instances to mine? If every deployment is a project, you’re funding the learning curve.
Which events does the underlying system actually record? Name the messiest case in your own operation and ask them to show it. In commerce, that’s a split shipment with a partial cancel and a return that arrived before the RMA. Then watch what happens.
The answers are usually available if you ask plainly. Most buyers never ask, because the chat box demos well and the room wants to believe it.
