COBOL Is Not the Problem

Blog 1 of this series argued that AI-assisted modernization is now constrained less by artifact generation than by production proof. The enterprise question is no longer whether a tool can explain code, produce documentation, or generate a target artifact. The question is whether the modernized system can be proven functionally equivalent, operationally resilient, auditable, and safe to cut over. Blog 2 moves to the first practical reason that proof often collapses: language coverage.

In many modernization evaluations, the initial COBOL conversion pilot works exactly as expected. The pilot slice looks promising. The dashboard shows progress. Then the full inventory surfaces the actual production estate: COBOL programs surrounded by Assembler routines, PL/I utilities, Easytrieve reports, Telon-generated code, JCL procedures, SAS jobs, REXX scripts, IMS transactions, Db2 schemas, access paths, and embedded SQL logic, VSAM files, and platform-specific dependencies that were never included in the pilot scope.

That is where many modernization programs stop being a code-conversion exercise and become a production-risk problem.

The uncomfortable truth is simple: modernization programs rarely fail because of the language validated during the initial pilot. They fail later when the production estate exposes languages, data structures, job flows, and operational dependencies the platform cannot parse, transform, validate, and certify.

COBOL is not the problem. It is usually the most visible part of the problem. The hidden problem is the surrounding estate.

COBOL remains central to many mission-critical systems. It is still deeply embedded in legacy mainframe systems in banking, insurance, healthcare, government, and high-volume transaction processing. IBM describes mainframes as systems designed to process up to 1 trillion web transactions daily, and mainframe environments continue to support workloads requiring high security, reliability, and resiliency.

Yet an enterprise estate is almost never pure COBOL.

A core banking application may express business rules in COBOL, invoke performance-critical Assembler routines, orchestrate nightly processing through JCL, store account data in Db2 databases or VSAM datasets, use IMS or CICS for transaction processing, generate regulatory reports through Easytrieve or SAS, and depend on REXX scripts or operational procedures that only a small group of experienced specialists still understands. A public-sector benefits platform may add Telon, PL/I, hierarchical database dependencies, batch restart logic, and decades of exception handling accumulated through successive policy changes.

In that environment, COBOL conversion is not modernization. It is one workstream inside a larger controlled transformation.

This matters because any gaps create chain-of-custody gaps. If a platform can analyze COBOL but cannot parse the JCL that controls execution, the dependency map is incomplete. If it can refactor business logic but cannot certify the Assembler routine that handles a performance-critical calculation, the evidence package is incomplete. If it can convert application code but cannot reconcile IMS, Db2, or VSAM behavior, the production proof is incomplete. And if the evidence is incomplete, the cutover decision is not governed; it is a bet.

For a GSI or CSP leading the program, that gap is not academic. It becomes schedule exposure, margin exposure, reputational exposure, and ultimately customer-risk exposure.

The major technology providers are not ignoring the problem. AWS Transform for mainframe supports modernization of z/OS mainframe applications written in COBOL with associated JCL, CICS transactions, BMS screens, Db2 databases, and VSAM data files. IBM watsonx Code Assistant for Z documentation states that it can explain COBOL, PL/I, REXX, Assembler, and JCL, refactor COBOL and PL/I, transform COBOL to Java, and validate Java equivalence. AWS has also published material on converting Assembler programs to COBOL, explicitly linking that capability to modernization and Assembler skills risk.

These are meaningful advances. They show that the market understands modernization cannot remain COBOL-only. They also reveal the larger issue: support for a language is not the same as the ability to transform, validate, and certify it within a complete production migration program.

A platform may explain a language without transforming it. It may transform one language but only document another. It may handle analysis but not data migration. It may generate target code but rely on separate testing, separate reconciliation, separate release governance, and separate post-cutover operations. It may support IBM Z but not Unisys or Bull GCOS8. It may work well on a clean subset of source assets but struggle when the real estate contains generated code, embedded macros, undocumented copybook variants, unusual control flow, or platform-specific operational procedures.

