The system works. That is precisely what makes it hard to talk about.
Order management, production, inventory, shipping, settlement — these run every day on programs written twenty or thirty years ago, and they run correctly. The problem is not defect rates. The problem is that every proposal now begins with the same question: can we change the core system to support this? A new sales channel, a partner API, a data platform, a forecasting model — each one stalls at the same gate. Over time, the roadmap quietly shrinks to fit what the core system will tolerate.
That is the real trigger for most COBOL modernization programs. Not the age of the language, but the shrinking set of options around it. This article is written for CTOs, CIOs, IT directors and engineering managers who are building the internal case for change. It covers the difference between migration and modernization, how to choose between replatform, refactor and reimagine, where AI genuinely helps, and the five phases of a COBOL-to-Java migration — including the testing that determines whether the whole thing succeeds.
Why COBOL modernization has moved up the board agenda
COBOL is not a dead language. It still processes core transactions in banking, insurance, manufacturing and distribution, and it does so reliably. But a working system is not the same as a maintainable one. Eight pressures typically push modernization from “someday” to “this fiscal year.”
1. Talent risk and key-person dependency
Documentation is incomplete or absent, so the business logic lives in the heads of a small number of long-serving engineers. When one of them retires, the organization does not just lose capacity — it loses the ability to change the system at all. The external COBOL labour market keeps shrinking, so backfilling is no longer a reliable plan.
2. Rising cost of ownership
Hardware and software maintenance are the visible costs. The larger, less visible cost is testing: when nobody can predict the blast radius of a change, every change is regression-tested broadly. A one-line fix that takes three months to release is expensive in ways that never appear on the infrastructure line.
3. Declining maintainability
Decades of amendments leave programs with branching logic nobody can fully trace. Teams spend more time deciding whether a change is safe than making it.
4. Platform and middleware end-of-support
Hardware and middleware lifecycles move on vendor timelines, not yours. When a platform reaches end-of-support, the decision window narrows — and the later you start, the more likely you are forced into the fastest option rather than the right one.
5. Security and audit exposure
Unsupported platforms cannot always take current patches, cipher suites or identity integrations. Increasingly, the honest answer to an audit finding becomes “the architecture does not allow it.”
6. Integration and data access
When core data is locked inside the legacy estate, analytics, data platforms and AI initiatives all end up partial. The usual workaround — another point-to-point batch feed — creates the next generation of legacy.
7. Time to market
Modernizing the front end does not help if the core cannot keep pace. Overall delivery speed is set by the slowest layer, and for most enterprises that layer is the core.
8. Operational resilience
Business continuity is not “it has never gone down.” It is “we know who can recover it and how.” A system understood by three people is a continuity risk regardless of its uptime record.
Migration is not the same as modernization
This distinction decides the budget. Moving a workload to a new runtime (migration) and restructuring it so it can be maintained and extended (modernization) are different investments with different outcomes. In practice, mature programs apply different patterns to different parts of the estate — an approach AWS also describes in its guidance on disposition strategies for mainframe application modernization.
| Approach | What it does | Best fit | What it does not solve |
|---|---|---|---|
| Replatform | Moves the application to an open or cloud platform while keeping most of the application and business logic intact. | End-of-support pressure; stable business requirements; the priority is removing infrastructure risk quickly. | Maintainability and key-person dependency remain. Plan the next step before you finish this one. |
| Refactor | Converts COBOL into a maintainable stack — typically Java and Spring — and restructures the code around it. | Core domains that will keep changing; areas where you need a larger hiring pool. | Automated conversion alone produces “COBOL written in Java.” Target architecture must be defined up front. |
| Reimagine | Redesigns selected business capabilities using APIs, microservices, event-driven patterns or cloud-native services. | Differentiating capabilities; functions that must expose or consume external services. | Cost and duration. Applied across a whole estate, it rarely completes. |
For a large estate, the useful question is not “which one?” but “which one, where?” Batch-heavy, stable processing may only need a replatform to clear the infrastructure risk. High-change domains such as order management justify a refactor. A small set of functions that must integrate externally are worth reimagining. Getting that allocation right has more effect on return than any tooling decision.
AI-assisted, expert-led modernization
AI has changed the economics of the discovery and documentation phases, which historically consumed a large share of the effort. It is genuinely effective for:
- Classifying and inventorying source code — live, dead, duplicated
- Application discovery and dependency mapping
- Generating technical documentation for undocumented assets
- Extracting and summarizing embedded business logic
- Assisting code conversion
- Generating test cases
- Supporting migration wave planning
- Test automation
What AI cannot do is close the program on its own. Legacy code encodes more than logic: it encodes exceptions, workarounds and history. A conditional branch that exists for one specific counterparty, a rounding rule that reflects an accounting policy, a date check written around a regulation that has since changed — static analysis surfaces these as code, not as intent. Only someone who knows the business can classify them.
This is why the working model should be AI-assisted and expert-led, with humans in the loop. AI supplies speed in analysis and generation; legacy specialists, Java and cloud engineers, QA, and business users own the verification. Business-user involvement is not a courtesy — it is the only credible basis for declaring functional equivalence.
Treat AI as leverage on investigation and generation effort, never as the accountable party for a business decision. Programs that blur this line discover the problem during testing, at the worst possible cost.
The five phases of a COBOL modernization program
Phase 1 — Application discovery and dependency mapping
Inventory programs, jobs, shell scripts, reports, screens and database objects, then map call chains and data flows. The single highest-leverage output of this phase is identifying what is no longer used: estates routinely shrink materially once dead code is excluded. In parallel, interview business users to recover the rules that were never written down.
Phase 2 — Proof of concept and migration wave planning
Do not start at full scale. Select one representative slice — ideally a genuinely awkward one — and prove the conversion approach, target architecture and test method end to end. The purpose of the PoC is not to show that it is possible; it is to make the effort, quality and risk of the full program estimable. The results then drive how you split the estate into migration waves, and how each wave cuts over, including whether parallel running is required.
Phase 3 — Converting code, screens, data and platform
Code conversion runs alongside re-implementing online screens for the web, rebuilding reports, migrating data (with character-set and data-type differences handled explicitly), and moving middleware and job scheduling. Maintain traceability throughout: at any point you should be able to say which COBOL program corresponds to which Java component, and why.
Phase 4 — Functional equivalence testing and quality assurance
This phase determines whether the program is trusted. If the business process is not changing, you must be able to demonstrate with evidence that the new system returns the same results as the old one for the same inputs. That normally requires:
- Unit tests
- Component tests
- Batch output comparison between legacy and target
- Integration tests
- Data reconciliation
- System tests
- Performance tests — particularly batch completion inside the operational window
- Security validation
- Regression tests
- User acceptance testing
Phase 5 — Cutover, stabilization and continuous improvement
Cutover plans are only complete when the rollback criteria are written down alongside them. Staff monitoring and first-line support heavily for the first cycles, confirm stable running, then hand over to normal maintenance. Modernization does not end at cutover: once the estate is maintainable, API exposure and cloud services can be introduced incrementally. That second stage is where much of the return actually accrues.
Business outcomes to expect
- Reduced operational risk — off unsupported platforms, with a wider pool able to respond to incidents.
- Reduced talent concentration — a mainstream stack means the team can actually be rebuilt.
- Improved maintainability — structure and documentation cut the investigation effort in every change.
- Shorter release cycles — predictable blast radius allows test scope to be scoped rationally.
- Integration readiness — real connection points for APIs, cloud services, data platforms and AI.
- Preserved business logic — decades of validated rules carried forward in an explainable form.
- Better user experience — web-based screens remove terminal and client constraints.
- A base for longer-term change — future initiatives no longer start with an archaeology project.
Savings percentages and payback periods depend entirely on the size, structure and requirements of the estate in question. Targets should come out of the discovery phase, not from a vendor’s brochure.
How BAP has delivered this work
BAP has worked on a program that moved order management, production, inventory and shipping operations from a legacy system to a new platform under an explicit constraint: the business processes themselves were not to change.
The scope covered approximately:
- 90 user screens
- 300 application programs
- 85 shell scripts for batch processing and operations
- 65 database tables
BAP carried out on-site requirements confirmation and system analysis, proposed the migration approach, supported development, and executed component testing, system testing and user acceptance testing.
The “do not change the process” constraint is worth dwelling on, because it defines where such a project is won or lost. If the process must stay identical, then proving functional equivalence is not a closing activity — it is the central deliverable, and test design has to be built into the program from the discovery phase onward.
What BAP brings to a modernization program
| Area | Capability |
|---|---|
| Assessment | Asset inventory, dependency mapping, business interviews, comparison of migration options |
| Proof of concept | Validating approach and improving estimate accuracy before large-scale commitment |
| Incremental migration | Wave design and execution by business domain and data domain |
| Development | COBOL-to-Java conversion, Java/Spring development, web screen and report rebuild |
| Platform and data | Platform and middleware migration, data migration and reconciliation |
| Quality assurance | End-to-end testing from unit through UAT, batch comparison, performance and security validation |
| Delivery models | Offshore, onsite and hybrid; support in English, Japanese, Korean and Vietnamese |
| Post-modernization | Stabilization support, ongoing maintenance and incremental enhancement |
BAP is a software engineering company of around 500 technical staff, with delivery centres in Vietnam (Hanoi, Da Nang, Ho Chi Minh City, Hue) and offices in Japan, South Korea, Australia and the United States. A significant share of our delivery history is with Japanese enterprise clients, where documentation discipline, functional equivalence and stable operation are treated as non-negotiable — a standard that transfers well to any core system programme.
Frequently asked questions
Does converting COBOL to Java complete the modernization?
No. Mapping COBOL control structures directly onto Java produces code that is technically modern and practically unchanged — the investigation effort per change stays where it was. Conversion has to be paired with decisions about package structure, data access and error handling before it delivers maintainability.
We have almost no documentation. Is migration still viable?
Yes, and it is the normal starting condition. Specifications are reconstructed from source, job definitions and observed data behaviour, then validated with business users. AI-assisted analysis and documentation generation are particularly effective here, though the validation step remains human.
Big bang or incremental cutover?
It depends on downtime tolerance and estate size. A single cutover avoids the cost of parallel running but makes rollback harder. Incremental waves lower per-event risk but introduce a real design problem: keeping old and new data consistent during the transition. Decide this on PoC evidence rather than principle.
How do we guarantee the business does not change?
Through functional equivalence testing. Legacy and target outputs are compared, and every difference is investigated until it is classified as either a defect or an intended specification change confirmed by the business. There is no shortcut around this.
Our platform is supported for several more years. Why start now?
Because discovery and decision-making alone take substantial time, followed by migration, testing and stabilization. Starting late tends to eliminate the refactor and reimagine options and leave only the fastest one. Beginning with assessment costs comparatively little and preserves choice.
What is a sensible first step?
An asset inventory and dependency map. Until the size and shape of the estate are visible, any discussion about replatform versus refactor versus reimagine is speculation. This step does not require a large commitment.
Talk to BAP about your COBOL estate
We work with organizations at every stage of this decision, including the earliest one. Engagements typically start with:
- A COBOL modernization assessment — asset inventory and dependency mapping of the current estate
- A working discussion — reviewing talent exposure, maintenance load and platform support timelines
- A modernization roadmap — pattern allocation by domain and migration wave design
- A proof of concept — validating the approach and the estimate before large-scale investment
If your internal position is still unsettled, that is a reasonable place to begin. Tell us about the current system and we will set out the questions worth answering first.
