Modernization path

Migrate a COBOL batch estate to TypeScript and Node.js.

Q: Is TypeScript really suited to transactional COBOL?

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.

Q: What is the advantage of Cloudflare Workers over Azure Functions or AWS Lambda?

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.

Q: How is financial arithmetic handled in TypeScript?

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.

Q: How much does a COBOL to TypeScript migration cost?

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.

Q: What is vibe coding and how does it accelerate migration?

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.

Modernization of COBOL batch applications to TypeScript, Node.js architecture, and cloud. ATLAS methodology, proven functional parity.

Key figures

240 B

lines of COBOL still in production worldwide

Reuters / IBM 2022

10:1

rewrite ratio from COBOL to modern TypeScript

By batches

incremental delivery, duration set at scoping

ATLAS methodology applied

From scoping to deployment, five structured phases.

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.

01Phase 1
Scoping
ATLAS steps
E1 Intake · E2 Discovery · E2b Functional spec
Understand the existing batch COBOL estate: programs, copybooks, JCL, overnight processing chains. Rebuild a functional analysis. Define scope, constraints, success criteria.
Phase deliverable
Estate inventory + functional spec + pricing
02Phase 2
Capture & dependencies
ATLAS steps
E2e Capture · E3 Dependency mapping
Set the ground truth: input/output datasets, printed reports, exchange files. Map batch flows, VSAM/QSAM files, DB2 databases, scheduling.
Phase deliverable
Reference dataset bench + complete map
03Phase 3
Target architecture
ATLAS steps
E4 Target architecture · E4b Pre-migration tests
Design the target TypeScript architecture: Node.js or Cloudflare Workers, PostgreSQL/D1 database, job orchestration, cloud cost benchmark. Prepare characterization tests.
Phase deliverable
Signed target architecture + test suite
04Phase 4
Migration & parity
ATLAS steps
E5 Migration · E6 Parity validation
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.
Phase deliverable
TypeScript code + parity audit per process
05Phase 5
Deployment & handover
ATLAS steps
E7 Delivery
Progressive go-live with strangler fig, parallel runs legacy ↔ TypeScript, batched cutover of processes, ops handover to client team.
Phase deliverable
Pipelines in production + autonomous client team

See the full ATLAS methodology →

At the core of the ATLAS method

AI to understand COBOL, not to translate it.

Porting COBOL to TypeScript exposes a gap converters ignore: COBOL computes in exact decimal, JavaScript in binary floating point. A literal conversion of financial arithmetic introduces rounding drift invisible in unit tests and visible at accounting close. 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 source code, from several angles. Here, what we read first: sequential batch processing to rethink as asynchronous services, and any monetary arithmetic to isolate in a dedicated decimal library. AI comes in as a comprehension accelerator, to decipher years 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 and drives the migration pattern by pattern, under parity audit.

This understanding still requires humans who know the source technologies. That's our edge: where Europe and North America face a retirement wave on these skills, Tunisia retains experienced COBOL developers, paired with Node.js architects. Together they ensure continuity between the original business intent and the target system.

Who is concerned

Business context and modernization stakes.

Why TypeScript to modernize COBOL

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.

COBOL perimeters suited to TypeScript

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 TypeScript field experience

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.

Source platform

COBOL batch (mainframe, AS/400)

AS/400↗COBOL↗

Target technology

TypeScript, Node.js, PostgreSQL, containers

TypeScript↗PostgreSQL↗Node.js↗

Technology alternatives

Compare target trajectories.

TypeScript + Cloudflare Workers + D1

Serverless architecture, moderate volumes, minimal operating cost, global edge distribution. The default choice for agile fintechs and telecoms.

TypeScript + Node.js + PostgreSQL + Kubernetes

Classic containerized architecture, need for fine control over infrastructure, on-premise or multi-cloud compatible.

TypeScript + Deno + Deno KV

Modern ecosystem, security by default, native TypeScript without compilation. Suited to greenfield projects or migrations where an emerging stack is acceptable.

Java 21 + Spring Boot

Very high transactional volumes, strong in-house Java skills. See COBOL to Java.

.NET Core 8 + Azure

Microsoft ecosystem dominant. See COBOL to .NET Core.

Scoping reference

Typical duration and team for this path.

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.

Challenges

Porting COBOL decimal arithmetic to TypeScript with adapted libraries (decimal.js).
Transforming sequential batch processing into observable Node.js pipelines.
Migrating sequential files to relational databases or Kafka streams.

ATLAS approach

Existing-system capture and mapping of batch flows.
Characterization tests on representative datasets.
Pattern-by-pattern migration with parallel runs and parity audit.

Expected outcomes

Observable TypeScript pipelines, deployable in containers.
Automated regression tests.
Technical documentation and internal classified discrepancy registry.

Identified pitfalls and ATLAS response

What we learned on this migration path.

Pitfall 01

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.

ATLAS response

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.

Pitfall 02

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.

ATLAS response

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).

Pitfall 03

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.

ATLAS response

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.

Pitfall 04

Porting sequential COBOL files (VSAM, QSAM) to naive relational tables without rethinking the model. Positioned access becomes SQL full scans, catastrophic performance.

ATLAS response

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.

Pitfall 05

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.

ATLAS response

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.

Related expertise

Legacy to Cloud

See modules, services, and use cases.

Proprietary methodology

ATLAS methodology

10 steps, 9 principles, proven parity.

Cell composition

A specialized cell for this modernization path.

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.

Duration

Set at scoping based on volume and criticality

Volume

Determined after the POC and scoping

Profiles

Mainframe ↔ serverless cloud architect

Bridge between z/OS or AS/400 and the Node.js / serverless edge ecosystem

TypeScript Tech Lead

TypeScript, Node.js, Cloudflare Workers or containers, COBOL→TS migration patterns, line-by-line traceability

TypeScript developers

Ideally with a Java or C# background to port accumulated business logic

Sequential files → PostgreSQL/D1 DBA

VSAM/QSAM file migration, relational modeling, data parity audit

Serverless cloud & DevOps engineer

Containerization, CI/CD, observability, cloud cost benchmark, batch parallelization

QA & functional parity

Characterization test bench, legacy/target comparison, ATLAS audit validation

Access field experience

This path in real conditions.

CardDemo POC (AWS Mainframe Sample)

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).

ratio 7.4:1 · 3 discrepancies · 6/6 workflows validated

Portfolio Management POC

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).

ratio 10:1 · 5 discrepancies · serverless architecture

Frequently asked questions

What decision-makers ask about this path.

Is TypeScript really suited to transactional COBOL?+

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.

What is the advantage of Cloudflare Workers over Azure Functions or AWS Lambda?+

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.

How is financial arithmetic handled in TypeScript?+

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.

Can the performance of a COBOL batch be maintained in TypeScript?+

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.

How much does a COBOL to TypeScript migration cost?+

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.

What is vibe coding and how does it accelerate migration?+

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.

Considering a COBOL to TypeScript migration?

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.

COBOL audit (4-6 weeks) →Legacy to Cloud expertise →Build-Operate-Transfer model →

Case studies