What Legacy Systems Really Cost? Kaleshwar Aryasomayajula Spent a Decade Counting

A Senior Software Developer at Charles Schwab and a veteran of Maryland’s modernization programs, he has turned a decade of overhauls into $2.6 million in savings and one blunt argument: standing still has a price.

Legacy systems are eating 35% of federal finance teams’ working hours, according to research MeriTalk published in April 2026 with Workday Government, based on 100 senior finance decision-makers across federal civilian agencies, the Department of Defense, and the intelligence community. That third of the workweek does not go to analysis or planning. It goes to manual reporting, reconciling spreadsheets by hand, re-keying data, and chasing errors, all of it work modern systems handle without anyone touching it. The finding is not really about technology. The cost of a legacy system is not only what an organization pays to keep it running; it is what that system stops its people from doing.

Kaleshwar Aryasomayajula has been making that argument in practice for more than a decade. A Senior Software Developer at Charles Schwab and a long-time contributor to government modernization across several Maryland state agencies, he has built a documented record of what these decisions return. His work spans three organizations: a major financial institution, a state-government IT contractor, and an insurance technology firm. Together they account for more than $2.6 million in cumulative savings, plus measurable gains in processing speed and reliability for thousands of daily users. The numbers make a financial case first and a technology case second.

The Maintenance Trap

The standard accounting for a legacy system covers what shows up on an invoice: license fees, support contracts, and the engineering hours to keep aging infrastructure alive. What it misses is the overhead that builds up around a system that works, but badly. People fill the gap. Staff reconciles by hand what the system cannot reconcile itself; engineers spend weeks staging a change because the codebase has grown so tangled that nobody can say for certain what else will break. Over time, the organization quietly reorganizes itself around maintenance instead of progress, and the projects that should be starting never do.

The scale is well documented. A GAO review of U.S. federal IT spending found that 79% of an annual budget north of $105 billion goes to operations and maintenance, and that only three of ten critical legacy systems it had previously flagged were modernized after 2019. Financial services looks no better. A Deloitte banking survey found that firms underestimate the true total cost of ownership of their legacy systems by 70% to 80%, with real costs landing 3.4 times above the original budget.

At Charles Schwab, Aryasomayajula made the call to replace legacy batch processing with microservices. Performance drove the decision, but its clearest financial result was removing the manual reconciliation overhead that batch systems pile up. That one change produced roughly $2.4 million in annual operating savings, the single largest piece of the $2.6 million total, and it came not from a sweeping transformation program but from one targeted architectural choice.

“The companies that get stuck are the ones running a comparison they never actually put on paper,” says Aryasomayajula. “Modernization has a number attached, so it looks expensive. The status quo has no line item, so it looks free. It isn’t. You pay for it every quarter, in salaries and slow decisions. You just never get an invoice.”

The Productivity Tax

Operating savings are only part of the bill. The harder cost to surface is productivity: the hours staff and citizens spend absorbing the friction of systems that work, but slowly.

In financial services, that tax shows up as transaction throughput and processing latency. In government, it shows up as the days it takes to resolve a citizen complaint or close a regulatory case. These delays rarely get blamed on technology in any public accounting; they get absorbed as the normal pace of institutional work. But they have a source, which means they can be fixed.

“Government systems are different from commercial ones in one way that matters,” he says. “In a business, a slow platform costs you customers, and customers are a number leadership watches. In government, the people stuck with that system can’t take their business elsewhere. The cost is just as real, but nobody is watching a churn rate, so it sits there for years.”

His government work attaches hard numbers to that source. At the Maryland Insurance Administration, rebuilding the complaint platform’s workflow engine and restructuring how cases moved across 15 departments cut average resolution time by 38% for more than 1,800 internal and 50,000 external users. At the Maryland Department of Transportation, modernizing the core operations platform cut page-load times by 73% and database query times by 68% for over 1,200 daily users, a gain that compounds with every session. At the Maryland Department of the Environment, he migrated more than 2.5 million records off a two-decade-old permit system at 99.95% accuracy, letting the agency finally retire infrastructure it had been patching for years.

The Compounding Deficit

Technical debt is the least visible cost of all, and it goes unnoticed for the same reason: it doesn’t look like a problem until something has to change. Then it surfaces as a codebase whose structure has gone opaque under years of workarounds, where fixing one thing means tracing what it might do to five others. There is no single incident to point at. The cost is simply that everything after it gets harder.

This is where the deficit compounds. A badly architected system does not get cheaper to change as it ages; the distance between what it is and what a modern replacement has to be widens with every year the investment is put off.

At the Maryland Insurance Administration, Aryasomayajula drove the code-quality work, setting review standards and enforcement patterns that brought production bugs down 67% and lifted the maintainability score from 42% to 89%. That last number is the one to watch. At 42%, changes are slow, expensive, and risky; at 89%, they are not. An organization’s ability to adapt and modernize rises directly with the quality work already banked.

“People hear ‘technical debt’ and treat it as a metaphor,” says Aryasomayajula. “It isn’t. It behaves like real debt, and it charges interest. Every month you carry a low-maintainability system, the principal on the eventual rebuild goes up, and you have less room to move when the bill finally comes due.”

The case for modernization has usually been argued in technological terms, scalability, security, and integration, and it tends to lose the budget meeting, because those words don’t convert cleanly into dollars. The frame that does convert is blunter: what is the current state costing right now, in maintenance overhead and in the compounding price of deferred quality?

Aryasomayajula’s work across financial services and state government is one documented answer: $2.6 million returned not through a transformation program but by treating each modernization call as a financial calculation. The organizations still putting that calculation off are running the same arithmetic in reverse, paying for legacy infrastructure slowly, in ways that never land on a single report. Across an industry, the total is not small.