What is COBOL modernization? A Plain English guide for CIOs

← All posts

COBOL modernization is the work of changing a COBOL application, or the platform and processes around it, so that it is cheaper to run, easier to change, safer to operate and supportable by the people you can hire, while keeping the business logic it contains. That can mean leaving the code on the mainframe and adding modern interfaces, moving it to a new platform, translating it into a language such as Java or C#, or replacing it altogether.

This guide is written for CIOs, CFOs, heads of architecture and board members who need to understand COBOL modernization well enough to make decisions about it, without having to read COBOL. It explains what is being modernized, why COBOL systems are still running, why organizations are acting now, the main approaches, what a program involves, what makes it hard, how Gen AI and symbolic AI fit, when not to modernize, and how to explain the decision to a board. A glossary at the end defines the terms you will hear from vendors and teams.

COBOL modernization, defined

COBOL, the Common Business Oriented Language, dates from 1959 and became the standard language for business data processing on mainframes. It is still used heavily in banking, insurance, government, retail, transport and utilities. The programs written in it handle payroll, accounts, claims, benefits, billing, reservations and a long list of other core functions.

“Modernization” in this context covers a family of changes. A COBOL system has several layers, and modernization can touch any of them.

• The code. The COBOL programs, copybooks and the job control language (JCL) that runs them. Modernizing the code can mean restructuring it, translating it to another language or rewriting it.
• The data. Files and databases that the programs read and write, such as VSAM files, IMS databases or Db2 tables. Modernizing the data usually means moving it into relational or cloud databases and converting its formats.
• The platform. The mainframe hardware and operating system, or whichever server the programs run on. Modernizing the platform can mean moving to distributed servers or the cloud.
• The integration. How the system talks to other systems: file transfers, batch interfaces, screens, messages. Modernizing integration usually means adding APIs so that new applications can call the old logic directly.
• The people and process. Who can maintain the system, how changes are made, tested and released. Modernizing this means modern development tools, automated testing and a codebase that more developers can work on.

A modernization program might address one layer or all of them. Being clear about which layers are in scope is the first step toward a sensible plan.

Why COBOL systems are still running

Executives new to the subject often ask why these systems have not already been replaced. There are good reasons.

They work. Many COBOL systems have run reliably for decades, processing high volumes with strong availability. The mainframe platforms underneath them are engineered for exactly that kind of workload.

They contain the business. Over thirty or forty years, every product change, regulatory update and exception has been written into the code. Much of that logic is not documented anywhere else. Replacing the system means rediscovering all of it.

Replacement projects have a mixed record. Large rewrites and package replacements have failed or run far over budget often enough that organizations are cautious about repeating them.

The cost of leaving has been hard to justify. For years, running the existing system was cheaper and safer in the short term than changing it.

These reasons remain valid. What has changed is the balance of risk. The US Government Accountability Office reviewed federal legacy systems in 2019 and found that about 80 percent of federal IT spending went to operating and maintaining existing systems. It highlighted a critical system written in COBOL, a language with a dwindling number of people available to support it (GAO-19-471). A 2023 follow-up found that two of the agencies had still not implemented GAO’s recommendation to document modernization plans for those systems (GAO-23-106821). Private sector organizations face the same pressures, usually with less public reporting.

Why organizations modernize COBOL now

The reasons usually combine several of the following.

Skills

The people who built and maintain many COBOL systems are retiring, and fewer developers are learning COBOL and the mainframe platform. The shortage covers the language and, more seriously, the knowledge of each specific system, which cannot be hired from outside. Our piece on the legacy code talent shortage looks at how this is developing and what it costs. Training programs exist, including the open COBOL Programming Course from the Open Mainframe Project, and they help, but they do not replace decades of system-specific knowledge.

Cost

Mainframe software licensing, hardware and specialist staff are significant costs. Some of that cost can be reduced without leaving the mainframe, for example by tuning workloads and removing unused code. For some organizations, moving the workload to a different platform reduces cost further; for others it does not, once migration and new operating costs are counted.

Speed of change

When every change to a core system needs scarce specialists and long test cycles, the business waits. Products launch late, integrations take months and regulatory changes consume the capacity that could go to new work.

Integration

Customers expect digital channels, partners expect APIs and analytics teams expect access to data in near real time. COBOL systems designed around overnight batch and file transfers can support these, but often only with considerable extra engineering.

Security and regulation

Older platforms and software versions fall out of support, security expectations rise and regulators ask more questions about operational resilience and third-party dependencies. Modernization is sometimes the most practical way to meet new requirements.

