Legacy systems meet AI: How dedicated teams are changing COBOL modernization in 2026

The scale of the challenge

The numbers remain staggering. An estimated 250 billion lines of COBOL remain in active production worldwide, powering systems that process trillions of dollars in transactions daily. Roughly half of organizations that rely on mainframe systems report being unable to fill open COBOL positions, with salaries rising fast and the talent pool shrinking. The average COBOL developer is well into their fifties, and according to the Deloitte Mainframe Modernization Report, by 2027 the majority of experienced COBOL engineers will have retired.

This is not merely a staffing inconvenience. It is an existential challenge for the enterprises that depend on these systems. Every retirement takes with it decades of undocumented institutional knowledge — the “why” behind business rules that were implemented thirty years ago, the edge cases that were discovered through painful production incidents, and the implicit dependencies that exist nowhere except in the memory of the people who built them.

For most organizations, the result has been paralysis. Legacy system modernization projects were historically so expensive and risky that doing nothing felt like the safer option. The cost of understanding a legacy codebase often exceeded the cost of rewriting it, which meant modernization never got past the planning stage.

How AI changes the equation

The breakthrough is not that AI can write better code than COBOL developers. It is that AI can read COBOL — quickly, systematically, and at a scale that no human team could match.

Modern AI coding tools like Claude Code and GitHub Copilot can now perform tasks that previously required teams of specialized consultants working for months. As Anthropic detailed in February 2026, these include mapping dependencies across thousands of programs and copybooks, generating documentation from source code that was never properly documented, identifying implicit coupling through shared data structures, file operations, and global state, and producing translation drafts that serve as starting points for human engineers.

The key insight is that AI changes who needs to be the expert, not whether expertise is needed. A dedicated development team of skilled software engineers — people who may never have written a line of COBOL — can now work effectively with legacy codebases because AI handles the comprehension layer. Business logic validation, infrastructure decisions, system integration, and final accountability still require experienced humans.

Independent benchmarks from TechChannel and Swimm put AI comprehension of COBOL at roughly 69–86% on small programs and 24–35% on large ones. In the engagement model we describe below, that translates into roughly 70% comprehension on day one, improving to approximately 90% within three months as accumulated knowledge — RAG corpora, client copybook libraries, and incremental model improvements — compound. This is not perfection, but it is enough to make AI legacy migration projects viable where they were previously not. Practitioners at Thoughtworks have made the same point from the other direction: AI augments the existing modernization toolchain rather than replacing it, and SME involvement remains essential.

Why the traditional approach falls short

The conventional model for COBOL modernization has always been consultant-heavy: bring in a large team of mainframe specialists, spend months (or years) mapping the system, produce a migration plan, and then execute it with a different team. This approach has several well-known problems.

First, there are simply not enough COBOL specialists available. The talent pool is shrinking every quarter, and the competition for remaining experts drives costs to a level that makes many projects financially unviable.

Second, knowledge transfer is inherently lossy. The consultants who analyze the system are rarely the same people who execute the migration. Critical context gets lost in handoffs, and the resulting modern system often fails to capture edge cases that the legacy system handled silently.

Third, the “big bang” migration approach — where the entire system is replaced at once — carries catastrophic risk. Thirty years of accumulated business logic cannot be safely replicated in a single release. When these projects fail, they fail spectacularly.

A different model: Dedicated teams with AI

The alternative is an approach built around three principles: dedicated development teams that build deep product knowledge over time, AI tools that replace the need for large COBOL specialist teams, and phased engagement that proves value before scaling.

The team structure

A lean team of two to three engineers can cover the Discovery and Stabilize phases of a legacy system modernization engagement. This typically includes an AI/ML engineer who manages the RAG pipeline, local model deployment, and prompt engineering; a Java or modern-language developer who builds API wrappers, target microservices, and integration tests; and an architect or lead who makes modernization decisions per module and validates AI output against business logic.

This small team works because AI replaces the need for a large COBOL team upfront. The deterministic parser combined with a local LLM handles code comprehension that previously required three to four senior COBOL developers. One architect who can read AI-generated documentation is sufficient to validate. The team starts lean, proves value in Discovery, and scales only when the client approves full migration.

The role of the Product Owner

In this model, the client’s Product Owner plays a critical role — not as a COBOL expert, but as a domain expert. They validate business logic (“is this output correct?”), own priorities and acceptance criteria, and serve as the human validation layer that ensures the modernized system behaves exactly as the legacy system did. They do not need to read COBOL. They need to understand what the system is supposed to do.

The COBOL subject matter expert

For engagements that involve mainframe infrastructure — JCL, CICS, DB2, VSAM — a COBOL subject matter expert is brought in on demand, not full-time. This is the only addition to the standard team model. Their role is knowledge transfer to the AI-augmented team, not ongoing development.

How it’s governed

