COBOL still runs core processing in finance, insurance and government, and it runs it well. The problem is that every year fewer people can safely change it. We read the programs into a model and generate standard modern code from it, with the business rules carried across from the source.
This is for organisations whose COBOL is correct, load-bearing, and increasingly unmaintainable for reasons that have nothing to do with the code quality.
COBOL is supported and will be for years. That is not the same as being safe.
IBM and others continue to support and develop COBOL compilers, so there is no end-of-support cliff. What there is instead is a maintenance population heading for retirement, and almost no new entrants. Risk arrives through the org chart, not the release notes.
In a system amended for thirty or forty years, the documentation describes an application that no longer exists. The only accurate account of what the business does is the COBOL itself, which is exactly what makes a from-scratch rewrite so dangerous.
Everything around the core system now expects an API: digital channels, partners, regulators, analytics. Bolting interfaces onto batch-era programs works, until the number of bolt-ons becomes its own system to maintain.
Platform, licensing and specialist contract rates are a permanent line in the budget, and specialist day rates rise as the talent pool shrinks. The spend is predictable, which is why it so rarely gets challenged.
A hand rewrite works your business rules out again from documentation and memory, which is where undocumented behavior gets lost. We carry them across from the real source instead.
Code Analyzer reads every line of the COBOL source: every program, copybook, data definition and batch dependency, along with the data access and the business rules buried inside them. From that we build a model of how the application actually behaves. Gaps are surfaced, not guessed.
Code Transformer maps the model onto a modern architecture and generates modern server-side code, with a web interface where people use the system, 90%+ automated. Generating from the model gives you an application built the way someone would build it today, instead of old workarounds in a new language. Our engineers handle the custom pieces no automated conversion can reach, with AI assistance, and check the result against your original system.
Side-by-side testing runs the new system and the old one on the same inputs and compares what comes out. The business rules held in the model give a second, separate check that does not rely on the tests alone. Automated test coverage is built alongside the transformation.
The core processing is regenerated as server-side services in standard code. A web interface is built where people interact with the system, but it is the smaller half of the job and it is not what replaces the COBOL.
Job sequencing, scheduling dependencies, restart points and transaction boundaries come out of the model with the program logic. A converted batch system that runs correctly but not in the window is a failed migration.
Record layouts, packed and zoned decimal fields, redefines, and fixed-point arithmetic are carried across explicitly, so numeric results match rather than nearly match.
Converting the application does not force a database or infrastructure move. The data can stay where it is, which is usually what makes a staged migration possible while the business keeps running.
A track record across major enterprises
Yes. COBOL compilers are actively supported and developed, and large COBOL systems will run for years yet. The pressure is the shrinking number of people who can safely change them, not an end-of-support date.
They are handled deliberately rather than assumed away. Record layouts, packed and zoned numeric fields, file handling and job sequencing are read into the model with the program logic, because getting them subtly wrong is how a converted batch system fails in production.
No. The analysis produces a full dependency map, which is what makes staged migration possible: you can see which programs can move independently and which have to travel together. Large systems normally move in phases while the business keeps running.
Analysis typically finds a significant amount of code that nothing calls any more. Identifying it is part of the assessment, and leaving it out of the migration is usually one of the larger savings in the plan.
Business rules move across through a model built from your real source, rather than being re-typed by hand. We then check the result two ways: side-by-side testing on the same inputs, and the business rules held in the model as a separate check.
Usually with the free assessment: a complete dependency map, risk scoring, an effort model and a costed migration plan, produced from your own source code. It tells you the size of the problem before you commit a budget to it.
The assessment is free and built from your own source code. If you would rather see output first, we can run a paid proof of concept on a representative slice of the application.