Thinking About Cobol Conversion?

You are here


In this series of articles, We will try to summarize key learnings from more than 30 years of being involved in system conversions, predominately Cobol to something else. Regardless of what it is, there are a few shared considerations a project should consider where embarking such endeavor.


Cobol is a structural language with many years of maturity. It was built for business use, and it is used as that for a few decades now. So why to move away from it?

Let's start with that Cobol is a great language with many features for data processing. It is used in many core business processes. So core and critical that companies afraid to touch it due to the risk of impairing their business. Cobol has a solid environment for development, test, and run since late 50's.

So really, why to convert? There is plenty of information with conflicting advice to either stay with or move out of Cobol. Rather try to weigh in on such discussion, here are a few drivers that lead companies to consider moving on.

In reality, stay or convert is a business investment with long term vision. As such, it needs to be incorporated into your company's long-term business goals and objectives.

Expert availability

The world moved on. Rightfully or not, fewer and fewer colleges are teaching Cobol. As a result, fewer and fewer Cobol experts are made available. Partly due to that Cobol programming language lacks newer programming paradigms found in languages such as C++, Java, Lisp, and Python just to name a few. For example, inheritance and lambda anonymous function. So not so much bleeding edge concepts like object oriented and functional programming cannot be taught nor used with Cobol.

Existing Cobol experts pool is aging. To get experts to work on your project, in many cases, one needs to go abroad (India has a large pool of Cobol experts). Even when it is practical, such reach may strain project capabilities.

Cobol ecosystem

Cobol core business programs are aging too. Some were built and patched over more than 40 years. Every element you touch may cause unforeseen issues. So a small set of business requirements translates into days and weeks of design and change with weeks and months of tests and rollout. Such lengthy deployment impacts time to market of new capabilities.

Some Cobol environment costs can be attributed to its resource consumption, predominately Mainframe. There is plenty of information on how Mainframe environments are cheaper and more stable than distributed environments. The startup cost for projects, however, is lower with distributed environment. Those environments can be built to scale with use. As the use of new business process grows, so does the environment supporting it. If your environments have many startup projects, Mainframe cost can be amortized.


A quote from a colleague: "We want to move into a nimble IT environment that allows quick response to business needs. Our Cobol environment drives lengthy and costly delivery timelines that upset our business," sums this up nicely.

As mentioned above, many types of research show the benefit and disadvantages to stay with or move on from Cobol. The direction you take should be coupled with your company's business goals and capabilities.


Assuming decision had been made to move on from Cobol to something else. From here on we will assume the target system is distributed environment with a set of programming languages that do not include Cobol.

In reality, conversion project is not any different from any other software coding project. And should be run as such. Conversion is the process of introducing new software for existing business processes.

However, there are a few interesting considerations with conversion:

  1. There is existing software handling the business process. Do we maintain user experience?
  2. The current system may not be documented well. How do we re-engineer?
  3. In the conversion period, business keeps requesting enhancements. How to we keep old and new at par?

Way forward

So you have many business processes bundling Cobol programs and business data residing on DB2 SQL, for example. At the end of a conversion process, you want to have distributed environment using some combination of modern programming language and different database engine. You may also want better user experience.

Two approaches

Here are two different ways We saw conversion project run. In one project the company decided to rewrite their backend processing in distributed environment using C/C++ programming languages. That was done in the second half of the 90's. The first step was "specing" the new system based on existing system specs plus enhancements. On its last step, rollout, the project capitalized on that user community was split into isolated groups. Hence, deployment could progress by business population.

In another project, a conversion was done according to business processes. To start, isolating a business process was needed to allow its replacement. Adapters between legacy business processes were designed and built as part of this effort. Those adapters allowed legacy processes to communicate with new processes. Adapters included process-to-process and process-to-data access methods. The project started with lesser significant processes. Each conversion added new knowledge that was incorporate into next steps.

Both approaches were successful. Both took a few years to complete. Both delivered modernized system more nimble than before.

Small steps

The spectrum of things to consider in conversion project is wide. The larger the project is, the more way it can be sliced and managed. And slicing is of the essence. Think big but start small is a motto to keep in mind. One reason for this is that conversion project is not only converting programs and their artifacts. It is also migrating people and processes to a new environment, new system new rules.

Starting small would help everyone catch up and contribute. As test and deployment progressed, new knowledge would be acquired. Improvements will be made to the process. Taking this one step further, experimenting is critical for such project. One way to get going is to start any new development on the new platform.

Assuming your target environment has means to read and write Cobol files, you can develop extensions in the target language. Ab Initio, for example, has file interface to Cobol files. In Acrisel we developed Python read and write Cobol files based on their DDE (copybook). With that, the project team can start experimenting in the future environment and acquire required experience for the conversion.

Example for how simple it is to integrate with Cobol reading Cobol file:

copybook_source=cpy.load('data_struct_source.cpy', replacing=[('any', ':TAG:', 'WS')],)
with, 'r', delimiter='\n', encoding=encoding) as in_stream:
    for rec in

Having such capabilities also help in creating data for test cases. We are adding similar capabilities for C++ and Java.

Additional Information

"All The Rich Kids Are Into COBOL—But Why?", M. ASAY, 2014,

"The Inevitable Return of COBOL," R.Trikha, 2015,

"Visual COBOL 2.2 - REST Web Services Tutorial", Microfocus community,

"Mainframe Is Still Cheaper: Cost Analysis of the Infrastructure," D.BEULKE, 2012,

"The Hidden Costs of Moving from the Mainframe," ""

"Open source project by Acrisel,"

Copyright © 2017 by Acrisel, all rights reserved.

Leave a Reply

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.
Enter the characters shown in the image.