Platform end of support

Hardware leases end, operating system versions leave support and vendors change their product plans. These dates often become the practical deadline that turns a long-running discussion into a funded program.

The main approaches to COBOL modernization

Vendors use many names for the approaches. Most fit into six options, which can be combined across an estate.

Retain and optimize

Keep the COBOL on its current platform and make it cheaper and easier to run: remove dead code, tune expensive workloads, update compilers and improve development tooling. This is the lowest risk option and often a sensible first step.

API enable and extend

Keep the COBOL where it is and expose its functions as APIs, so that new digital services can use the existing logic. This delivers new capability quickly without changing the core. It can also be the foundation for replacing pieces gradually, an approach often called the strangler fig pattern.

Rehost

Move the COBOL to a different platform, such as distributed servers or the cloud, using a compatible compiler and runtime. The code stays as COBOL. Rehosting can reduce infrastructure cost relatively quickly, but the language and skills dependency remain.

Refactor or translate

Convert the COBOL into a mainstream language such as Java or C#, preserving its behavior. Done with rule-based translation technology, this can move large estates in a predictable way, producing code that a much larger pool of developers can maintain. The data typically moves to modern databases at the same time.

Rearchitect or rewrite

Redesign the application, often as services in the cloud, and rebuild it from the requirements and the knowledge extracted from the existing code. This offers the greatest long-term flexibility and carries the greatest risk and cost.

Replace

Retire the custom system and move to a commercial package or software-as-a-service product. This works well where the business function is standard and the organization is willing to adapt its processes to the package.

Each approach suits different drivers. A skills-driven program points toward translation or rewrite. A cost-driven program might start with optimization or rehosting. An integration-driven program might start with APIs. Our comparison of rehost, refactor and rearchitect strategies looks at these options in more depth, including what each leaves you with after several years.

What a COBOL modernization program involves

Whatever the approach, a program follows a broadly similar sequence.

Assessment

Build an inventory of the estate: programs, copybooks, JCL, databases, files, interfaces, schedulers, reports and supporting utilities. Measure size and complexity, identify dead code and map which business functions depend on which components. A good assessment usually finds more than expected, especially in the surrounding components that are not COBOL.

Strategy and business case

Decide what should happen to each part of the estate, and why. Build the business case on the combination of costs avoided, risks reduced and capabilities gained, over a realistic time horizon.

Pilot

Take a small but representative slice through the chosen approach end to end, including data migration and testing. The pilot proves the method on your own code and provides a basis for the full plan.

Waves of delivery

Group the estate into waves, usually by shared data and business function, and move each wave through conversion, data migration, testing and cutover.

Verification

Prove that the modernized system produces the same results as the old one. For most programs this is the critical path, and it is the area where under-investment most often causes delay.

Cutover and decommissioning

Switch production to the new system, run in parallel where needed, then retire the old platform, licenses and contracts, keeping any records that must be retained.

Knowledge transfer and ongoing change

Leave the internal team able to maintain and develop the new system, and establish the development practices that stop the new system from becoming the next legacy problem.

What makes COBOL modernization hard

The difficulties are well understood, and each can be managed.

• Undocumented business rules. The code is often the only complete description of how the business works. Modernization must preserve that behavior, including behavior that nobody remembers asking for.
• Exact arithmetic. COBOL handles money in fixed-point decimal with explicit rounding rules. Converting it carelessly introduces small differences that accumulate across millions of transactions.
• Complex data definitions. COBOL lets one area of memory be read in several ways, and lets record lengths vary. Mapping those structures into modern databases takes care.
• Dialects and platform features. Each compiler and platform has extensions, and the surrounding estate of JCL, transaction monitors, utilities and schedulers is often as large as the COBOL itself.
• Testing. Proving equivalence across online processing and batch, including month-end and year-end cycles, needs realistic data, parallel running and a disciplined process for resolving differences.
• Change during the program. The business keeps changing while modernization runs. Changes made to the old system must be carried into the new one.

Where Gen AI and symbolic AI fit in COBOL modernization

Two very different technologies both get described as “AI” in modernization marketing, and the distinction matters for executives.

Symbolic AI and compiler technology. This is the rule-based approach used by translation technology such as DMS. It parses code the way a compiler does, builds a precise model of its meaning and applies explicit transformation rules. The results are deterministic, meaning the same input always produces the same output, and they can be verified and repeated. This approach is well suited to converting large volumes of business-critical code.

