Is COBOL still used in 2026? Where it runs, why it persists and what comes next

← All posts

Is COBOL still used? Yes, and not as a museum piece. COBOL still settles bank balances, calculates insurance premiums, pays federal and state benefits and runs the overnight batch cycles that large organizations close their books with as well as many, many more ??? . What has changed is the quality of the conversation around COBOL. Most articles answering this question recycle the same handful of statistics from a single 2017 news graphic, and few explain why the language is so hard to retire.

This post is for CTOs, architects and engineering leads who need a straight answer they can repeat in a budget meeting. You will get dated, sourced evidence (and a frank note on which numbers are stale), a short COBOL program explained for people who have never read one, the engineering reasons COBOL persists, what really happened during the 2020 unemployment-system crisis, and how the 2026 GenAI wave changes the options. It sits inside our complete guide to legacy software modernization, which covers the wider estate.

Key takeaways

• COBOL is still in production across banking, insurance, government benefits and tax, and large back-office operations. The language standard was revised as recently as 2023 and IBM ships Enterprise COBOL 6.5 for current hardware.
• The famous "220 billion lines" and "95% of ATM swipes" figures come from Reuters reporting in April 2017. They are nearly a decade old and should be cited with that date.
• The newest broad estimate (a 2022 vendor-commissioned survey) puts COBOL in daily production at over 800 billion lines, but that is a survey extrapolation, not a count.
• COBOL persists for engineering reasons: native decimal arithmetic, proven correctness, high batch and transaction throughput on IBM Z, and business rules that exist nowhere except the code.
• The realistic paths forward are retain and optimize, wrap with APIs, or translate. A from-scratch rewrite is the riskiest of the options, not the default.

What is COBOL?

COBOL (Common Business-Oriented Language) is a compiled programming language designed in 1959 for business data processing: records, files, money and reports. It uses English-like syntax, fixed-point decimal arithmetic and explicit data layouts. Standardized since 1968 and most recently revised as ISO/IEC 1989:2023, it still runs core systems in banking, insurance and government.

A committee called CODASYL, a consortium of government and business organizations, produced the first version, which was released in 1960. IBM's own explainer, What is COBOL?, summarizes that history and notes that COBOL was one of the first languages standardized by both ANSI and ISO.

The standard is not frozen. ISO published ISO/IEC 1989:2023 on 31 January 2023 as the third edition, replacing the 2014 edition, and the ISO catalog already marks it "to be revised" with a draft successor in progress. Object-oriented features, free-format source, XML and JSON handling and Unicode support have been added over the past two decades, though most production code predates them.

The compilers are not frozen either:

• IBM Enterprise COBOL for z/OS. IBM's Enterprise COBOL product page documents version 6.5, with optimization for the IBM z17 processor, built-in JSON and XML generation and parsing, UTF-8 support and COBOL/Java interoperability. IBM ships fix packs roughly every two months.
• GnuCOBOL. The free GnuCOBOL compiler (latest release 3.2, July 2023) produces native executables on Linux, Windows, macOS and Unix, supports 19 dialects and passes more than 9,740 tests from the NIST COBOL 85 test suite.
• Commercial distributed compilers. Micro Focus and Fujitsu NetCOBOL run COBOL on Windows and Linux, so plenty of COBOL never touches a mainframe.

The risk most organizations face is not the language. It is the age, size and opacity of the specific programs they depend on.

Is COBOL still used? What the data actually says

The short answer is yes. The longer answer is that almost every number you will see quoted has a specific origin, a specific year and a specific methodology, and those details matter if you are going to put the number in a board paper.

The 2017 Reuters numbers, and why you should date them

The most widely repeated statistics trace back to Reuters reporting in April 2017 about U.S. banks struggling to replace retiring COBOL programmers. That coverage, which included an interactive graphic, is the source of four figures you will find in hundreds of articles: 220 billion lines of COBOL in use, 95% of ATM swipes running through COBOL code, 80% of in-person transactions, and an estimated $3 trillion in daily commerce. The New Stack's May 2017 summary of the Reuters findings attributes each figure to Reuters and links the original graphic.

Those numbers have been recycled for almost a decade. IBM's own COBOL explainer, updated in February 2026, repeats the 95% ATM and 80% in-person card figures, citing a 2023 PC Magazine article rather than the 2017 original. That is how stale statistics become permanent: each citation points one hop back, and the date drops off along the way.

If you use these figures, say "Reuters, April 2017." Do not present them as current measurements. The 220 billion figure in particular was itself an estimate, not a count.