AI-assisted modernization without clear governance is a recipe for uncontrolled risk. The engagement runs on three interlocking feedback cycles. The Customer/PO cycle defines priorities, scope, and acceptance criteria — the client owns the development cadence and provides timely decisions. The Squad Leader cycle drives impediment removal and continuous improvement across the team, enhanced by an embedded AI Coach. The Business cycle — involving Branch Directors and Heads of Department — negotiates priorities and team setup with the customer and owns the AI transition framework.

Every AI-generated change goes through sprint-level transparency and quality gates before it reaches production. 

These cycles operate within an Agile cadence, which means problems surface in days, not months. Every AI-generated change goes through sprint-level transparency and quality gates before it reaches production. The governance model is not new — it is the same structure Axon Active uses across all its engagements, extended with AI-driven enablement. That is the point: legacy system modernization should not require a new governance framework. It should run on a proven one.

The privacy question: Cloud vs. local AI

For regulated industries, the hybrid on-premise approach is the only viable path. 

For organizations in regulated industries — Swiss banking, European insurance, government agencies — sending COBOL source code to cloud-based AI services is often not an option. Data residency requirements under the Swiss FADP, FINMA outsourcing guidelines, and the EU AI Act make this a hard constraint, not a preference. 

The practical answer is a hybrid architecture. Deterministic static analysis runs entirely on-premise, providing full coverage with zero data leakage. A local LLM — running on hardware like the NVIDIA DGX Spark or ASUS Ascent GX10 at approximately $5,000–6,500 one-time cost depending on vendor and region — translates those findings into documentation. A RAG knowledge base built from COBOL standards, IBM manuals, and client-specific copybook libraries supplements the model’s understanding. For components that can be safely anonymized, cloud-based frontier models offer higher capability on complex analysis. 

This approach maps cleanly to governance tiers: deterministic tools at Tier 1, local LLM with RAG at Tier 2, and optional cloud processing at Tier 3. It gives compliance officers a clear framework and gives engineering teams the tools they need.

Phased engagement: De-risk before you scale 

The modernization itself follows a phased approach designed to prove value before asking for significant commitment. This layered model aligns with approaches validated by Bankdata in Denmark with Microsoft and Microsoft’s Legacy Modernization Agents — the same pattern emerging independently across the industry in 2026. 

Phase 0 — Discovery (2–4 weeks). An AI-assisted codebase scan produces an inventory of all programs, copybooks, and JCL. Critical paths are distinguished from dormant code. Documentation is generated directly from source. The deliverable is a risk map and modernization roadmap. This phase answers the question: what do we actually have? 

Phase 1 — Stabilize (ongoing). The legacy system is wrapped with a modern API layer. A test harness is built against existing COBOL behavior. Only small, low-risk changes are made, and every change follows the rule: AI generates, human reviews. 

Phase 2 — Selective Migration (per module). Module-by-module translation begins — typically COBOL to Java. Old and new systems run in parallel (dual-run validation), and decommissioning happens only after proven behavioral equivalence. 

The Discovery phase is the key de-risking step. It is small in scope, low in cost, and high in learning — for both the service provider and the client.

Which scenario fits your system? 

Not every COBOL system needs the same treatment. The practical reality is that most organizations use a mix of approaches: 

Leave it alone — if the system runs reliably, meets compliance requirements, and has maintainers, migration risk may outweigh maintenance cost. AI still adds value here by documenting the system so non-COBOL engineers can understand it. 

Wrap it with APIs — modern REST or message queue APIs around the COBOL backend enable mobile apps and web services to interact with the mainframe without touching its core. 

Strangler fig migration — incrementally replace modules with modern services while old and new run in parallel. Originally described by Martin Fowler, this is the most common approach for mid-tier systems. 

Full rewrite — start fresh in Java or Python, using the COBOL source as a specification. Highest risk, but AI-generated test cases significantly reduce it. 

Modernize the COBOL — upgrade to COBOL 2014+ or GnuCOBOL, running on Linux or cloud infrastructure. Zero translation risk because the code stays COBOL. 

Honest barriers: Key risks & how we address them 

Hidden business logic is addressed through the Discovery phase combined with domain expert sessions to reconstruct intent. The mainframe ecosystem (JCL, CICS, DB2) is handled by scoping the engagement to include infrastructure, not just code translation. AI hallucination risk is mitigated through a strict test harness where no change ships without dual-run validation. Client knowledge gaps are addressed by making knowledge transfer and documentation explicit deliverables. Liability concerns are managed through clear contracts and phased go-live that reduces blast radius. AI context window limits are handled by module-by-module segmentation. 

The security dimension 

One risk that receives too little attention in modernization discussions: migrating from COBOL on a mainframe to Java or Python in the cloud fundamentally changes the security posture. A mainframe system has zero open-source dependencies and a minimal attack surface built on decades of hardening. A modern Java application may pull in hundreds of Maven packages, each with its own transitive dependencies and potential vulnerabilities — 70–90% of which are typically open-source components. 

This is not a reason to avoid modernization. It is a reason to integrate SCA scanning and vulnerability management from the first migrated module, not as an afterthought.

