“The system still runs accurately every day — but almost no one can explain why it works the way it does.” Many companies running COBOL core systems find themselves in exactly this position.
The problem is not quality. It is speed of change and narrowing options. Adding a sales channel, connecting to SaaS, using AI for demand forecasting — every initiative starts with the same question: “Can we touch the core system?” Too often, the answer shrinks the initiative itself. That, more than the age of the code, is what pushes companies to modernize.
What you will learn (for IT leaders, CIOs and CTOs)
- Eight pressures that make COBOL modernization a priority
- The difference between migration and modernization — and how to choose between Replatform, Refactor and Reimagine
- Where AI genuinely helps, and where human judgment is still required
- A five-phase modernization process, plus a BAP project example
Why COBOL Modernization Has Moved Up the Agenda
COBOL is not a dead language. It still processes core transactions in banking, insurance, manufacturing, and distribution. But a system that runs well is not the same as a system you can maintain. The question is not how old the technology is, but whether it can keep up with how the business needs to change. Eight pressures typically turn modernization into a real priority.
| Pressure | What happens |
|---|---|
| 1. Talent risk | Only a few long-tenured engineers understand the business logic. When they leave, change stops — and the shrinking COBOL talent pool makes outside hiring harder each year |
| 2. Rising cost of ownership | Beyond license and hardware fees, unclear impact analysis inflates testing. “Three months of testing for a one-line fix” slows every decision |
| 3. Declining maintainability | Decades of patches turn programs into black boxes. Figuring out whether a change is safe takes longer than making it |
| 4. End of platform support | Hardware and middleware lifecycles follow vendor timelines, not yours. Start late, and you may be forced into the fastest option rather than the right one |
| 5. Security and audit exposure | Unsupported platforms cannot always take current patches or encryption standards, leaving more areas where the answer is “not possible” |
| 6. Integration limits | Data locked inside the core keeps BI, data platforms, and AI half-finished. Each new point-to-point batch interface becomes tomorrow’s legacy |
| 7. Slower delivery | No matter how agile the front end becomes, overall speed is capped by the core system’s lead time |
| 8. Business continuity | “It runs, so it’s safe” is not resilience. Without people and procedures to recover it, a key-person-dependent core is a continuity risk |
Migration and Modernization Are Not the Same Thing
This is the most common misunderstanding at the start. Migration moves a system to a new environment; modernization rebuilds it into something easier to maintain and extend. They are different investment decisions. In practice, three approaches are combined by business domain.
| Approach | What it does | Best suited for | Watch out for |
|---|---|---|---|
| Replatform (rehost / platform move) | Moves the platform to open systems or the cloud while keeping most application logic intact | Domains facing imminent end-of-support with stable business requirements | Removes platform risk, but maintainability and key-person issues remain. Plan the next step |
| Refactor (COBOL → Java, etc.) | Converts COBOL into maintainable technology such as Java/Spring and restructures it | Core domains that will keep changing; widening the hiring pool | Pure machine translation produces “COBOL written in Java.” Define the target design up front |
| Reimagine (redesign capabilities) | Redesigns business capabilities with APIs, microservices, and cloud-native services | Differentiating domains that need integration or new channels | High cost and duration. Only works when scope is tightly focused |
The realistic answer is a mix
AI-Assisted Modernization: What to Delegate, and What Not To
AI is now widely used in modernization projects. But it cannot complete a project end to end on its own — at least not yet.
Where AI adds real value
- Classifying and inventorying source code (active / unused / duplicate)
- Application discovery and dependency mapping
- Generating documentation where specs have been lost
- Extracting and summarizing business logic; assisting code conversion
- Generating test cases, test automation, and migration wave planning
Where human judgment is required
- Business exceptions, e.g. “this branch is a rule for one specific customer”
- Historical context, e.g. “this rounding logic comes from our accounting policy”
- Deciding whether an output difference is a spec or a defect
- Final confirmation of functional equivalence — business users must be involved
BAP’s approach: AI-assisted, expert-led
How to Modernize COBOL: Five Phases
Application discovery and dependency mapping
Inventory programs, jobs, scripts, reports, and databases, and visualize call relationships and data flows. Identifying assets that are no longer used has a big impact on downstream scope. Interviews with business teams surface undocumented rules.
PoC and migration wave planning
Pick one business area of representative difficulty and prove out the conversion approach, architecture, and test method. The goal is not to show it can be done, but to estimate effort, quality, and risk at full scale. Use the results to split work into waves and choose a cutover method for each, including whether parallel running is needed.
Converting code, screens, data, and platforms
Alongside code conversion, modernize online screens for the web, rebuild reports, migrate data (including character encoding and data type differences), and move middleware and job operations. Keep full traceability of which COBOL program maps to which Java class.
Functional equivalence testing and QA
This is where modernization quality is decided. You must be able to prove, with evidence, that old and new systems return the same result for the same input.
Unit testing Component testing Batch output comparison Integration testing Data reconciliation System testing Performance testing (batch windows) Security testing Regression testing User acceptance testing (UAT)
Cutover, stabilization, and continuous improvement
Prepare runbooks together with rollback criteria, and strengthen monitoring right after cutover. Modernization does not end at go-live: the investment pays back as you build on the new, maintainable structure with APIs and cloud services.
The Business Value of Modernization
| Value | What it means |
|---|---|
| Lower operational risk | Exit unsupported platforms and broaden the pool of people who can respond to incidents |
| Less key-person dependency | Move to technologies like Java with a far larger talent pool |
| Better maintainability | Clear structure and documentation cut investigation effort for every change |
| Faster release cycles | Predictable impact lets you scope testing rationally |
| Integration readiness | Create connection points for APIs, cloud, data platforms, and AI |
| Preserved business logic | Carry decades of proven business rules forward in an explainable form |
| Better user experience | Web-based screens remove device, browser, and usability constraints |
*Cost reduction and payback periods vary widely with asset size, structure, and business requirements. Targets should be set from an assessment of your actual assets.
BAP Project Example: Moving Core Operations Without Changing Business Processes
BAP took part in a project to move core operations — order management, production, inventory, and shipping — from a legacy system to a new platform, on the condition that existing business processes would not change.
~90
user screens
~300
application programs
~85
batch and operational scripts
~65
database tables
BAP handled on-site requirements validation and system analysis, proposed the migration approach, supported development, and ran component testing, system testing, and UAT. A “no process change” constraint means proving functional equivalence becomes the heart of the project — which is why building testing into the design from the start matters so much.
How BAP Can Help
| Area | Scope |
|---|---|
| Assessment and analysis | Asset inventory, dependency mapping, business interviews, comparison of migration options |
| PoC | Validation before full rollout, improving estimates of effort, quality, and risk |
| Phased migration | Design and execution of migration waves by business area and data domain |
| Development | COBOL-to-Java conversion, Java/Spring development, rebuilding web screens and reports |
| Platform and data | Platform and middleware migration, data migration and reconciliation |
| Quality assurance | End-to-end testing from unit to UAT, batch comparison, performance and security testing |
| Delivery model | Offshore, onsite, or hybrid — in English, Japanese, Korean, and Vietnamese |
| Post-modernization support | Stabilization, ongoing maintenance, and enhancements |
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.
Frequently Asked Questions
Q. Is modernization complete once COBOL is converted to Java?
A. No. Copying COBOL control structures into Java produces “COBOL written in Java,” and investigation effort barely changes. Conversion must go hand in hand with redefining package structure, data access, and exception handling.
Q. We have no design documents at all. Can we still migrate?
A. Yes — this is common. We reconstruct specifications by cross-checking source code, job definitions, and real data behavior, then confirm intent with business teams. AI-based analysis and documentation are especially effective here.
Q. Should we choose a big-bang or phased migration?
A. It depends on how much downtime the business can tolerate and the size of the estate. Big-bang reduces parallel-running effort but makes rollback harder. Phased migration lowers risk per step but requires designing old-new data integration. Decide based on PoC results.
Q. Will our business processes change after migration?
A. Not if equivalence is tested properly. Compare old and new outputs, investigate every difference, and confirm with business teams whether it is a spec or a defect. There is no shortcut.
Q. End of support is still years away. Should we start now?
A. Yes. Assessment and decision-making alone take time, followed by migration, testing, and stabilization. Starting close to the deadline tends to limit you to replatforming. Begin with an asset inventory and dependency mapping.
Talk to BAP About COBOL Modernization
- Assessment: inventory of current assets and dependency mapping
- Issue mapping: staffing, maintenance load, and platform support deadlines
- Roadmap: approach allocation by domain and migration wave design
- PoC: validate the approach and estimates before a major investment
Even if you have not settled on a direction internally, tell us about your current system and we will outline the key questions and a practical way forward.