The 2022 survey estimate: over 800 billion lines

The newest broad estimate comes from a study that Micro Focus, a COBOL tools vendor, commissioned from research firm Vanson Bourne. According to Vanson Bourne's summary of the COBOL study, published in February 2022, the firm conducted 1,104 interviews across 47 countries with COBOL experts and IT decision makers. Its headline finding was that more than 800 billion lines of COBOL run on production systems in daily use. Ninety-two percent of respondents said their COBOL applications are strategic, and nearly half expected the amount of COBOL at their organization to grow over the following 12 months.

Treat that number with care too. It is extrapolated from respondents' estimates and was commissioned by a company that sells COBOL tooling. It is not a census, but it is directional: organizations that run COBOL are not shrinking their footprint quickly.

Government data from GAO

The most rigorous public evidence comes from the U.S. Government Accountability Office, which names systems, ages and costs.

GAO's 2016 testimony, Federal Agencies Need to Address Aging Legacy Systems, listed COBOL-based systems at Veterans Affairs (a personnel and accounting system reported at 53 years old, and the Benefits Delivery Network at 51), the Department of Justice (a COBOL and Java system at 35 years), and the Social Security Administration's Title II systems (162 subsystems, some written in COBOL). It also listed Treasury's Individual Master File and Business Master File, the IRS taxpayer master files, as assembly-language systems around 56 years old.

In July 2025 GAO returned to the topic with Agencies Need to Plan for Modernizing Critical Decades-Old Legacy Systems. It identified 11 federal systems most in need of modernization, ranging from about 23 to 60 years old and costing roughly $754 million a year to operate and maintain. Eight of the 11 use legacy programming languages, and both of Treasury's selected systems run on COBOL and assembly language, languages GAO describes as having "a dwindling number of people available with the skills needed to support them." Of the 10 systems GAO flagged in 2019, only three modernizations were complete by 2025.

What the evidence supports

Claim	Source and year	How much weight to give it
220 billion lines of COBOL in use	Reuters, April 2017	Historical. An estimate, now nine years old
95% of ATM swipes, 80% of in-person transactions	Reuters, April 2017 (often recycled via newer articles)	Historical. Widely repeated, rarely re-measured
800+ billion lines in daily production	Vanson Bourne for Micro Focus, February 2022	Directional. Survey extrapolation by a vendor-commissioned study
Named federal systems on COBOL, with ages and costs	GAO, 2016 and July 2025	Strong. Specific systems, audited by GAO
COBOL standard and compilers are actively maintained	ISO 2023; IBM Enterprise COBOL 6.5; GnuCOBOL 3.2	Strong. Primary sources

So, is COBOL still used? On the strongest evidence, yes: in named, audited government systems, in compilers still shipped for current hardware and, on softer survey evidence, in very large volumes across financial services. Nobody has a precise global line count.

A simple COBOL program, explained for non-COBOL readers

To see why COBOL is hard to replace, it helps to read some. Here is a small, complete program that calculates one month of interest on a savings balance, written in the fixed-format style most production code uses.

IDENTIFICATION DIVISION.

PROGRAM-ID. INTCALC.

* Calculate one month of interest on a savings balance.

DATA DIVISION.

WORKING-STORAGE SECTION.

01 WS-ACCOUNT.

05 WS-ACCT-ID PIC X(10) VALUE 'SAV0001234'.

05 WS-BALANCE PIC S9(9)V99 COMP-3

VALUE 12345.67.

01 WS-ANNUAL-RATE PIC 9V9(5) COMP-3

VALUE 0.04250.

01 WS-MONTHLY-INT PIC S9(7)V99 COMP-3.

01 WS-DISPLAY-AMT PIC ZZZ,ZZZ,ZZ9.99-.

PROCEDURE DIVISION.

MAIN-PARA.

COMPUTE WS-MONTHLY-INT ROUNDED =

WS-BALANCE * WS-ANNUAL-RATE / 12

ON SIZE ERROR

DISPLAY 'INTEREST OVERFLOW FOR ' WS-ACCT-ID

MOVE ZERO TO WS-MONTHLY-INT

END-COMPUTE

ADD WS-MONTHLY-INT TO WS-BALANCE

MOVE WS-MONTHLY-INT TO WS-DISPLAY-AMT

DISPLAY 'ACCOUNT ' WS-ACCT-ID ' INTEREST ' WS-DISPLAY-AMT