What Axon Active offers

Dedicated team. A committed team that ramps up on your legacy stack and stays. No rotating consultants, no one-off project handoffs, no knowledge walking out the door at the end of a phase. The same engineers who run Discovery are the engineers who run the migration. 

Direct communication. Your domain experts (Product Owner) work directly with our engineers, following the Axon Model™ (hyperlink: Axon Model). No middlemen, no project managers translating between sides, no information loss in the handoff. 

AI Coach embedded in the squad. An AI coaching layer — Claude Code, GitHub Copilot, and Axon’s internal AI frameworks — guides the team through COBOL comprehension, translation, and testing. The tools sit inside the team, not as an external service. 

Monitoring and governance. Sprint-level transparency, quality gates at every phase, dual-run validation before any production change. The same governance discipline that runs across all Axon engagements, extended with AI-specific clauses in the Definition of Done. 

Getting started 

If this direction makes sense for your organization or your clients, the next concrete step is a Discovery agreement — small scope, low risk, high learning for both sides. 

The prerequisites are straightforward: access to the legacy codebase (even read-only is sufficient), one domain expert available for onboarding sessions and business logic validation, and a signed engagement agreement to begin recruitment. Timeline from contract signing to team readiness is typically one to two months. Discovery itself can begin with a small team while the dedicated team ramps up. 

Ready to explore AI-assisted legacy modernization? Get in touch with our team to discuss how a Discovery phase can map your modernization path — with minimal commitment and maximum clarity. 

This article is part of a series. See also AI Changes the Practice. The Scrum Team Stays. — the companion piece on how Axon Active organizes AI-augmented software development teams across all engagements, not just legacy modernization. (Link will be live once the companion article is published — content team to insert the live URL at publication.)

Sources and further reading 

All sources used in this article, with direct links to the original research and primary documents. 

COBOL landscape

• Reuters (2017) — “Banks scramble to fix old systems as IT cowboys ride into the sunset.” Original source for the 250 billion lines of COBOL figure widely cited in the industry. 

• Open Mainframe Project — Linux Foundation collaborative project. Co-source for COBOL line counts and mainframe ecosystem statistics. 

• Micro Focus — COBOL line count survey (2022). Industry survey on global COBOL deployment. 

AI capabilities and benchmarks

• Anthropic — “How AI Helps Break the Cost Barrier to COBOL Modernization” (February 2026). The blog post that triggered the broader 2026 conversation about AI and COBOL modernization economics. Companion Code Modernization Playbook. 

• Thoughtworks — “Claude Code and COBOL modernization: What’s the reality?” (March 2026). Practitioner perspective on what AI tools augment and where SME involvement remains essential. 

• TechChannel / Swimm — “Can Claude Code Really Understand COBOL?” (March 2026). Independent benchmarks: 69–86% comprehension on small COBOL programs, 24–35% on large programs. Source for the day-1 / month-3 comprehension framing in this article. 

Modernization methodology

• Microsoft DevBlogs — “How We Use AI Agents for COBOL Migration and Mainframe Modernization” (July 2025). Microsoft Global Black Belt collaboration with Bankdata (Denmark) — the COBOL Agentic Migration Factory (CAMF) reference architecture. 

• Microsoft / Bankdata — Legacy-Modernization-Agents (GitHub, aka.ms/cobol). Open-source reference implementation of the CAMF approach. 

• Martin Fowler — Strangler Fig Application. The original pattern description; the basis for incremental module-by-module migration. 

• AWS Prescriptive Guidance — Strangler Fig pattern. Practical implementation guidance. 

• GnuCOBOL Project. Modern open-source COBOL compiler — the basis for the “modernize the COBOL” option. 

Hardware and infrastructure

• NVIDIA — DGX Spark. GB10 Grace Blackwell desktop AI system; reference platform for on-premise local LLM deployment. 

• ASUS — Ascent GX10. Partner SKU built on the same GB10 reference design. 

• ServeTheHome — DGX Spark review (March 2026). Hardware benchmarks and real-world performance characterization. 

Regulatory and compliance 

• FADP — Swiss Federal Act on Data Protection. The Swiss data protection law, in force since September 2023. Particularly relevant for our Swiss client base. 

• FINMA — Swiss Financial Market Supervisory Authority. Operational risk and outsourcing guidelines (Circular 2018/3) governing how Swiss financial institutions can engage external service providers. 

• EU AI Act — Regulation (EU) 2024/1689. The European Union’s regulatory framework for artificial intelligence; defines risk classification and compliance requirements relevant to AI-assisted modernization in regulated industries. 

• GDPR — General Data Protection Regulation. The European data protection framework. 

Companion article

• Axon Active — AI Changes the Practice. The Scrum Team Stays. The companion piece on how to organize AI-augmented software development teams.

• Axon Active — Why AI Gains Are Real and Your Balance Sheet Doesn’t Show It. The companion piece on AI productivity measurement and flow governance.

Frequently asked questions