Mainframe ↔ Java architect
1Bridge between z/OS, AS/400, or Unisys and the modern Java ecosystem
Loading...
Loading...
Modernization of COBOL applications running on z/OS mainframe, AS/400, or Unisys to Java 21, using the ATLAS methodology. Existing-system capture, characterization tests, pattern-by-pattern migration, parity audit.
Each phase aggregates one or more of the ten ATLAS steps. No phase starts until the previous one has delivered its validated artefact. The ATLAS methodology makes AS/400 migration predictable and auditable.
Understand the existing COBOL estate, programs, copybooks, JCL. Rebuild a functional analysis. Define scope, constraints, success criteria.
Set the ground truth: recorded transactions, input/output files, printed reports. Map subsystems, VSAM files, DB2/IMS databases, CICS integrations.
Design the target Java architecture: Spring Boot, microservices or monolith, PostgreSQL/Oracle database, cloud or on-premise hosting. Prepare characterization tests.
Translate COBOL → Java pattern by pattern: COPY → Java classes, PERFORM → methods, PIC S9(n)V9(n) → BigDecimal. Incremental migration, signed parity audit per batch.
Progressive go-live with strangler fig, mainframe ↔ Java coexistence for 6 to 24 months, batched transactional cutover, ops handover to client team.
COBOL estates on mainframe primarily belong to universal and corporate banks, life and P&C insurers, central public administrations, pension and social security funds, and a handful of historical telecom operators and industrial players. The equation is always the same: a transactional core written between the 1980s and 2000s, still in production, carrying critical business rules (premium calculations, pricing, tax bases, scoring, provisioning) whose documentation is partial.
Two forces are driving migration today. First, the retirement of a generation of COBOL engineers: profiles trained in the 1990s are progressively leaving the market and few are being trained as replacements. Second, the planned end of support of certain legacy platforms and the pressure from executive committees to rationalize infrastructure costs. Our ATLAS methodology is precisely designed to make this transition predictable, with no service interruption.
Among the possible trajectories — Java, .NET Core, TypeScript, Python — Java remains the default choice in three situations. When the target is a high-availability transactional system. When Java skills are already present in-house or in the integrator ecosystem working with your IT department. When the company anticipates other migrations to the same stack to pool expertise. If one of the three points does not match, look at the COBOL to .NET Core or COBOL to TypeScript paths.
High-availability transactional system, Java skills already in-house, need to pool with other migrations to the same stack. The default choice for large banks and administrations.
Microsoft ecosystem dominant in the target IT, presence of Azure or Dynamics 365, teams more comfortable with C#. See the COBOL to .NET Core path.
Migration to a serverless architecture, moderate transactional volumes, priority on velocity of evolution and operating cost. See the COBOL to TypeScript path.
Dominant analytical or batch components, proximity with the data and AI ecosystem, multidisciplinary data + dev teams.
A COBOL to Java modernization program is typically structured over twelve to thirty-six months depending on volume and criticality. The typical cell combines a senior legacy architect, a Java tech lead, four to eight Java and COBOL developers, one to two QA engineers specialized in characterization tests, and a delivery director. For an estate of twenty thousand to one hundred thousand lines of COBOL, plan six to twelve months with a cell of five to eight people. Beyond that, a structuring program mobilizes fifteen to thirty people over two to three years.
Migrating without characterization tests written upstream on the legacy. The target code then becomes the new specification and any drift is unrecoverable.
Principle P1 — tests first, migration second. The test suite characterizes the legacy before any line of target code is touched. On our Portfolio POC (7,972 lines of COBOL), this discipline detected five discrepancies including two business-critical ones before delivery. See the full ATLAS methodology.
Refactoring during migration. Mixing translation and redesign makes regressions indistinguishable — migration drift or redesign drift?
Redesign happens once parity is proven. We migrate isofunctionally first, then in a second contractually distinct phase, we redesign the areas that deserve it.
Underestimating COBOL arithmetic specifics: COMP-3, PIC S9(n)V9(n), silent overflow on financial calculations.
Systematic mapping of COMP-3 and PIC to BigDecimal in Java with explicit scale and rounding mode. Boundary tests (overflow, underflow, division by zero) added to the characterization suite.
Translating programs one by one rather than by functional blocks. COBOL code typically contains thirty percent of replaceable infrastructure that can be substituted by Java framework primitives.
Migration by functional blocks with mapping CICS to REST, VSAM to JPA/PostgreSQL, JCL to Spring Batch. Typical productivity ratio observed: ten lines of COBOL per one line of Java.
Declaring the migration complete after code conversion, without validating end-to-end workflows under real conditions.
Principle E7 — browser and business workflow validation mandatory before delivery. On our CardDemo POC, the first delivery had been validated through API tests but the remote database was not initialized. This lesson reshaped our deployment checklist.
Several distinct profiles, mobilized over the full program duration. Reproducing this cell internally is rarely realistic — the legacy skills shortage and ATLAS expertise depth make outsourcing structurally faster and less risky.
Bridge between z/OS, AS/400, or Unisys and the modern Java ecosystem
Java 21, Spring Boot, COBOL→Java migration patterns, line-by-line traceability
Ideally with COBOL background to understand accumulated business logic
DB2, IMS, or VSAM schema migration, data parity audit
Containerization, CI/CD, observability, mainframe/cloud coexistence
Test bench, legacy/target comparison, ATLAS audit validation
Multi-year program to modernize a COBOL estate on IBM z/OS mainframe, several mission-critical transactional systems running 24/7 in production. Co-delivery with a North American prime contractor under the ATLAS methodology.
More than 35,000 lines of COBOL converted to Java and TypeScript across ten POCs (banking, insurance, sovereign tax, retail, CRM). Writing ratio of 10 to 1, 39 COBOL patterns covered, 44 discrepancies detected and classified.
Our measurements across ten POCs covering more than thirty-five thousand lines establish a typical productivity of eight to fifteen thousand lines of COBOL migrated per month per cell of five to eight people, characterization tests included. This pace assumes a completed upstream discovery: if the code must be deciphered while being translated, productivity drops by half. See our ATLAS methodology for the detailed protocol.
We recommend keeping two to three senior COBOL developers for at least twenty-four months after the cutover, even if the COBOL code is replaced. These profiles remain valuable for two reasons: resolving interpretation ambiguities on undocumented business rules, and supporting parity tests on edge cases rarely covered by documentation. After two years, the business knowledge has been sufficiently absorbed on the target side for these profiles to evolve into architecture or governance roles.
CICS transactions are migrated to REST endpoints or Spring services with Spring Transaction management. CICS commareas become typed DTOs. Pseudo-conversational flows are rewritten as stateless workflows with state preserved in HTTP session, database, or Redis depending on criticality. ABEND error handling is replaced by an Exception hierarchy pattern with structured logging.
Yes, this is even strongly recommended. The ATLAS methodology applies the strangler fig pattern — we migrate subsystem by subsystem, starting with the least critical transactions, then the critical ones once the cell has matured. During the coexistence period, mainframe and target systems communicate through gateways (Kafka, API gateway, MQ). This approach spreads risk across the whole program. See the Legacy to Cloud expertise for detailed patterns.
Cost depends on volume, criticality, and engagement model. As a benchmark, a modernization program of fifty thousand lines of mainframe COBOL in nearshore co-delivery typically lands between eight hundred thousand and one million two hundred thousand euros, parity tests and documentation included. For a five hundred thousand line estate, plan a multi-year budget of three to eight million euros depending on complexity. We frame the cost during the Intake phase with an explicit range. See the delivery models for the contractual formats.
This is the role of the signed discrepancy registry at program closure: every identified, weighted, and validated or compensated discrepancy is explicitly listed. If an unlisted discrepancy appears after cutover, it is handled under warranty mode per the contractual clauses. Our protocol: reopen the parity audit on the affected scope, qualify the discrepancy, produce a fix with associated tests, and record it as an annex to the registry. This case remains rare because discrepancies are generally detected during the parallel runs phase before cutover.
Three concrete ways to start — from a free diagnosis to a full cell. Our COBOL → Java 21 approach is documented, priced, and applicable from the first meeting.