Why AI Alone Is Not Enough to Transition Your Bank Off Mainframes

Software Engineer Unni Siva Sankar, who has nearly two decades of mainframe migration experience across major US financial institutions, on why human expertise remains irreplaceable in COBOL-to-cloud transformations

Menlo Ventures’ “State of Generative AI in the Enterprise” report shows that 76% of AI use cases in enterprises are currently purchased rather than built in-house, compared to 53% in 2024. This shift reflects companies recognizing that building specialized AI capabilities internally often takes longer and costs more than acquiring external expertise. Yet for one of enterprise IT’s most complex challenges, mainframe modernization, ready-made AI solutions don’t exist. Financial institutions face a particularly challenging version of this problem: migrating decade-old mainframe applications to modern cloud platforms while processing millions of transactions daily without downtime.

Unni Siva Sankar spent 19 years performing just such migrations at Nordstrom and Wells Fargo, delivering millions of dollars in annual savings by eliminating IBM licence fees while maintaining zero defects in regulatory compliance. His unusual expertise, fluency in both 1970s COBOL and modern Golang microservices, backed by AWS Solutions Architect and Azure certifications, makes him one of the rare professionals capable of bridging the skills gap that stalls most enterprise modernisation initiatives.

We spoke with Sankar about why AI-powered code transformation tools still require human expertise, what makes tax season the most brutal test for any financial system, and how his work on building Kerala’s first private hydroelectric plant connects to reducing computing’s carbon footprint.

Businesses’ spending on artificial intelligence upgrades is rising, but most projects to migrate legacy systems still fail before reaching production. When converting a 30-year-old COBOL credit processing system that handles billions of transactions, what is the most dangerous assumption companies make about using artificial intelligence tools to accelerate migration?

I saw projects fail because teams trusted AI-generated transformations without understanding that the original COBOL wasn’t just processing transactions — it was encoding decades of institutional knowledge about fraud patterns, regulatory exceptions and modern cloud-native design. I’ve seen projects fail because teams trusted AI-generated conversion without understanding that the original COBOL wasn’t just processing transactions – encoding decades of institutional knowledge about fraud patterns, regulatory exceptions, and edge cases that nobody documented. You need a human who can read both the old code and the compliance requirements.

Most developers avoid legacy technologics, preferring to work with new tools. In 2006, you took a different path by choosing to master COBOL, JCL, and Endevor – legacy mainframe technologies that most developers were abandoning. What did you see that others didn’t?

I noticed that all large financial institutions were completely dependent on mainframe systems to perform critical operations: credit card processing, transaction settlements, reporting to regulators and the people who understood these systems were getting older. It was obvious that companies would eventually have to modernise, but they would face an obstacle because no one would be able to read the existing code well enough to migrate it safely. Studying COBOL, JCL, and Endevor meant recognising that the rarest skill in corporate IT would be the ability to translate between legacy and modern platforms. By 2020, when financial institutions finally decided to move to the cloud, this foundation made me one of the few people who could analyse the business logic of a mainframe system, determine what needed to be preserved and what was obsolete, and develop the right Golang replacement that would not lead to regulatory violations. It takes an institutional understanding of why these systems were built a certain way and how seemingly redundant code actually prevents errors that cost millions of dollars.

Migrating Nordstrom’s credit system saved millions of dollars a year by eliminating IBM licence fees. But during the transition, the old mainframe had to continue processing every transaction flawlessly while you built its replacement. How do you maintain zero defects in a production system that you are actively decommissioning?

You treat it like a passenger plane that needs an engine replacement during flight. I had to demonstrate that we could reproduce every piece of the mainframe’s business logic in Golang microservices without introducing differences in transaction processing. We completely redesigned the processing model from mainframe batch operations to event-driven microservices, while proving that we could maintain transaction integrity under peak loads. The AWS deployment required security and high availability configurations, as any downtime would cost more than the entire project budget. But here’s what complicated the task: I spent my nights debugging production issues in 30-year-old COBOL when mission-critical batch jobs ended in failure, and then spent my days designing the architecture for new cloud services. The outdated system could not be allowed to deteriorate – business operations depended on its ability to process millions of transactions daily without a single error. Most organisations cannot find people who can operate effectively in both worlds simultaneously, which is why so many modernization projects stall or fail catastrophically.

At a major financial services company in the U.S. , you managed tax form generation systems during the 2021-2022 tax season. These applications generate forms for millions of customers in accordance with IRS deadlines. What happens when a critical batch job fails, and the forms must be ready the next day?

