Four steps, in this order, and what comes after. Each one ends in something you can put in front of a committee.
1 · Pre-assessment
The real translator reads your source as it arrives — a ZIP or a folder — and reports program by program: what is there, what is missing, what depends on what, and how much of it translates clean. Because that reading comes from the engine that will do the work, the estimate and the migration cannot disagree. You walk into the business case with a number anyone can reproduce on a Tuesday. And you run it yourself: one download, no build tool, no network access, no AI in the loop — your source never leaves the building, and there is nothing to configure to keep it that way.
2 · Migration
COBOL, CICS, JCL and embedded SQL become imperative Java 21 — readable code carrying your own names, not a black box with an API. Anything the translator cannot do is flagged and reported instead of guessed at, so a wrong translation never ships quietly. Your team reviews the result in a web workspace with roles for development, systems, operations and security, and a Git repository per user. What comes out is code a Java developer can read in a review, which is the entire point of leaving COBOL behind.
3 · Deployment
The system goes to your Kubernetes with its online regions, job queue, spool and operator console, and the VSAM data loaded byte for byte into PostgreSQL. The migrated programs still speak CICS and JCL, so screens and the nightly batch behave the way the business already knows them — the people who run it on Friday run it the same way on Monday. It is your cluster, in your cloud or your datacenter, with no meter on the workload.
4 · Certification
When a program passes your tests, you certify it: the tool stops regenerating it and hands it over for good. That single act draws the line between a migration and a dependency — from there the program lives in your Maven build and is maintained like any other Java. The project has an end date, and after it you owe nobody a licence to change your own code.
And then: what you build next
The next application does not have to be COBOL, or even go through the runtime. The data is published as a SQL contract for reading and a Spring Data repository for reading and writing by key, so a new service reaches the master file with ordinary tools. The migration stops being a project that finishes and becomes the platform the next decade of work sits on.
Straight talk: a migrated program comes out as faithful Java, not as a hand-crafted microservice. That rewrite is a later decision — and it is yours to make, because by then the code belongs to you.