The enterprise buyer does not experience those distinctions as product-scope nuance. The buyer experiences them as delay, remediation, change orders, additional vendors, parallel workarounds, and delayed cutover confidence.

For systems integrators and cloud providers, the consequence is more direct: if the modernization platform cannot certify the full language profile, the delivery partner owns the failure mode. The customer may not blame the tool. The customer blames the transformation program.

A mixed estate is not a list of languages and data structures. It is a map of runtime behavior.

COBOL may own the transaction logic. JCL may control sequencing, dependencies, condition codes, restart behavior, and execution windows. Assembler may provide performance-sensitive routines, operating-system interfaces, custom utilities, or legacy integration points. PL/I may sit inside older financial, insurance, or government workloads. Easytrieve and SAS may produce reports that executives, regulators, and downstream systems still treat as authoritative. REXX may automate operational tasks. IMS databases, Db2 schemas, VSAM datasets, and related data structures may encode access patterns and business assumptions that the application code only partially reveals.

If any of those layers are outside the modernization scope, the program has three unattractive options.

First, leave the component behind and build an interface around it. That preserves dependency on legacy skills and creates a permanent boundary condition for future releases.

Second, rewrite the component manually. That increases time, cost, and risk precisely in the areas least likely to be fully documented.

Third, use a separate tool or vendor for the unsupported component. That introduces integration seams, inconsistent evidence, and fragmented accountability.

None of these options is fatal in isolation. In a large estate, repeated across hundreds or thousands of components, they become the reason modernization programs stall.

The coverage problem is not limited to technology support. It is also a knowledge problem.

Enterprise modernization depends on knowledge that rarely appears in public repositories: decades of coding conventions, generated code patterns, customer-specific copybook structures, proprietary batch designs, database access strategies, hand-optimized Assembler routines, industry-specific exception handling, and operational procedures accumulated over years of production use.

General-purpose AI models are useful for code explanation, documentation, pattern recognition, and developer assistance. However, they are trained primarily on publicly available information. Enterprise modernization programs depend on knowledge that is often private , organization-specific, and deeply embedded within production systems.

This is where domain-specific AI can add value. Models aligned to enterprise modernization patterns can improve understanding, accelerate analysis, and help recover business rules from complex application estates.

However, AI alone does not make the modernization output certifiable. Certification requires a governed path from source artifact to transformation decision to validation result to release evidence.

In other words: domain-specific AI can improve the modernization analysis and transformation. Deterministic pipelines and automated validation provide the evidence needed to make the result production-grade.

Blog 1 established that production proof depends on deterministic execution, automated validation, and evidence packages. Blog 2 adds a sharper requirement: those controls must apply across the full estate profile, not only the primary application language.

A deterministic COBOL pipeline paired with a manual PL/I workaround still leaves a control gap. A validated Java target with unvalidated JCL conversion still leaves an operational gap. A transformed application with partially reconciled data behavior still leaves a production gap. A clean technical conversion that cannot document what happened to Easytrieve reports, SAS jobs, REXX scripts, or Assembler routines still leaves an audit gap.

Determinism is valuable only if it covers the components that determine business behavior.

That does not mean every artifact must follow the same modernization pathway. Refactor, replatform, reengineer, rehost, replace, retire, or encapsulate decisions may vary by component. But every decision must be governed. Every retained dependency must be documented. Every converted component must be validated. Every exception must be visible in the evidence package. Every output that affects business results must be reconciled.

This is where broad language coverage becomes more than a technical feature. It becomes the condition of program completion.

The most dangerous modernization outcome is not an outright failed conversion. It is a partial conversion that looks successful enough to declare progress but leaves the enterprise with a more complex operating model than before.

The application has moved, but critical batch logic remains behind. The UI has changed, but reporting still depends on an unmigrated tool. The core logic was refactored, but a performance-sensitive Assembler routine is wrapped rather than transformed. Data has been relocated, but reconciliation rules are not fully proven. Operations has a modern pipeline for some components and a legacy manual process for others.