MOVE WS-BALANCE TO WS-DISPLAY-AMT

DISPLAY 'NEW BALANCE ' WS-DISPLAY-AMT

GOBACK.

Run with these values, it prints an interest amount of 43.72 and a new balance of 12,389.39. Here is what each part does, in plain terms.

Divisions. Every COBOL program is split into divisions. The IDENTIFICATION DIVISION names the program. The DATA DIVISION declares every variable and its exact layout before any logic runs. The PROCEDURE DIVISION holds the logic.

Level numbers and records. 01 WS-ACCOUNT is a record, and the 05 items inside it are its fields. The same mechanism describes a 2,000-byte customer record with hundreds of fields.

PIC clauses. PIC (picture) declares the exact shape of a value. X(10) is ten characters. S9(9)V99 is a signed number with nine digits before an implied decimal point and two after. The V takes no storage; the decimal point is tracked by the compiler, not stored as a character. 9V9(5) holds a rate like 0.04250 with five decimal places.

COMP-3. This tells the compiler to store the number as packed decimal: two digits per byte plus a sign nibble. Packed decimal is exact for base-10 values, and IBM Z processors have hardware instructions to do arithmetic on it directly.

COMPUTE ... ROUNDED. The arithmetic is done in decimal, and ROUNDED rounds the result to the two decimal places of the target field (0.5 and above rounds away from zero by default). Without ROUNDED, COBOL truncates the extra digits. Either behavior can be correct; a migration must preserve whichever one the original programmer chose.

ON SIZE ERROR. If the result does not fit in S9(7)V99, this branch runs instead of silently storing a wrong value.

Edited pictures. ZZZ,ZZZ,ZZ9.99- is a display format: suppress leading zeros, insert commas and a decimal point, and show a trailing minus for negative values. Report formatting is baked into the data declaration.

The same calculation in Java, and the gotchas

A careful Java translation looks like this:

import java.math.BigDecimal;

import java.math.RoundingMode;

BigDecimal balance = new BigDecimal("12345.67");

BigDecimal annualRate = new BigDecimal("0.04250");

BigDecimal monthlyInterest = balance

.multiply(annualRate)

.divide(BigDecimal.valueOf(12), 2, RoundingMode.HALF_UP);

if (monthlyInterest.precision() - monthlyInterest.scale() > 7) {

// Equivalent of ON SIZE ERROR for PIC S9(7)V99

System.out.println("INTEREST OVERFLOW FOR SAV0001234");

monthlyInterest = BigDecimal.ZERO.setScale(2);

}

balance = balance.add(monthlyInterest);

Four things are easy to get wrong here. Using double instead of BigDecimal introduces binary floating-point error into money. Constructing BigDecimal from a double literal carries that error in. RoundingMode.HALF_UP matches COBOL's default ROUNDED behavior, but code that omitted ROUNDED needs RoundingMode.DOWN instead. And Java has no built-in equivalent of ON SIZE ERROR for a declared field width, so the check must be generated explicitly. Our guide to mapping COMP-3 and other COBOL data types to Java and C# covers them in depth.

Who still uses COBOL, and for what

COBOL lives wherever a business processes large volumes of structured records against precise rules. Typical patterns, which vary by organization:

Sector	Typical COBOL workloads	Why it tends to stay
Retail and commercial banking	Core deposit and loan accounting, interest accrual, statement generation, end-of-day settlement batch	Decimal precision, regulatory audit trails, extremely high cost of a failed core replacement
Insurance	Policy administration, premium rating, claims adjudication, actuarial feeds	Decades of product rules for policies that are still in force
Government benefits and tax	Benefit eligibility and payment, taxpayer master files, payroll, personnel and accounting	Statutory rules encoded over decades, procurement cycles, public consequences of failure
Airlines and travel	Revenue accounting, loyalty, fare settlement and back-office batch around reservation systems	Integration with older transaction platforms and industry settlement formats
Retail, logistics and payroll services	Inventory and replenishment batch, invoicing, payroll calculation	Batch throughput and stable rules that rarely justify a rewrite

Banking and payments

Core banking systems are the ledger: they hold balances, post transactions, accrue interest and produce statements. In many banks that ledger runs as CICS online transactions by day and a long batch cycle at night, largely in COBOL, with digital channels layered in front.

Insurance

A life or annuity policy written decades ago is still in force and governed by the product rules of the year it was sold. Those rules usually live in COBOL rating and policy-administration programs, often with no separate specification, and a replacement must re-prove every variant.

