Mainframe ↔ Java architect
Bridge 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, internal parity audit per batch.
Progressive go-live with strangler fig, mainframe ↔ Java coexistence with duration set at scoping based on risk profile, batched transactional cutover, ops handover to client team.
Automatic legacy-code conversion tools produce code that compiles but stays unreadable and unmaintainable: original patterns are copied as-is, without idiomatization, with dependencies on a proprietary runtime. Pushed to production without full re-characterization, this code is neither reliable nor scalable. End-to-end automatic translation isn't a modernization method — it's a debt transfer.
Our approach is the opposite. ATLAS relies on multiple readings of the legacy code, from several angles: data flows, business rules, dependencies, edge cases. AI comes in as a comprehension accelerator — to decipher decades of accumulated business logic, reverse-document uncommented branches, surface the intent behind the code. It doesn't decide and it doesn't translate: it informs the architect's work, who then designs the target architecture (cloud, database, services) and drives the migration pattern by pattern, under parity audit.
This understanding still requires humans who know legacy languages. That's our edge: where Europe and North America face a retirement wave among mainframe and legacy developers, Tunisia retains a pool of experienced developers (COBOL, Delphi, PowerBuilder, RPG…). Paired with modern architects and developers trained in the ATLAS method, they ensure continuity between the original business intent and the target system.
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 structured as a sequence of functional batches, with the cadence set at scoping based on volume and criticality. The typical cell combines a senior legacy architect, a Java tech lead, Java and COBOL developers, QA engineers specialized in characterization tests, and a delivery director. Composition and headcount are not fixed upfront: they are determined after the POC and scoping, once the real work has been measured. Each batch delivers a parity-validated functional subset before the next one starts.
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, 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: eight 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
Multiple internal POCs covering representative scopes (banking, insurance, sovereign tax, retail, CRM). COBOL to Java and TypeScript patterns validated, type discrepancy registry maintained, proven decimal arithmetic mapping.
Our measurements across ten multi-sector POCs confirm a migration productivity significantly above classical approaches. The exact pace varies depending on source code complexity, discovery maturity, and the size of the mobilized cell. 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 a few senior COBOL developers during the coexistence phase, 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. Once the business knowledge has been sufficiently absorbed on the target side, these profiles 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, based on 2026 market benchmarks and our nearshore quality positioning, a modernization program of fifty thousand lines of mainframe COBOL typically lands between 100k and 400k euros depending on complexity, parity tests and documentation included. For a five hundred thousand line estate, plan a multi-year budget of one to four million euros depending on complexity (market sources: Gartner / Forrester estimate $1.5-$4 USD/LOC global market, Tunisia nearshore quality positions mid-range). 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 internal classified 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.
Yes, but not on its own — and not on every codebase. AI accelerates two things on a COBOL program: reading legacy code (mapping intent, finding dead branches, extracting business rules from PERFORM/GO TO logic) and writing target code pattern by pattern with traceability. We measure 2x to 3x throughput on legacy migration when AI is paired with a structured methodology and human review. What AI does not replace: the discovery phase, the characterization tests written before any target code is touched, and the parity audit on real datasets. Tools that promise fully automated COBOL-to-Java conversion (Blu Age, Heirloom, AWS Mainframe Modernization) deliver useful first drafts but rarely production-grade output without senior engineering review. Our position: AI is the default operating mode (vibe coding) inside the ATLAS methodology — never a replacement for it.
It depends on your stack, your talent pool, and your operational ambitions. Choose Java for large mainframe estates with heavy batch processing, where the JVM ecosystem (Spring Batch, Kafka Streams, Hadoop, Spark) maps cleanly to COBOL transactional and analytical workloads. Java has the deepest library coverage on financial transactions and the largest senior talent pool globally. Choose .NET Core 8 when the broader IT ecosystem is Microsoft (Azure, Dynamics 365, Power Platform, SQL Server) — interop drops effort by 20-30% on integration plumbing alone. Both languages are now mature options for COBOL modernization; the differentiator is no longer language quality, it's organizational fit. For analytical batches or scientific computing, look at COBOL to Python instead. For a serverless web target, COBOL to TypeScript. The ATLAS methodology handles these targets with the same characterization-test-driven approach.
It depends on volume, complexity, and modernization ambition. ATLAS delivers in successive functional batches rather than on a monolithic plan: each batch is defined with you at scoping, delivered with validated parity, then the next one starts. The variable that drives duration is rarely the line count itself — it's how messy the legacy is (decades of accumulated business rules, undocumented branches, GO TO chains, dead code). Multi-million-line estates with embedded CICS and 5250 logic are systematically broken into sub-systems via the strangler-fig pattern. A 2-6 week POC on the client's actual codebase measures real productivity and prices the full program. The ATLAS methodology sets kill/go gates between steps so the program never drifts.
Three categories of tools, with very different positioning. Vendor-led conversion suites: Blu Age (now part of AWS), Heirloom Computing, Micro Focus Visual COBOL. These produce Java that compiles, but the output is rarely idiomatic and often unmaintainable without senior engineering review. Cloud-vendor offerings: AWS Mainframe Modernization (using Blu Age), IBM Watson Code Assistant for Z. These work as a starting point but lock you into the vendor's runtime. Frontier coding assistants in vibe-coding mode: Claude Code, GitHub Copilot, Cursor, plus proprietary agents. This is what we use in ATLAS — they read COBOL, propose target patterns, generate characterization tests, and document business rules, all under human review. Productivity 2x to 3x vs manual baseline. The key insight: tools accelerate the work, but none of them replace the discovery, parity testing, and discrepancy adjudication that make a migration trustworthy.
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.