Mainframe ↔ serverless cloud architect
Bridge between z/OS or AS/400 and the Node.js / serverless edge ecosystem
Loading...
Loading...
Modernization of COBOL batch applications to TypeScript, Node.js architecture, and cloud. ATLAS methodology, proven functional parity.
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 batch COBOL estate: programs, copybooks, JCL, overnight processing chains. Rebuild a functional analysis. Define scope, constraints, success criteria.
Set the ground truth: input/output datasets, printed reports, exchange files. Map batch flows, VSAM/QSAM files, DB2 databases, scheduling.
Design the target TypeScript architecture: Node.js or Cloudflare Workers, PostgreSQL/D1 database, job orchestration, cloud cost benchmark. Prepare characterization tests.
Translate COBOL → TypeScript pattern by pattern: COPY → typed modules, PERFORM → functions, PIC S9(n)V9(n) and COMP-3 → decimal.js. Batch parallelization, internal parity audit per batch.
Progressive go-live with strangler fig, parallel runs legacy ↔ TypeScript, batched cutover of processes, 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.
Migrating COBOL to TypeScript is a trajectory increasingly chosen by IT departments looking to move from a monolithic mainframe to a cloud-native serverless architecture. TypeScript offers two decisive advantages over Java or .NET on the right perimeters: a drastically reduced execution cost through serverless runtimes (Cloudflare Workers, Azure Functions, AWS Lambda, Deno), and a higher velocity of evolution thanks to the npm ecosystem and a structural typing more flexible than Java.
TypeScript fits particularly well with COBOL batch perimeters (overnight processing, reporting, ETL, extracts) and moderate-volume transactions (under one thousand transactions per second). Typical sectors: growing fintechs that do not want to invest in heavy Java infrastructure, telecom and media oriented serverless, digitized administrations that have adopted cloud-first APIs, niche banks looking to quickly exit a costly mainframe. For very high-volume transactions (more than ten thousand TPS), look instead at COBOL to Java or COBOL to .NET Core.
Our internal POCs have converted COBOL to TypeScript on Cloudflare Workers across three representative cases (CardDemo, Portfolio, CBSA). The observed ratio is 10:1 (10 lines of COBOL per 1 line of TypeScript) — higher than the Java ratio (7:1) because TypeScript avoids Spring boilerplate. Vibe coding assisted by AI (Claude Code, GitHub Copilot) accelerates conversion by 2 to 3 times in this modern language. See the ATLAS methodology applied on these POCs.
Serverless architecture, moderate volumes, minimal operating cost, global edge distribution. The default choice for agile fintechs and telecoms.
Classic containerized architecture, need for fine control over infrastructure, on-premise or multi-cloud compatible.
Modern ecosystem, security by default, native TypeScript without compilation. Suited to greenfield projects or migrations where an emerging stack is acceptable.
Very high transactional volumes, strong in-house Java skills. See COBOL to Java.
Microsoft ecosystem dominant. See COBOL to .NET Core.
A COBOL to TypeScript migration is structured as a sequence of functional batches, with the cadence set at scoping based on volume and criticality. The typical cell combines a serverless cloud architect, a senior TypeScript tech lead, TypeScript developers ideally with a Java or C# background, a QA 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. TypeScript generally allows a more compact cell than Java or .NET.
Using the JavaScript number type to port COBOL PIC S9(n)V9(n) and COMP-3. Floating-point rounding errors are guaranteed on any financial calculation.
Systematic mapping of PIC and COMP-3 to the decimal.js library or BigDecimal via BigInt. Financial calculations are encapsulated in a Money class with explicit scale and rounding mode. Unit parity tests on overflow, underflow, division by zero, comparison with COBOL outputs on representative datasets.
Reproducing sequential COBOL batch processing in TypeScript without exploiting native Node.js parallelization. The result is a slow batch that does not benefit from cloud advantages.
Explicit parallelization with Promise.all, worker_threads, or job queue (BullMQ, Cloudflare Queues). Splitting large batches into idempotent jobs orchestrated by a scheduler. Observability via structured logs (Pino, Winston) and metrics (Prometheus, Cloudflare Analytics).
Neglecting the difference in cloud billing model. COBOL batch bills on infrastructure, serverless bills per execution. A poorly optimized batch can become expensive at scale.
Cloud cost benchmark integrated in the target architecture phase. For very large batches, arbitration between Cloudflare Workers (edge, low latency) and Azure Container Apps or AWS Fargate (long-running, predictable cost). Monthly cost estimate validated before deployment.
Porting sequential COBOL files (VSAM, QSAM) to naive relational tables without rethinking the model. Positioned access becomes SQL full scans, catastrophic performance.
Relational modeling adapted to target queries. VSAM indexed files become tables with composite indexes suited to the access patterns identified during discovery. Sequential COBOL queries are ported to TypeScript streams with cursor-based pagination to avoid full memory loading.
Declaring the migration complete without validating end-to-end workflows in production with real volumes. On our Portfolio POC, the first delivery was validated through API tests but the browser dashboard did not work because the remote D1 database was not initialized.
Principle E7 — browser and workflow validation mandatory before delivery. Deployment checklist including: schema initialized in target environment, seed data loaded, API smoke tests passed, browser smoke tests passed, complete workflow replayed. This checklist emerged from honest self-criticism of our POCs. See the ATLAS methodology.
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 or AS/400 and the Node.js / serverless edge ecosystem
TypeScript, Node.js, Cloudflare Workers or containers, COBOL→TS migration patterns, line-by-line traceability
Ideally with a Java or C# background to port accumulated business logic
VSAM/QSAM file migration, relational modeling, data parity audit
Containerization, CI/CD, observability, cloud cost benchmark, batch parallelization
Characterization test bench, legacy/target comparison, ATLAS audit validation
Internal Access POC: migration of CICS COBOL (AWS CardDemo, Apache 2.0) to TypeScript on Cloudflare Workers. COBOL programs, copybooks, D1 tables, REST endpoints, HTML dashboard. Functional parity validated on 6/6 browser workflows, three discrepancies detected including one business-critical (overlimit/expiry cascade).
Internal Access POC: migration of COBOL to TypeScript on Cloudflare Workers with Hono and D1. Programs and copybooks ported, REST endpoints, HTML dashboard, five discrepancies detected including two business-critical (SELL cost_basis and position delete).
Yes, subject to volume. TypeScript via Node.js or Cloudflare Workers is perfectly suited to moderate-volume transactions (up to one thousand TPS) with sub-second latencies. For higher volumes, look at COBOL to Java or COBOL to .NET Core. The real sweet spot of TypeScript for COBOL: batch and event-driven workloads where the serverless model shines.
Cloudflare Workers runs in 325 cities worldwide at the edge, with a cold start latency of a few milliseconds (vs several hundred for AWS Lambda). It offers a simple pricing model (per request) and a native D1 integration (distributed SQLite) for relational storage. Azure Functions is preferable if your IT is already in the Microsoft ecosystem. AWS Lambda if the AWS ecosystem dominates. Cloudflare Workers if you start from scratch and seek the best performance/cost ratio for serverless edge.
Never use the JavaScript `number` type for financial calculations. Use decimal.js (mature, widely adopted) or BigDecimal via BigInt (more performant but less ergonomic). Encapsulate any financial operation in a Money or Decimal class with explicit scale, currency, and rounding mode. Unit parity tests on each calculation with comparison to COBOL outputs on representative datasets. decimal.js covers 95 percent of cases.
Yes, generally even better. A sequential COBOL batch can be ported to TypeScript with parallelization via worker_threads or Promise.all, and executed on a cluster (Kubernetes, Cloudflare Queues). On our POCs, migrated batches are 2 to 5 times faster than their COBOL equivalent thanks to parallelization and co-location with the database. Exception: batches with strong sequential dependency (accounting with cumulative totals) where linearity is intrinsic.
For thirty thousand lines of batch COBOL in nearshore co-delivery, plan five hundred thousand to seven hundred thousand euros parity tests and documentation included — cheaper than Java or .NET thanks to the 10:1 ratio that reduces target code volume. For one hundred thousand lines, budget one to two million euros. See the delivery models for contractual formats.
Vibe coding designates legacy code conversion assisted by AI (Claude Code, GitHub Copilot, Cursor) framed by our ATLAS methodology. AI accelerates pattern-by-pattern translation by 2 to 3 times but does not replace discovery or characterization tests. We measured these gains on our 10 POCs, documented in our article Vibe coding: AI-augmented consultants.
Three concrete ways to start — from a free diagnosis to a full cell. Our COBOL → serverless TypeScript approach is documented, priced, and applicable from the first meeting.