Government benefits and tax

The GAO reports above show benefit delivery, personnel and accounting, and taxpayer master files on COBOL and assembler. Assembly language is a separate modernization problem; we cover it in our guide to PL/I and HLASM modernization.

Airlines and travel

Airline core reservation processing historically ran on specialized transaction platforms programmed in assembler and proprietary languages such as SabreTalk rather than COBOL, but the business systems around them (revenue accounting, settlement, loyalty and finance) are classic COBOL territory. If your estate includes those proprietary languages, our SabreTalk migration service addresses them directly.

Why is COBOL still used? Five engineering reasons

"Nobody knows how to replace it" is the lazy answer. The real reasons are technical and economic, and they explain why replacement projects fail as often as they do.

1. Correctness that production has already tested

A COBOL program that has run nightly for 30 years has been tested against more real data than any test suite contains. Every edge case that mattered has been hit and fixed; a replacement starts at zero.

2. Decimal arithmetic is native

COBOL declares decimal precision in the data definition and performs exact base-10 arithmetic with explicit rounding and overflow behavior. Java and C# can match it with BigDecimal and decimal, but only if every operation is translated deliberately; floating-point leakage in one program produces penny differences reconciliation teams chase for weeks.

3. Throughput on IBM Z

Mainframe COBOL runs close to the hardware: packed-decimal instructions in the processor, record-oriented I/O against VSAM and Db2, and transaction managers (CICS and IMS) built for very high volumes of short transactions. IBM's Enterprise COBOL documentation highlights that recompiling for the z17 processor can lower CPU use without source changes. A batch window that finishes in four hours on the mainframe has to finish in four hours on the target too, and that is a design constraint, not an afterthought.

4. The rewrite risk is asymmetric

If a modernization works, the business gets roughly the same functionality on a new platform. If it fails, the business can lose customers, regulators' confidence and years of budget. GAO's 2025 finding that most of the federal systems flagged in 2019 were still mid-modernization six years later is a measured example of how long these programs take.

5. Business rules live only in the code

The specification for a 40-year-old system is usually the system. Interest-accrual exceptions, grandfathered fees and state-specific benefit rules were added as code changes without updating any document, so a rewrite team working from interviews will miss some, and the misses surface in production. Before any change, the rules have to be found; our guide to legacy code analysis and business rules extraction explains how that is done systematically.

The 2020 unemployment-system crisis: what actually broke

In spring 2020, pandemic layoffs sent unemployment claims to levels state systems had never been sized for, and COBOL suddenly became national news. New Jersey became the emblem. As CIO Dive reported in an April 2020 analysis of the COBOL scramble, the state's unemployment site failed under load, and the state resorted to rationing applicants' access by Social Security number. IBM responded with an initiative to help technologists learn COBOL quickly.

The popular takeaway was "old COBOL code collapsed." More accurately, several things failed at once:

• Capacity. Systems sized for normal claim volumes were hit with many times that load, and web front ends, middleware and hardware were as much a bottleneck as the COBOL behind them. The same CIO Dive piece quotes a COBOL consultant arguing that "COBOL doesn't fail," and notes that tight state IT budgets had left critical systems on 40-year-old mainframes.
• Rule changes on a deadline. New federal relief programs required new eligibility and payment logic in code few current staff understood well.
• Missing documentation and tests. Where automated regression tests were missing, every change was risky and slow to verify.
• Thin staffing. Too few people knew those specific systems.

The lesson for CTOs is not "COBOL is fragile." It is that a system nobody understands cannot be changed quickly under pressure, whatever language it is written in.

The COBOL skills picture

The skills concern is real, but often overstated in both directions. GAO's 2025 report explicitly flags a dwindling pool of people with COBOL and assembly skills as a risk for Treasury's systems. Experienced mainframe developers are retiring, and university computer science programs rarely teach COBOL.

On the other side, the language itself is not hard to learn. Its syntax is verbose but simple, and training exists: the Open Mainframe Project hosts a free, openly licensed COBOL programming course on GitHub, developed jointly by IBM, IBM clients and American River College, with labs that run against real z/OS. Many organizations successfully train Java developers to maintain COBOL.

The scarcer skill is not COBOL syntax. It is knowledge of a specific system: why a field is redefined three ways, which batch job must finish before another starts, which customer segment the strange branch in program X handles. That knowledge lives in people's heads and in the code, and it leaves when people do. We discuss the staffing side in more detail in our article on the legacy code talent shortage.

