There is a particular kind of meeting that happens inside large organizations, usually once a year, usually driven by a new CIO or a fresh budget cycle, where someone puts a slide on the screen showing the core system that processes payroll or claims or inventory, and next to it the year it was written, and the room goes quiet for a moment because the number is older than most of the people in it. Then the conversation turns to replacement, and someone mentions a figure, and someone else mentions the last time a replacement was attempted, and by the end of the hour the system has been granted another year of life. This is not incompetence. It is, in most cases, the rational decision. The systems that keep global commerce moving are old because old systems that work are extraordinarily difficult to argue with, and the industry has spent thirty years pretending otherwise while selling replacement projects that mostly failed.
The scale of the dependency is worth sitting with. Reuters reported in 2017 that COBOL still underpinned a large share of daily banking transaction volume and the majority of in-person credit card transactions, with billions of lines of the language still in production across financial services (Reuters, “Banks scramble to fix old systems as IT ‘cowboys’ ride into sunset”). Those foundations have not been replaced in the years since. The same reporting found that only about 11.5% of COBOL programmers were under the age of 35 at the time, with most well into their fifties, which is the detail that turns a technical observation into a business risk, because a language with no succession plan is a dependency with an expiry date attached to human biology rather than to any product roadmap.
Why the old systems are still here
The honest reason decades-old systems survive is that they encode decisions nobody wrote down anywhere else. A COBOL batch job that has run nightly since the Reagan administration is not just moving data between tables. It is applying the tax treatment agreed with a regulator in 1994, the rounding convention that resolved a dispute with a major customer, the exception handling for a product line that was discontinued but whose contracts run for forty years, and the particular sequence of operations that stopped a reconciliation failure that nobody currently employed can remember. None of this appears in a requirements document, because there is no requirements document. The code is the document. That is the whole problem, and it is also why the code keeps running.
Add to that the plain fact that these systems are, in the narrow terms they were built for, very good. Mainframe transaction processing is reliable in ways that generations of distributed replacements have struggled to match. An AS/400, now IBM i, installed in a manufacturing plant in the 1990s may have run for two decades with almost no unplanned downtime, and the operations director who watched it do that is entitled to be skeptical when a vendor promises the same reliability from something that needs patching every few weeks. The strongest version of the case for leaving legacy alone is not nostalgia or inertia. It is that the system works, the replacement risk is real and demonstrated by history, and the capital could earn a better return almost anywhere else. That case deserves a proper answer rather than a sneer.
The cost is not the license fee
Where the argument for standing still falls apart is on the cost side, because the cost of legacy dependency is almost never the line item that appears in the IT budget. Hardware and support contracts are visible and, relative to the alternative, often modest. The invisible costs are the ones that compound.
The first is knowledge. When the person who understands the general ledger module retires, the organization does not lose a developer, it loses the only working model of how a critical business process actually behaves. Documentation, where it exists, describes what the system was meant to do at some point in the past. The gap between that and current behavior is filled entirely by memory. Every retirement widens the gap. Organizations respond by hiring contractors at rates that reflect scarcity, which works until the contractor market itself thins out, and it is thinning, because nobody entering the profession today is choosing to specialize in a language whose employers are trying to escape it.
The second is optionality. A legacy core does not stop you running the business, it stops you changing it. Every new channel, every partner integration, every regulatory reporting change, every acquisition that needs to be absorbed becomes a negotiation with a system that was designed before any of those requirements existed. The cost shows up as elapsed time rather than expenditure, six months to add a product variant, eighteen months to integrate an acquired entity, a competitor shipping something in a quarter that you cannot ship at all. Nobody books that to the legacy line. It is real money.
The third is concentration risk, and it is the one boards should be asking about directly. If a single system failure would halt a material part of revenue, and the number of people who can diagnose that system is in single digits and falling, that is a governance issue, not an engineering preference.
What is actually still in production
Legacy modernization content tends to talk about “legacy systems” as a homogeneous category, which is convenient for vendors and useless for anyone actually holding the problem. The stacks are different, they fail differently, and they need different treatment.
COBOL on mainframe dominates banking, insurance, and government administration. Huge codebases, batch-oriented, exceptional throughput, deep entanglement with JCL and VSAM or DB2. The business logic is genuinely valuable and genuinely undocumented.
RPG on AS/400 and IBM i is the manufacturing, distribution, and wholesale equivalent. Often smaller in line count than a banking mainframe but no less load bearing, frequently green-screen fronted, and commonly maintained by one or two people who joined when the machine was installed.
Microsoft Access and VBA is the one organizations are most embarrassed about and most exposed to. These applications were never sanctioned. They grew because a department needed something the central systems did not provide, and they now hold production data, run reporting that feeds board packs, and sit on a shared drive with no version control and no owner. The failure mode is quiet and sudden.
Oracle Forms built a generation of enterprise applications, particularly around Oracle databases and E-Business Suite. Oracle’s own Lifetime Support Policy sets a real, near-term deadline: Premier Support for Oracle Fusion Middleware 12c, which includes Forms and Reports 12c, ends in December 2026, with Extended Support running through December 2027 (Oracle Fusion Middleware: End of Premier and Extended Support). Organizations still running Forms should treat that date as a planning input now, not a future problem.
Lotus Notes and Domino applications are the archaeology of the 1990s collaborative enterprise, hundreds or thousands of small applications accumulated across departments, each one holding a workflow somebody depends on, almost none of them inventoried.
Excel-based workflows belong on this list even though nobody calls them legacy. A spreadsheet that three departments depend on, with embedded macros, manual handoffs, and a single author, is a production system with none of the controls.
Why rip-and-replace keeps failing
The replacement playbook has been consistent for thirty years and so has its record. Gather requirements from a system whose requirements exist only in code, write a specification, select a package or commission a build, run a multi-year program, discover partway through that the old system does forty things the specification missed, extend the timeline, watch the sponsor change, and either ship something that recreates the legacy system badly or abandon the effort and write off the spend. The public failures are well documented across government and financial services; the private ones are more numerous and quieter.
The root cause is not project management. It is that requirements gathering assumes the requirements can be gathered, and with legacy systems they cannot, because the people who knew them are gone and the only complete statement of behavior is the source code itself. Every replacement project that treats the old code as something to be discarded rather than read is starting from a position of guaranteed information loss.
The alternative follows directly from that. Treat the legacy source as the specification. Read it, extract the logic it actually implements, and rebuild against that rather than against a business analyst’s reconstruction of what it might do. Do it incrementally, application by application, so that value arrives in weeks rather than after a multi-year program, and so that each step can be validated against the system still running beside it.
This is the design premise behind GalaxyONE, Sovablu’s AI engine. It accepts legacy source code as a direct input, including COBOL, RPG, AS/400, Visual Basic, Oracle Forms, Lotus Notes, and Access/VBA, and its four Copilots (Solution, Data, Logic, Layout) produce output that lands as editable objects in the UI Designer, Data Designer, and Logic Designer. That last part matters more than it might sound. The output is not opaque generated code that becomes tomorrow’s legacy problem. It is inspectable, editable structure that a business or IT team can interrogate, which means the modernization does not simply relocate the knowledge gap to a new platform.
What to do about it
Start by finding out what you actually have. Most organizations cannot produce an accurate inventory of their Access databases or Notes applications, and the discovery exercise alone usually reframes the conversation, because the risk turns out to be distributed across hundreds of small things rather than concentrated in the one mainframe everybody worries about. Then rank by the knowledge risk rather than the technical age, because a ten-year-old application with three maintainers is safer than a five-year-old one with none.
Then pick the smallest thing that hurts and migrate it properly, using the source code as the specification rather than a reconstruction of it, and measure how long it took. That number, produced by your own team on your own system, is worth more than any vendor’s benchmark, including ours. If it is short enough that the second migration can start before the first has finished being celebrated, you have found a path off legacy that does not require betting the company on a single program. If it is not, stop and change the approach before the budget rather than after it.
The systems will not modernize themselves, and the people who understand them are leaving on a schedule nobody controls. That is the deadline.