The system works. That is precisely what makes it hard to talk about.<\/p>\n
Order management, production, inventory, shipping, settlement \u2014 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?<\/strong> A new sales channel, a partner API, a data platform, a forecasting model \u2014 each one stalls at the same gate. Over time, the roadmap quietly shrinks to fit what the core system will tolerate.<\/p>\n 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 \u2014 including the testing that determines whether the whole thing succeeds.<\/p>\n 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.”<\/p>\n 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 \u2014 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Hardware and middleware lifecycles move on vendor timelines, not yours. When a platform reaches end-of-support, the decision window narrows \u2014 and the later you start, the more likely you are forced into the fastest option rather than the right one.<\/p>\n 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.”<\/p>\n When core data is locked inside the legacy estate, analytics, data platforms and AI initiatives all end up partial. The usual workaround \u2014 another point-to-point batch feed \u2014 creates the next generation of legacy.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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 \u2014 an approach AWS also describes in its guidance on disposition strategies for mainframe application modernization<\/a>.<\/p>\n For a large estate, the useful question is not “which one?” but “which one, where?”<\/strong> 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.<\/p>\n 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:<\/p>\n What AI cannot do is close the program on its own. Legacy code encodes more than logic: it encodes exceptions, workarounds and history<\/strong>. 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 \u2014 static analysis surfaces these as code, not as intent. Only someone who knows the business can classify them.<\/p>\n This is why the working model should be AI-assisted and expert-led, with humans in the loop<\/strong>. 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 \u2014 it is the only credible basis for declaring functional equivalence.<\/p>\n 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.<\/p><\/blockquote>\n 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.<\/p>\n Do not start at full scale. Select one representative slice \u2014 ideally a genuinely awkward one \u2014 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<\/strong>. The results then drive how you split the estate into migration waves, and how each wave cuts over, including whether parallel running is required.<\/p>\n 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.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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.<\/p>\n 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<\/strong>.<\/p>\n The scope covered approximately:<\/p>\n 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.<\/p>\n 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 \u2014 it is the central deliverable, and test design has to be built into the program from the discovery phase onward.<\/p>\n 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 \u2014 a standard that transfers well to any core system programme.<\/p>\n No. Mapping COBOL control structures directly onto Java produces code that is technically modern and practically unchanged \u2014 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n We work with organizations at every stage of this decision, including the earliest one. Engagements typically start with:<\/p>\n 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.<\/p>","protected":false},"author":43,"featured_media":164826,"template":"","meta":{"_acf_changed":false},"tags":[],"blog-cat":[],"class_list":["post-164825","knowledge","type-knowledge","status-publish","has-post-thumbnail","hentry"],"acf":[],"yoast_head":"\nWhy COBOL modernization has moved up the board agenda<\/h2>\n
1. Talent risk and key-person dependency<\/h3>\n
2. Rising cost of ownership<\/h3>\n
3. Declining maintainability<\/h3>\n
4. Platform and middleware end-of-support<\/h3>\n
5. Security and audit exposure<\/h3>\n
6. Integration and data access<\/h3>\n
7. Time to market<\/h3>\n
8. Operational resilience<\/h3>\n
Migration is not the same as modernization<\/h2>\n
\n\n
\n \nApproach<\/th>\n What it does<\/th>\n Best fit<\/th>\n What it does not solve<\/th>\n<\/tr>\n<\/thead>\n \n Replatform<\/strong><\/td>\n Moves the application to an open or cloud platform while keeping most of the application and business logic intact.<\/td>\n End-of-support pressure; stable business requirements; the priority is removing infrastructure risk quickly.<\/td>\n Maintainability and key-person dependency remain. Plan the next step before you finish this one.<\/td>\n<\/tr>\n \n Refactor<\/strong><\/td>\n Converts COBOL into a maintainable stack \u2014 typically Java and Spring \u2014 and restructures the code around it.<\/td>\n Core domains that will keep changing; areas where you need a larger hiring pool.<\/td>\n Automated conversion alone produces “COBOL written in Java.” Target architecture must be defined up front.<\/td>\n<\/tr>\n \n Reimagine<\/strong><\/td>\n Redesigns selected business capabilities using APIs, microservices, event-driven patterns or cloud-native services.<\/td>\n Differentiating capabilities; functions that must expose or consume external services.<\/td>\n Cost and duration. Applied across a whole estate, it rarely completes.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n AI-assisted, expert-led modernization<\/h2>\n
\n
The five phases of a COBOL modernization program<\/h2>\n
Phase 1 \u2014 Application discovery and dependency mapping<\/h3>\n
Phase 2 \u2014 Proof of concept and migration wave planning<\/h3>\n
Phase 3 \u2014 Converting code, screens, data and platform<\/h3>\n
Phase 4 \u2014 Functional equivalence testing and quality assurance<\/h3>\n
\n
Phase 5 \u2014 Cutover, stabilization and continuous improvement<\/h3>\n
Business outcomes to expect<\/h2>\n
\n
How BAP has delivered this work<\/h2>\n
\n
What BAP brings to a modernization program<\/h2>\n
\n\n
\n \nArea<\/th>\n Capability<\/th>\n<\/tr>\n<\/thead>\n \n Assessment<\/td>\n Asset inventory, dependency mapping, business interviews, comparison of migration options<\/td>\n<\/tr>\n \n Proof of concept<\/td>\n Validating approach and improving estimate accuracy before large-scale commitment<\/td>\n<\/tr>\n \n Incremental migration<\/td>\n Wave design and execution by business domain and data domain<\/td>\n<\/tr>\n \n Development<\/td>\n COBOL-to-Java conversion, Java\/Spring development, web screen and report rebuild<\/td>\n<\/tr>\n \n Platform and data<\/td>\n Platform and middleware migration, data migration and reconciliation<\/td>\n<\/tr>\n \n Quality assurance<\/td>\n End-to-end testing from unit through UAT, batch comparison, performance and security validation<\/td>\n<\/tr>\n \n Delivery models<\/td>\n Offshore, onsite and hybrid; support in English, Japanese, Korean and Vietnamese<\/td>\n<\/tr>\n \n Post-modernization<\/td>\n Stabilization support, ongoing maintenance and incremental enhancement<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n Frequently asked questions<\/h2>\n
Does converting COBOL to Java complete the modernization?<\/h3>\n
We have almost no documentation. Is migration still viable?<\/h3>\n
Big bang or incremental cutover?<\/h3>\n
How do we guarantee the business does not change?<\/h3>\n
Our platform is supported for several more years. Why start now?<\/h3>\n
What is a sensible first step?<\/h3>\n
Talk to BAP about your COBOL estate<\/h2>\n
\n