The practical response is to capture system knowledge as documentation and tests, invest in automated code analysis so understanding no longer depends on a few individuals, and decide deliberately which applications stay on COBOL rather than letting retirements decide for you.

COBOL and generative AI in 2025 and 2026

The biggest change in the COBOL conversation since 2023 is generative AI. Large language models read COBOL well, and that has produced a wave of products and public claims.

In February 2026, Anthropic published COBOL Modernization with AI: Breaking the Cost Barrier, arguing that understanding legacy code is the most expensive step in modernization and that AI tools can automate much of the exploration: mapping dependencies, documenting workflows and surfacing risks. It argues that AI mainly changes the economics of rewriting, while stressing that engineers must decide priorities and architecture and that migration should proceed one validated component at a time.

Platform vendors are moving the same way. IBM's watsonx Code Assistant for Z offers AI-generated COBOL explanations and COBOL-to-Java conversion with generated unit tests that compare the new Java service with the original program. AWS Transform for mainframe describes agentic AI that assesses codebases, extracts business rules, generates code and produces test plans for functional-equivalence checks.

A neutral reading

There is real value here, and also a real gap.

• Where GenAI is strong: explaining unfamiliar programs, drafting documentation, proposing test cases and helping engineers navigate large codebases, exactly the knowledge-capture problems the 2020 crisis exposed.
• Where caution is warranted: generating the production code itself. LLM output is probabilistic. The same input can produce different output on different runs, and subtle errors in rounding, data layout, file status handling or control flow look plausible in review. At millions of lines, even a small error rate means thousands of defects to find by testing.
• What vendor materials do not provide: independent, published error rates for AI-generated COBOL translations at scale. Ask for measured results on your own code.

We have written about this trade-off before. "93% accurate is a failing grade" looks at what accuracy percentages mean for financial code, and why GenAI alone is not enough for modernization explains where language models fit alongside deterministic tooling. The most productive pattern we see is a hybrid: GenAI for comprehension, documentation and test generation; deterministic, repeatable transformation for the code that must behave identically.

What comes next: retain, wrap or translate

"Is COBOL still used?" usually leads to the real question: what should we do about ours? For most organizations the answer is not one thing. Different applications in the same estate warrant different strategies. Our mainframe migration strategy playbook covers the full decision process; here is the condensed version.

Option	What it means	Good fit when	Main risk
Retain and optimize	Keep COBOL on the current platform; upgrade compilers, tune, reduce cost	Stable application, adequate skills, cost acceptable	Skills and knowledge erosion over time
Wrap with APIs	Expose COBOL transactions and data as REST or event services	Digital channels need access; core logic is sound	Adds a layer; the core still needs people who understand it
Rehost	Move COBOL as-is to distributed COBOL compilers or emulated environments	Hardware or data-center exit is the driver	Same code, new bill; no reduction in complexity
Translate (automated)	Convert COBOL to Java or C# with tooling that preserves behavior	Platform exit, skills risk, need for modern tooling	Unreadable output if the tooling is weak; data-layout fidelity
Rewrite or replace	Rebuild from requirements, or buy a package	The business process itself must change	Lost business rules, long timelines, high failure rates

Retaining COBOL is a legitimate strategy: upgrading to a current compiler, recompiling for current processors, removing dead code and tuning batch can cut cost without changing behavior, as our article on reducing MIPS without leaving the mainframe explains. Wrapping with APIs unblocks digital teams quickly but leaves the knowledge problem underneath. When the driver is a platform exit or a skills cliff, automated translation to Java or C# preserves behavior while changing the platform; output readability and decimal fidelity decide whether the result is maintainable.

A five-step way to decide

• Inventory. Count programs, copybooks, JCL, data stores and interfaces, and identify the non-COBOL pieces (assembler, PL/I, utilities, schedulers).
• Measure. Find dead code, clones, change frequency and complexity hotspots with automated analysis rather than interviews.
• Classify. For each application, decide whether it is stable and cheap to retain, needs access (wrap), or needs to move (translate or replace).
• Prove. Run a pilot on a representative slice and compare outputs record by record against production.
• Sequence. Order the work by business value and dependency, and keep the riskiest core components for when the method is proven.

How deterministic translation handles COBOL migration

Modernize Software's approach to COBOL modernization is built on DMS, the Design Maintenance System, a program-transformation engine Semantic Designs has run in production since 1995. Instead of predicting output the way a language model does, DMS parses the source with a full grammar for the specific COBOL dialect, builds control-flow and data-flow models, and applies explicit rewrite rules to produce Java or C#. The company reports that DMS parses 13 to 15 COBOL dialects.