The result is not a completed modernization. It is relocated technical debt.

Relocated debt is harder to see because the program can claim cloud progress. It is harder to fund because the migration budget has already been spent. It is harder to operate because the new architecture contains hidden dependency boundaries. It is harder to change because every future release must navigate the seam between modernized and unmigrated components.

For enterprises, this erodes the business case. For GSIs, it damages delivery credibility. For CSPs, it delays workload expansion and downstream consumption. For software vendors, it limits the ability to position AI modernization as a repeatable enterprise solution. The economic risk is clear: incomplete coverage converts an automation opportunity into a long-term services liability.

The industry often describes mainframe modernization through a talent-shortage lens. That is accurate but incomplete. IBM has stated that the mainframe skills crisis is real as experienced systems experts leave the workforce. Open Mainframe Project initiatives continue to focus on training the next generation of COBOL and mainframe talent.

The deeper risk is loss of institutional knowledge, i.e. training new developers does not automatically recover decades of enterprise-specific knowledge.

The specialists who understand Assembler exits, PL/I utilities, JCL restart logic, Easytrieve reports, IMS transaction behavior, and production workarounds are not just programmers. They are the institutional memory of the enterprise. When they leave, the organization loses context about why the system behaves the way it does, not merely how the code is written.

Modernization can either preserve that knowledge or destroy it.

A narrow platform that only converts the most visible component accelerates part of the problem while leaving the hardest knowledge trapped in the components it cannot handle. A governed, broad-coverage modernization approach externalizes that knowledge into dependency maps, recovered business rules, test evidence, reconciliation results, operational runbooks, and release packages.

That turns modernization into a knowledge-transfer strategy, not just an application-transformation strategy.

Technical executives, GSI modernization leaders, CSP partner teams, and enterprise architects should evaluate coverage before committing to a modernization plan. The right questions are specific:

• Which components and artifact types can the platform parse, transform, validate, and certify, not merely inventory or explain?
• What is the unhandled pattern rate on our actual production codebase, including generated code, macros, copybooks, job streams, reporting tools, database calls, and operational scripts?
• How does the platform handle Assembler, PL/I, Easytrieve, Telon, JCL, SAS, REXX, IMS, Db2, VSAM, and source-platform dependencies such as GCOS8 / Bull?
• Can the evidence package trace each transformed component back to source artifacts, business rules, validation results, approvals, and release decisions?
• Where the platform cannot transform a component, what is the governed disposition: retire, retain, encapsulate, replace, rewrite, or migrate through a specialist process?
• How are mixed-language transaction paths, batch sequences, restart procedures, data mappings, and downstream reports validated under production-representative conditions?
• Who owns the delivery risk when coverage gaps appear: the tool vendor, the GSI, the cloud provider, or the customer?

These questions expose the difference between modernization scope and modernization readiness. A vendor may have a convincing COBOL story. That is not enough. The real test is whether the platform can produce controlled evidence across the full estate language profile.

If language coverage is a prerequisite for production proof, modernization platforms must be designed around the full estate rather than the primary application language. Discovery, transformation, validation, governance, and post-cutover operations must remain connected across the entire modernization lifecycle.

This is the architectural problem mLogica’s modernization architecture is designed to address.

LIBER*M supports deterministic mainframe modernization across complex legacy estates. STAR*M extends the same modernization discipline to distributed workloads. TRAK*M provides validation, governance, and managed-operations controls to prove and sustain the result after cutover.

The critical point is architectural, not promotional. The value is not that one platform can claim support for more languages. The value is that a dependency identified during discovery remains traceable through transformation, validation, release approval, and production operations. When modernization crosses languages, databases, middleware, generated code, and operational procedures, that end-to-end traceability becomes essential to maintaining proof, accountability, and delivery confidence.

That matters for regulated industries. It matters for system integrators responsible for delivery outcomes. It matters for cloud providers trying to migrate mission-critical workloads without inheriting uncontrolled risk. And it matters for enterprise technology leaders who cannot approve cutover until the entire transaction path, not just the COBOL segment, has been proven.

