Why haven’t they upgraded?
After all, moving to a newer compiler does not sound like application modernisation in the dramatic sense. The source code remains COBOL. The underlying business application may remain on the same mainframe. There is no necessarily massive rewrite or migration to another platform.
Just install the newer compiler, rebuild the programs and move on.
Unfortunately, large enterprise systems rarely work that way.
IBM itself describes migration to the Enterprise COBOL 5 and 6 generation as more difficult than most previous COBOL compiler migrations. The reason is not primarily that thousands of lines of source suddenly become invalid. It is that newer compilers generate code differently, and that can expose assumptions and data problems that applications have lived with for years.
For an organisation operating business-critical applications, that changes the calculation considerably.
The source code often isn’t the hardest part
One of the more surprising aspects of COBOL compiler migration is that the amount of source code requiring modification may be relatively small.
IBM’s migration documentation notes that changes affecting source are generally limited to comparatively uncommon language features. It says the relevant changes do not affect the overwhelming majority of COBOL users.
That sounds encouraging.
But source compatibility is only one part of the problem.
A production COBOL application is not simply a collection of .cbl files. It exists within a much larger environment incorporating compiler options, copybooks, JCL, runtime libraries, CICS or batch processing, database access, external interfaces, build procedures, testing systems and operational knowledge.
Changing the compiler means validating that this entire application behaves correctly after recompilation.
For a payroll utility containing five programs, that may be manageable.
For a banking system that has evolved over thirty years and contains thousands of programs, it is an entirely different exercise.
Newer compilers can expose old problems
This is perhaps the most important reason why organisations cannot treat COBOL compiler upgrades as routine maintenance.
Older applications sometimes contain data that does not precisely conform to the program’s declared definitions.
Examples can include invalid numeric data, mismatched argument sizes, uninitialised fields or binary values outside their expected definitions.
An application may nevertheless have operated successfully for years because the previous compiler generated machine code that happened to handle those conditions predictably.
Recompile it with a newer optimiser and that assumption may no longer hold.
IBM specifically warns that Enterprise COBOL 5 and 6 can produce different results where applications use invalid data. Its migration recommendations therefore include compiling initially with checking options such as SSRANGE, NUMCHECK, PARMCHECK and INITCHECK, performing regression tests, and only later compiling with the intended optimisation settings once those tests succeed.
That is an important distinction.
The compiler has not necessarily “broken” the application.
It may simply have exposed a defect that was always there.
Testing becomes the real migration project
This is where the economics become apparent.
Installing a new compiler might be relatively easy.
Proving that several thousand business-critical programs still behave correctly can be much harder.
Large COBOL estates often support processes where failure is extremely expensive:
- financial transactions
- policy administration
- payments
- billing
- payroll
- logistics
- government services
- customer records
The tolerance for unexpected behavioural changes is therefore understandably low.
IBM recommends treating applications as complete migration units rather than simply recompiling individual programs opportunistically. Its guidance emphasises regression testing and recommends migrating an application comprehensively so that future maintenance does not continually reopen the compiler-migration problem.
That requires test environments, representative test data, skilled personnel and time.
In some organisations, the hardest part may simply be knowing what the correct result should be.
A system created decades ago may have limited automated tests. Its developers may have left. Documentation may be incomplete.
The organisation can therefore find itself in the uncomfortable position of having software that works reliably in production but lacks the testing infrastructure required to prove that a newly compiled version is equivalent.
“It works today” is a powerful argument
Technology teams naturally prefer supported, current software.
Business owners are often more interested in something else:
Does the application work?
If an application processes millions of transactions every day without incident, the perceived benefit of changing its compiler may appear abstract.
The risk of introducing a regression, however, feels immediate.
This creates a familiar legacy-technology paradox.
The more important and reliable an application becomes, the harder it can be to justify changing it.
That does not mean remaining indefinitely on old tooling is sensible.
It means the modernisation team has to articulate the benefits in business terms rather than simply saying that the compiler is old.
Those benefits can include supportability, performance, compatibility with newer tooling, easier recruitment and reducing future technical risk.
Performance can provide a compelling reason to migrate
Modern Enterprise COBOL compilers are designed to exploit newer IBM Z hardware and perform more sophisticated optimisation than older compiler generations.
IBM documents a range of optimisation techniques in COBOL 6, including eliminating duplicated calculations, simplifying expensive arithmetic operations and inlining certain procedures to reduce branching overhead.
For CPU-intensive workloads, this can create a meaningful business case.
A program does not necessarily have to be rewritten to run more efficiently.
Recompilation with a newer compiler and appropriate optimisation settings may improve its use of the underlying processor.
That is why IBM recommends prioritising suitable workloads rather than necessarily attempting to migrate an entire estate simultaneously. Its migration guidance specifically discusses identifying applications where newer compiler optimisation is likely to provide greater benefits.
For organisations where mainframe CPU consumption materially affects operating costs, that can turn compiler migration from a housekeeping project into an optimisation initiative.
Mixed compiler estates make the problem easier to postpone
Another reason migration persists for years is that enterprises do not necessarily have to recompile everything immediately.
Existing load modules may continue running under supported z/OS runtime environments even when the compiler originally used to build them is old.
IBM distinguishes between the compiler used to build an application and the Language Environment runtime under which existing applications execute. Its current documentation notes that applications compiled with older compilers can continue running when compatible with supported runtime environments.
Operationally, that gives enterprises breathing room.
Strategically, it can also encourage delay.
A typical organisation may gradually accumulate a mixed estate:
some applications compiled using newer Enterprise COBOL versions,
some untouched applications whose executables have been running reliably for many years,
and various intermediate states created by maintenance work.
That may be workable, but it makes understanding the estate increasingly important.
Without good inventory information, an organisation may not know which compiler produced every load module or where its greatest migration risks sit.
The build environment matters as much as the compiler
Modernising the compiler often exposes another problem: the software-delivery process around the application may itself be old.
Some mainframe development environments still depend heavily on custom scripts, manual processes or knowledge held by a relatively small number of specialists.
A compiler upgrade can therefore become an opportunity — or a requirement — to inspect:
- build processes
- compiler options
- source control
- dependency management
- automated testing
- deployment pipelines
- debugging tools
- development standards
This is one reason organisations should resist viewing compiler migration as an isolated infrastructure change.
The better question may be:
If we are going to revalidate this application anyway, what else should we improve at the same time?
That could include moving source into Git-based workflows, introducing automated testing or improving CI/CD integration.
The compiler then becomes one part of a broader developer-experience modernisation effort.
Application knowledge is often the scarce resource
A migration project also depends on people who understand the applications being migrated.
Compiler specialists can explain new options and diagnostics.
They cannot necessarily explain why an insurance calculation contains a business rule created in 1998.
This connects compiler modernisation directly with the wider mainframe skills issue.
The people best equipped to assess unexpected behaviour after recompilation are often the people who have spent years working with the existing system.
If those people are approaching retirement or have already left, migration becomes more difficult.
That creates an argument for migrating important applications before organisational knowledge disappears rather than waiting until old tooling becomes impossible to maintain.
The technical risk may be lower while experienced application specialists are still available to explain the system.
Should enterprises move everything at once?
Usually, there is no need to turn compiler migration into a single enormous programme.
IBM describes multiple upgrade approaches, including migrating the entire estate as one project or progressing application by application through smaller initiatives.
For many organisations, an application-by-application strategy is more pragmatic.
Candidates can be prioritised according to factors such as:
Business criticality
How damaging would unexpected behaviour be?
CPU consumption
Could newer optimisation materially reduce processing requirements?
Change frequency
Applications under active development may benefit sooner from improved tooling.
Test coverage
Applications with strong automated regression suites may be easier to migrate safely.
Staff knowledge
Are experienced engineers still available to validate behaviour?
Technical dependencies
Does the application rely on unusual compiler options or legacy runtime assumptions?
The result should be a migration portfolio rather than an indiscriminate recompilation exercise.
Why COBOL 5.1 still matters historically
The historical InsideTechTalk URL for this article specifically referenced COBOL 5.1.
That version was important because it represented a significant generational change in IBM’s COBOL compiler technology.
However, an organisation planning a migration today should not interpret the restoration of this article as a recommendation to migrate to COBOL 5.1.
IBM’s current migration documentation focuses on Enterprise COBOL 6 as the modern migration target, while noting that properly serviced COBOL 5.1 and 5.2 are effectively equivalent for migration purposes.
The historical question therefore remains useful, but the modern version is broader:
What is preventing organisations from moving their COBOL applications onto a current compiler generation?
The answers are largely about risk, testing and organisational complexity.
What a sensible compiler-modernisation programme looks like
A pragmatic programme would begin with inventory rather than recompilation.
Know what you have.
Identify applications, programs, compiler versions, dependencies and runtime requirements.
Prioritise applications.
Do not assume every application offers the same benefit or carries the same risk.
Establish regression testing.
Where automated tests do not exist, building them may be one of the most valuable outputs of the migration.
Use diagnostic compiler options.
Treat invalid data and parameter mismatches as defects to fix rather than behaviours to preserve.
Benchmark important workloads.
Where performance is part of the business case, compare equivalent workloads under controlled conditions. IBM advises measuring old and newly compiled modules on the same hardware with comparable data when evaluating performance gains.
Capture application knowledge.
Involve experienced engineers while they are still available.
Improve the development process where appropriate.
Compiler migration can be a catalyst for better source control, testing and automation.
Move deliberately rather than indefinitely.
Waiting eliminates none of the complexity.
In many cases, it merely increases the chance that the people who understand the application will no longer be available when migration finally becomes unavoidable.
The barrier isn’t COBOL itself
The continued use of older COBOL compilers can look from the outside like evidence of technological inertia.
Sometimes it is.
More often, however, it reflects the realities of operating mature enterprise software.
A compiler upgrade can touch applications whose behaviour has been refined over decades and whose failure would have immediate business consequences.
That makes caution rational.
But caution and inaction are not the same thing.
Modern COBOL compilers provide better optimisation, compatibility with current tooling and a clearer path for maintaining these applications into the future. At the same time, the migration process can expose exactly the kinds of hidden dependencies and undocumented behaviours that organisations need to understand anyway.
The strongest argument for compiler modernisation may therefore not be that the old compiler is obsolete.
It is that every year an organisation waits, the application remains just as complicated while the people who understand that complexity become harder to replace.