In practice, that means:

• Determinism. The same input produces the same output on every run, so a fix to a rule fixes every instance, and a re-run months later produces identical code.
• Data fidelity. PIC clauses, COMP-3 fields, REDEFINES and rounding behavior are mapped by rules, not inferred case by case.
• Flagged exceptions. According to the company, constructs that cannot be translated deterministically are flagged for engineer review rather than guessed.
• Ownership. The customer owns the output code, with no runtime royalties, and the tooling can run on-premise.

The limits are real. A deterministic translator reproduces the behavior of the original, including its design; a different target architecture is additional work after translation, though behavior-equivalent code is a safer starting point than a blank page. Dependencies on CICS, file-status handling or assembler subroutines need explicit mappings the team must agree on. GenAI still has a role: the team uses it around the translation for documentation, analysis, business-rule extraction and test generation, not to write the translated code.

Case example: a NetCOBOL application moved to C#

One of Modernize Software's published case studies involves an unnamed financial services firm running a Fujitsu NetCOBOL application with embedded SQL. The company reports that the application, over 500,000 lines, was converted to C# in under six months. It is a reminder that "COBOL modernization" often means leaving a distributed COBOL runtime, not z/OS.

The harder part of a project like this is rarely the procedural logic. It is the embedded SQL, the decimal semantics and the behavior around errors and file status.

Analysis without migration is also a valid outcome: the same team reports building architecture-analysis tools for ANZ covering more than 15 million lines of Hogan COBOL, and analysis tools for the U.S. Social Security Administration covering more than 200 million lines of COBOL, assembler, SQL, JCL and Java. Neither was a migration; both were about understanding very large estates well enough to decide, which is where any COBOL plan should start. The wider context for those decisions is in our legacy modernization pillar guide.

Frequently asked questions

1. Is COBOL still used in 2026?

Yes. COBOL still runs core systems in banking, insurance, government benefits and tax, and large back-office batch operations. GAO's July 2025 report found Treasury systems running on COBOL and assembly language, ISO revised the COBOL standard in 2023, and IBM ships Enterprise COBOL 6.5 for current IBM Z hardware. Precise global line counts do not exist.

2. Why do banks still use COBOL?

Banks keep COBOL because their core ledgers run on it, it performs exact decimal arithmetic, it handles very high transaction and batch volumes on IBM Z, and decades of business rules exist only in the code. Replacing a core banking system is expensive and risky, so banks usually wrap, optimize or translate rather than rewrite.

3. How many lines of COBOL are still in use?

Nobody knows precisely. Reuters estimated 220 billion lines in April 2017. A 2022 study by Vanson Bourne, commissioned by COBOL vendor Micro Focus, estimated more than 800 billion lines in daily production, based on 1,104 interviews. Both are estimates, and the Reuters figure is now nearly a decade old.

4. Is COBOL worth learning in 2026?

For developers in financial services, insurance or government IT, it can be. The syntax is simple, free training exists through the Open Mainframe Project, and GAO reports a dwindling pool of people with these skills. The most valuable skill is combining COBOL with knowledge of a specific system and of modern targets such as Java or C#.

5. Can AI convert COBOL to Java?

Generative AI can explain COBOL and draft Java, and vendors including IBM, AWS and Anthropic now promote AI-assisted modernization. The open question is reliability at scale: LLM output is probabilistic and can be subtly wrong in rounding or data handling. Many teams use AI for comprehension and tests, and deterministic tooling for the production code.

6. Will COBOL ever be replaced?

Gradually, application by application, but not wholesale any time soon. Organizations replace COBOL when a platform exit, skills risk or business change justifies it. Many stable COBOL applications will remain because retaining them costs less and carries less risk than replacing them.

7. What is COBOL used for today?

COBOL is used for core banking ledgers, payment and settlement batch, insurance policy administration and rating, government benefit and tax processing, payroll, and high-volume reporting. It is strongest wherever large volumes of records must be processed against precise, auditable rules with exact decimal arithmetic.

Start with a codebase assessment

You cannot decide whether to retain, wrap or translate COBOL until you know what is actually in the codebase. Modernize Software offers a free codebase assessment that, by its own account, returns a complexity report, an automation estimate and a rough timeline in about five business days. Request an assessment, or read more about our COBOL modernization services.