{"id":1173,"date":"2025-07-09T17:10:30","date_gmt":"2025-07-09T17:10:30","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/all-things-azure\/?p=1173"},"modified":"2025-07-16T09:17:39","modified_gmt":"2025-07-16T09:17:39","slug":"how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/all-things-azure\/how-we-use-ai-agents-for-cobol-migration-and-mainframe-modernization\/","title":{"rendered":"How We Use AI Agents for COBOL Migration and Mainframe Modernization"},"content":{"rendered":"

Legacy modernization is one of the most frequently raised challenges customers approach us with. They want to eliminate technical debt and run applications cloud-native. Obviously, there are different levels of complexity in legacy modernization, but the most challenging cases remain mainframe languages like COBOL and PL\/1.<\/span><\/p>\n

COBOL still powers mission-critical systems in banking, insurance, and government. Modernizing away from the mainframe comes with increased complexity due to fewer experts, rising maintenance costs, and the loss of institutional knowledge \u2014 and the millions of lines of code certainly don\u2019t help either.<\/span><\/p>\n

Mainframe modernization is still overly reliant on specialized partners and Global System Integrators (GSIs), who dominate the market with their tooling and expertise. Despite existing efforts and tools, mainframe modernization projects are invariably long-term. Most customers we\u2019ve talked to no longer favor an approach led by a GSI or specialized partner. They want to stay in control of their intellectual property, project progress, and costs \u2014 choosing their own partners or leveraging in-house expertise.<\/span><\/p>\n

One example that illustrates this shift in modernization approach is Bankdata.<\/span><\/p>\n

\"BankData<\/a><\/p>\n

Bankdata<\/strong><\/a> is a technology company established by a consortium of Danish banks. It provides comprehensive IT platforms and services to its eight member banks, which together represent over 30% of the Danish banking market. Having existed since the 1960s, this includes tech stacks all the way from traditional mainframe workloads to modern cloud and cloud native compute platforms, all supporting critical financial services in Denmark.<\/span><\/p>\n

Almost all newer development in Bankdata is aimed towards cloud and cloud-native platforms, however over 70 million lines of code still exist on the mainframe today. While most of those systems are a good fit for the mainframe, some are not and would benefit from being re-platformed. Historically however, doing so has been a tremendous manual, time-consuming and costly affair.<\/span><\/p>\n

But even before discussing re-platforming, there\u2019s a critical question: is the COBOL code actually modernizable?<\/strong><\/span><\/p>\n

Many COBOL modules aren\u2019t just about business logic \u2014 they\u2019re deeply tied to the non-functional behaviors of the mainframe: batch throughput, I\/O handling, JCL orchestration, strict SLAs. These characteristics are hard to replicate and can\u2019t be handwaved away.<\/span><\/p>\n

That\u2019s why we don\u2019t treat all COBOL as equally \u201cmigratable.\u201d Some modules need a redesign. Others demand a smarter, critical look at their non-functional dependencies \u2014 not to avoid modernization, but to approach it thoughtfully.<\/span><\/p>\n

It\u2019s a dimension we\u2019re still actively exploring \u2014 and we believe it deserves just as much attention as the code transformation itself.<\/span><\/p>\n

Rethinking COBOL Modernization with Agentic AI<\/span><\/h2>\n

With the development of incrementally capable Large and Small Language Models and the rise of AI agents, we saw a chance to tackle this inhumane problem of mainframe migration from a fresh and hopefully more successful angle.<\/span><\/p>\n

In the context of early technical development, our first iterations began at the end of 2024 with simple back-and-forth chat interactions with GPT-4, later exploring the integrated coding experience through GitHub Copilot and its dedicated coding LLMs. We faced massive challenges: limited token windows led to loss of relevant context, and the general capabilities of language models to understand COBOL were very limited. We ended up with a good mix of educated guesses (from us and the model) and hallucinational gibberish.<\/span><\/p>\n

A positive side effect of our early experimentation was that it forced us to spend dedicated time thinking about how to structure and orchestrate a migration approach \u2014 which helped immensely as we began prompting different worker and orchestration agents.<\/span><\/p>\n

From this, we abstracted a set of key steps (though the exact order may vary between use cases):<\/span><\/p>\n

Preparation<\/span><\/h3>\n