Gen AI. Large language models generate text and code from patterns learned in training. They are useful for explaining code, drafting documentation, suggesting tests and helping developers learn an unfamiliar system. Their output varies from run to run and can contain errors that the model does not flag, so it needs review and testing. Gen AI works best as an augmentation layer around a deterministic conversion, helping people understand and verify the results.

When a vendor describes its approach as AI-powered, it is reasonable to ask which kind it means and what it does to your code.

When not to modernize

Not every COBOL system should be modernized, and not all at once. A system that is stable, cheap to run, rarely changed and supported by an adequate team may be best left alone for now, with attention given to documentation and succession planning. Parts of a large estate may be retired instead of modernized, because nobody uses them. Our piece on when not to modernize legacy systems explains how to tell which parts of an estate belong in which group.

The decision is rarely all or nothing. Most organizations end up with a portfolio: some systems left alone, some API-enabled, some translated, some replaced, sequenced over several years.

How to explain COBOL modernization to a board

Boards tend to ask the same few questions. Short, direct answers work best.

What is the risk of doing nothing? Describe the concrete exposures: named systems that depend on a small number of people, platform support dates, regulatory findings, and the business changes that are waiting on the system.

What are we going to do? Describe the approach per system group, in plain language, and why each was chosen.

What does success look like? Define outcomes the board can recognize: the skills dependency reduced, a platform retired, a regulatory finding closed, time to launch a product shortened.

How do we know it is working? Explain the pilot, the evidence each phase will produce and the checkpoints where the board will see results.

What could go wrong, and what have we done about it? Name the main risks, typically testing, data and scope growth, and the controls in place for each.

A board that understands the approach in these terms can support the program through the inevitable surprises, which matters more than any single estimate.

What COBOL modernization looks like in different industries

The approaches are the same everywhere, but each industry weighs them differently.

Banking and insurance

Financial institutions run core accounts, payments, policy administration and claims on COBOL. Exact decimal arithmetic, period-end processing and regulatory evidence dominate the work, and third-party risk rules apply to the firms involved. Translation with thorough parallel running is common for systems where skills risk is high, often alongside API enablement for digital channels.

Government

Tax, benefits, licensing and records systems at national and local levels are often written in COBOL and have been running for decades. Public reporting on these systems has repeatedly pointed to skills shortages and incomplete modernization plans. Procurement rules and the need for continuity of public services shape how programs are structured, frequently in smaller, staged contracts.

Retail, transport and logistics

Inventory, pricing, reservations, scheduling and supply chain systems carry high transaction volumes and seasonal peaks. Integration with e-commerce, partner systems and real-time data is often the main driver, so API enablement tends to come first, with translation or replacement of back-office components following.

Manufacturing and utilities

Billing, metering, maintenance and planning systems often combine COBOL with packages and specialized engineering software. Regulated tariffs and long asset lifetimes make historical accuracy important. Programs frequently mix translation of custom billing logic with replacement of standard functions by packages.

Common misconceptions about COBOL modernization

Several beliefs come up in almost every early conversation about COBOL modernization. Each contains some truth and each can lead a program in the wrong direction.

“COBOL is obsolete, so the code must be poor”

COBOL is old, and it is also a capable language for business data processing, with exact decimal arithmetic and efficient record handling built in. Much COBOL is well written and has run reliably for decades. The problems are usually the scarcity of people who know the specific system, platform costs and the difficulty of integrating with modern services. Modernization addresses those problems, and it does not need to start from the assumption that the code is bad.

“Modernizing COBOL means leaving the mainframe”

Leaving the mainframe is one option among several. Some organizations keep their mainframe and modernize the tooling, interfaces and code on it. Others move some workloads and keep others. The platform decision should follow from the drivers.

“Gen AI will convert the code for us”

Gen AI tools produce plausible code from COBOL, and on small programs the results can be good. On large estates the output varies from run to run and can contain subtle errors, so every line needs verification. Most programs get more value from Gen AI as an aid to understanding, documentation and testing, alongside a deterministic translation process.

“A rewrite will give us a clean system”

A rewrite offers the chance of a clean design, and it also requires rediscovering and reimplementing every business rule. For large systems, that is where many rewrite programs run into trouble. Translating first and redesigning later, on tested code in a modern language, is often a lower-risk route to the same destination.

“This is an IT project”

The system encodes how the business works, and the business must confirm that the modernized system behaves correctly. Programs that treat modernization as purely technical tend to meet resistance at sign-off, when business owners see differences they were not told about.