You have about six hours to identify the root cause, implement a fix, ensure it doesn’t corrupt data, and get the forms back into production because missing deadlines for tax forms means regulatory sanctions and significant fines. Tax season is when you discover what your systems are truly capable of, because peak loads stress-test every component. As a Technology Lead, I was fully responsible for systems that could not fail. This role required deep technical knowledge to debug issues through code-level analysis, as well as leadership skills to coordinate global teams under tight deadlines. When you’re rushing to fix batch processing of tax data for three million customers with only hours left before the deadline, every decision has to be right the first time. In addition to managing crisis situations, I implemented automation to reduce manual work and incident frequency in a highly regulated environment where every code change requires thorough testing.

EBCDIC encoding has been obsolete everywhere except mainframes since the 1980s, but it remains the standard for financial data in these systems. During your work at Infosys, you created your own ETL tool in Golang to automatically perform this conversion. Why couldn’t you just use existing data migration software?

Standard ETL tools treat EBCDIC conversion as a simple character encoding translation, which is a fundamentally flawed understanding of the problem. EBCDIC represents decades of mainframe-specific data structures, packed decimal formats, and binary encodings that have no direct equivalents in modern systems. When transferring credit card data from a mainframe to cloud storage, you are translating data types, processing obsolete field definitions that made sense in 1985, and preserving numerical precision that is critical for financial calculations. Commercial tools either couldn’t accurately handle these conversions or required manual intervention, which led to errors. My Golang ETL pipeline was designed to understand these mainframe data structures, automatically convert EBCDIC files, verify results against known correct outputs, and deliver clean data, reducing what used to take weeks to hours of automated processing with an accuracy unattainable by manual methods.

In 2018, you co-founded Mukkudam Electroenergy to build Kerala’s first private small hydropower plant in the Idukki region, an area known for landslides and geological instability. Given that your design specifically incorporated seismic and landslide resistance measures, what drove you to take on such an engineering challenge, and what’s the connection between solving problems in unstable terrain and your work in mainframe migration?

Engineering challenges have more in common than one might expect. In both cases, you need to understand the existing constraints, whether it’s 30-year-old COBOL or the topology of the Idukki river valley, and develop solutions that work within the real-world limitations. When I identified the site’s potential and conducted the initial feasibility analysis, it was the same problem-solving approach I use for system migration: assessing what is possible given the constraints, and then executing despite scepticism. Securing funding from IREDA required persistence because my co-founders and I were proposing something unprecedented. I redesigned the pipeline system to gain an additional 20 metres of head, which directly increased the power generation capacity. Beyond the engineering work, we incorporated a social objective into the project – we supply 10,000 units of energy per month to the local government hospital in Adimali, providing a reliable power supply for medical operations. The Hindu, Economic Times, and Times of India covered the project because it demonstrated private renewable energy development serving both economic and community needs.

Kerala’s mountainous terrain makes it prone to landslides and geological instability. How did you address the engineering challenges of building a hydropower plant in such conditions, and what broader applications could your approach have for renewable energy infrastructure in geologically sensitive regions?

The Idukki region experiences significant monsoon rainfall and has a history of landslides, which meant we couldn’t simply follow standard hydropower construction practices. We conducted extensive geological surveys and incorporated multiple safety measures into the design: reinforced foundation structures, strategic placement of the intake and powerhouse to minimize terrain risk, and continuous monitoring systems that can detect ground movement or structural stress. The most critical innovation was our approach to pipeline routing by redesigning the path to gain that additional 20 metres of head, we simultaneously chose a route that followed more stable geological formations and reduced exposure to potential landslide zones. This design philosophy of letting natural constraints guide engineering solutions rather than fighting them has broader applications. Many regions with high renewable energy potential: mountainous areas for hydro and wind, seismically active zones for geothermal, face similar challenges. Our project demonstrates that with careful site analysis and adaptive engineering, these geographical challenges can be converted into design advantages. The monitoring systems we implemented could serve as a template for other decentralized energy projects in unstable terrain, particularly in developing regions where renewable infrastructure is needed but geological risks have deterred investment.

In 2024, data centres consumed 4% of the total electricity in the United States, and this figure continues to grow as the adoption of artificial intelligence accelerates. You have experience in both enterprise IT modernisation and renewable energy. As someone with this combination of skills, how do you feel about reducing the carbon footprint of computing?

Modernising outdated systems has direct environmental implications that most people overlook. IBM’s licensing encourages the use of old equipment well beyond its useful life. When we migrated Nordstrom’s credit system to Golang microservices on AWS, we not only saved on licensing fees but also moved to a more energy-efficient infrastructure per transaction. But the picture is complex because it depends on server load, data centre power sources, and whether the cloud provider uses renewable energy sources. AI workloads are extremely energy-intensive, which can offset efficiency gains from other improvements. I am exploring how to apply the same approach I used in IT modernization, understanding both existing infrastructure constraints and cleaner alternatives, to help organisations reduce the energy consumption of computing systems. This could mean optimizing algorithms to require fewer compute cycles, better workload scheduling to leverage renewable energy, or infrastructure design that minimizes cooling requirements. My dual background positions me to work on problems at the intersection of both fields.