COBOL is not a museum piece. It still runs a large share of the core systems in banking, insurance, and government, and much of it works fine. The problem is not the code sitting still. It is that the people who understand it are retiring faster than anyone is replacing them, and the surrounding platform (the mainframe, the batch jobs, the job control) is expensive to run and hard to hire for. “It still works” holds right up until the person who knew why it works is gone.
If you own a COBOL system, here are the options that actually exist and where each one fits.
Why COBOL is hard to move, specifically
COBOL migrations have a reputation for being harder than other legacy work, and the reason is not the language, which is readable and orderly. It is everything around it:
- The environment, not just the code. A COBOL system usually comes with JCL, batch schedules, VSAM or hierarchical data, and mainframe-specific behavior. Moving the COBOL without accounting for all of that is only part of the job.
- Batch and data formats. Decades of records in fixed-width files, packed-decimal fields, and EBCDIC encoding carry assumptions that a careless migration will break. The data layer needs as much attention as the programs.
- Undocumented rules at scale. These systems are old and large, and the business rules have been amended for thirty or forty years without anyone writing them down. That knowledge is the real asset, and it is the thing most at risk.
The options
| Option | What it is | Timeline | Risk | Where it fits |
|---|---|---|---|---|
| Stay on the mainframe | Keep running COBOL as-is | n/a | Rising cost and skills risk | Only as a planned bridge |
| Rehost or emulate | Move COBOL to a cloud host or emulator, code mostly unchanged | Short to medium | Low to medium | You need off the mainframe fast, not off COBOL |
| Rewrite | Rebuild the system from requirements in a modern language | Long | High | Small scope, or the process is being redesigned |
| Automated conversion | Parse the COBOL source and generate a modern equivalent | Medium | Low to medium | A large system you must keep, moved to standard code |
Stay on the mainframe
Defensible only as a deliberate bridge while you plan. The running cost and the skills gap both get worse over time, so treat the time you buy as time to prepare the move.
Rehost or emulate
Rehosting lifts the COBOL onto cheaper infrastructure, a cloud mainframe or an emulator, with little change to the code. It can cut the platform bill and buy time, and it solves the “get off the physical mainframe” problem. What it does not solve: the code is still COBOL, so the hiring and maintainability problems remain. Useful as a first step, not as the destination.
Rewrite
A rewrite gives you a modern system built to current requirements, and for COBOL it is the highest-risk option on the table. The undocumented business rules have to be re-derived from the source and from people’s memories, at a scale where that reliably runs long. It fits when the scope is genuinely small, or when the business is deliberately redesigning the process and does not need the old logic preserved exactly.
Automated conversion
Automated conversion reads the actual COBOL programs and data definitions and generates a modern equivalent in standard code, in our case TypeScript and React with a documented API. The point is the same as with any language we handle: the business rules are carried across from the real source rather than reconstructed from memory. COBOL adds a specific requirement, which is that the data formats and batch behavior have to be handled on purpose, not assumed away. For a large COBOL system you need to keep running, conversion is usually the lowest-risk route to code you can actually staff.
To be straight about it: COBOL modernization is more than a language translation, because the mainframe environment and the data come with it. Any plan, ours included, that treats it as a pure code exercise will underestimate the work. The honest version is that the programs convert well, and the surrounding platform and data need real attention.
How to decide
Three questions cover most COBOL decisions:
- Do you need off the mainframe, off COBOL, or both? Rehosting handles the first. Conversion or rewrite handles the rest.
- How much of the business logic is undocumented? The more there is, the more a rewrite risks losing it, and the more carrying it across automatically is worth.
- What has to keep running during the move? Core financial and government systems rarely get a quiet weekend to switch over, which pushes against big-bang rewrites.
If you want a grounded read on your own system rather than a general answer, the usual first step is a fixed-scope proof-of-concept on a real slice of the code and data. It shows what converts cleanly and where the mainframe-specific work sits. Get in touch and we can scope one.