How to get started: the first 90 days

For an organization at the beginning, the first three months can produce a sound basis for decisions without committing to a large program.

Weeks 1 to 4: establish ownership and drivers. Name an executive sponsor and a program lead. Agree the main drivers in writing, and identify the business owners of the major systems. Collect what already exists: inventories, architecture documents, platform contracts and their end dates, known risks and audit findings.

Weeks 4 to 8: inventory and measure. Run an automated inventory of the estate: programs, copybooks, JCL, databases, files, interfaces and the components around them. Combine it with production usage data to find dead code and the most heavily used functions. Identify the people who know each system, and how exposed each system is to their departure.

Weeks 8 to 12: options and a pilot candidate. For each major system group, describe the realistic options and a preliminary recommendation. Select a pilot slice that represents the hard parts of the estate. Prepare a short paper for the executive committee setting out the drivers, the inventory findings, the options and the proposed pilot.

At the end of 90 days the organization knows what it has, what it wants to achieve and how it will test its chosen approach. That is enough to make a funding decision with confidence.

A glossary of COBOL modernization terms

Where Modernize Software fits

Modernize Software is the modernization arm of Semantic Designs. We help organizations assess their COBOL estates, translate COBOL into Java or C#, and prove that the new system behaves like the old one. Translation runs on DMS, which combines symbolic AI with enhanced compiler technology to apply transformation rules consistently across an entire estate, with Gen AI used as a separate layer for documentation, test generation and review. The COBOL modernization page describes how we approach these programs.

Frequently asked questions

1. What is COBOL modernization in simple terms?

It is updating COBOL systems, or the platforms and processes around them, so they are cheaper to run, easier to change and supportable by available staff, while keeping the business logic they contain.

2. Is COBOL modernization the same as COBOL migration?

The terms overlap. Migration usually means moving something, such as the code to a new language or the workload to a new platform. Modernization is broader and can also include keeping the code in place while improving its tooling, interfaces and processes.

3. Is COBOL still used today?

Yes. COBOL still runs core systems in banking, insurance, government and many other sectors, often processing very high transaction volumes on mainframes.

4. Why not just rewrite COBOL systems from scratch?

Rewriting means rediscovering decades of undocumented business rules and rebuilding them without error, which is slow and risky for large systems. Many organizations prefer to preserve behavior through translation first and redesign later, on code that is already in a modern language and covered by tests.

5. How long does COBOL modernization take?

It depends on the size of the estate, the approach and the testing required. A pilot typically takes a few months, and a full program for a large estate can take several years, delivered in waves.

6. Can symbolic AI or Gen AI modernize COBOL automatically?

Rule-based symbolic AI with compiler technology can translate large volumes of COBOL automatically and repeatably. Gen AI tools help with explanation, documentation and testing, but their output needs review and is not repeatable, so they are best used alongside a deterministic translation process.

7. Do we have to leave the mainframe to modernize COBOL?

No. Modernization can happen on the mainframe, through optimization, better tooling and APIs. Leaving the mainframe is one option among several, chosen when the drivers support it.

8. What is the difference between COBOL modernization and mainframe modernization?

Mainframe modernization covers everything on the mainframe platform: COBOL, but also PL/I, assembler, JCL, databases, security, operations and the hardware itself. COBOL modernization focuses on the COBOL applications and whatever is needed to change them. In practice the two overlap heavily, because most mainframe application code is COBOL.

9. What drives the cost of COBOL modernization?

The main drivers are the size and complexity of the estate, the number of dialects and surrounding technologies, the chosen approach, the amount of data to migrate, and above all the testing needed to prove equivalence. A pilot on a representative slice gives the most reliable basis for estimating the full program.

10. Can COBOL modernization happen while the business keeps changing the system?

Yes, and it usually has to. Long programs need a method for carrying changes made to the legacy code into the modernized version. With deterministic translation, the simplest method is to reconvert the changed programs using the same rules, then rerun the equivalence tests.

11. How do we know whether our COBOL estate needs modernizing?

Look at the exposures: how many people can maintain each system, how often changes are delayed, platform support dates, audit or regulatory findings, and integration requests the system cannot meet. Systems with several of these exposures are candidates; stable, rarely changed systems with adequate support may be better left alone for now.

12. Who should own a COBOL modernization program?

Usually a senior executive with authority over both technology and the affected business areas, supported by a program office. Business owners must be involved because they sign off that the modernized system behaves correctly.