For GSIs and CSPs, the language coverage issue should be treated as a delivery-risk question, not a feature-comparison question.

A modernization platform that cannot certify the full language profile may still be useful. It may accelerate assessment. It may reduce documentation effort. It may support part of a migration factory. However, if there are any unsupported or partially supported components, the GSI or CSP is still accountable for the resulting discovery risk. That risk may first surface as a failed cutover, triggering customer escalation and unplanned remediation effort, which in turn can delay cloud consumption and ultimately erode project margins.

The strategic question is simple: if a modernization platform cannot certify the full language profile, why should the GSI or CSP assume the delivery failure when specialized coverage for unsupported components already exists?

The next phase of modernization will not be won by the broadest AI claim or the cleanest initial COBOL conversion pilot. It will be won by the ability to prove transformation across the actual estate: the languages, data stores, job flows, reports, scripts, interfaces, and operational dependencies that keep the business running.

COBOL will remain important. But the future of enterprise modernization will be decided by what happens around COBOL.

The vendors, integrators, and cloud platforms that understand this will build modernization programs around full-estate coverage, deterministic execution, continuous validation, and release evidence. Those that do not will continue to discover the same failure pattern late in the program: the visible language converted, the hidden estate did not, and the cutover proof still cannot be signed.

AI can accelerate modernization. Broad language coverage determines whether modernization can finish. Evidence determines whether it can ship.

Part 3 of this series will examine the next layer of the problem: why deterministic AI and generative AI must play different roles in production modernization, and why confusing those roles creates avoidable risk.

The following categories are not exhaustive, but they illustrate why estate coverage must be evaluated as a control issue rather than a check-box feature.

Every layer in the estate contributes to production readiness. The challenge is not converting the most visible components, but proving that the entire estate remains correct, complete, and ready for production after modernization.

Peter Burney is Senior Vice President of Strategic Programs at mLogica, where he leads enterprise growth initiatives spanning go-to-market strategy, executive partnerships, strategic alliances, and cross-divisional programs. He has been central to mLogica’s evolution as a governed AI modernization platform company. His work spans strategic engagements with global systems integrators, cloud platform providers, and regulated-industry enterprises across financial services, insurance, and government, organizations for which the governance and evidence standard described in this series is not optional.

Peter has more than three decades of multidisciplinary executive experience across software, telecommunications, financial services, manufacturing, healthcare, and related technology markets, with a particular focus on the governance and operational discipline required to modernize mission-critical enterprise systems.

1. IBM, "What Is a Mainframe?":
   https://www.ibm.com/think/topics/mainframe
2. AWS, "Modernization of mainframe applications - AWS Transform":
   https://docs.aws.amazon.com/transform/latest/userguide/transform-app-mainframe.html
3. IBM, "About IBM watsonx Code Assistant for Z":
   https://www.ibm.com/docs/en/watsonx/watsonx-code-assistant-4z/2.x?topic=welcome-about-watsonx-code-assistant-z
4. AWS, "Transform your Assembler programs to COBOL with AWS Mainframe Modernization":
   https://aws.amazon.com/blogs/migration-and-modernization/unlocking-new-potential-transform-your-assembler-programs-to-cobol-with-aws-mainframe-modernization/
5. IBM, "Boosting Mainframe Skills with AI":
   https://www.ibm.com/new/product-blog/mainframe-skills-ai
6. Open Mainframe Project, "COBOL Working Group":
   https://openmainframeproject.org/our-projects/working-groups/cobol-working-group/
7. The Register, "AI-powered mainframe exits are a bubble set to pop":
   https://www.theregister.com/on-prem/2026/04/15/ai-powered-mainframe-exits-are-a-bubble-set-to-pop/5220040
8. mLogica, "ISG Provider Lens Named mLogica as a Leader in Mainframes, Solutions":
   https://www.mlogica.com/about-us/news/isg-provider-lens-named-mlogica-as-a-leader-in-mainframes--solutions