Core banking, insurance, payments and public-sector processing still run on COBOL, often on hardware and licences that cost more every year, read by fewer people every year. The code is usually correct. It encodes decades of decisions about rounding, dates, limits, cut-offs and exceptions that no other document records. A conversion that does not first recover those rules replaces a system that works with one that nearly does.
SOLUTIONS / LEGACY MODERNISATION
Preserve the logic. Transform the system.
From COBOL cores to the ageing Java estates others built to replace them: modernise to native software, without treating the business knowledge inside as disposable.
Discuss the workIllustrative engineering modelLocal / no external action
The same representative input
REPORT-014
Trim spaces.
Use upper-case letters.
REPORT-014
The same defined result,
through a separate path.
Behaviour preserved for this example. This small local comparison does not establish compatibility with a real legacy system.
COBOL is not the problem. Not understanding it is.
The Java estate is the next legacy.
Many of the systems others built in the 2000s to replace COBOL now sit on Java EE application servers, old JVM versions and frameworks that are heavy to run, slow to start, expensive to license and close to the end of vendor support. They carry the same risk the mainframe did: critical behaviour that nobody can fully explain, on a platform that is harder to staff each year. Replacing COBOL with a managed runtime traded native speed for a dependency on someone else’s roadmap. We treat these estates with the same discipline as the mainframe: understand first, then move one boundary at a time, to native software.
Illustrative loan-interest calculation · not a customer system
015 2100-CALC-INTEREST.016 IF WS-DAYS > 360017 MOVE 360 TO WS-DAYS018 END-IF019 COMPUTE WS-INTEREST ROUNDED =020 LN-BALANCE * WS-INT-RATE021 * WS-DAYS / 360022 IF LN-STATUS = 'F' OR 'W'023 GO TO 3900-SKIP024 END-IF025 WRITE LEDGER-REC.
002//STEP020 EXEC PGM=LNINT01003//LNACCT DD DSN=PROD.LN.ACCT.MASTER004//LEDGER DD DSN=PROD.GL.POST.DAILY
COBOL · CICS · packed decimal Live · the only path
Callers channels · nightly batch · reporting
Stable interface
interest(loan, days) → amount One contract for every caller. What answers behind it can change.Loan 4471 12.37 12.37 ✓
Loan 4472 8.04 8.04 ✓
Loan 4480 103.50 103.51 ✗rounding · for review
Loan 4493 0.00 0.00 ✓frozen · both skip
01interest(loan, days):02 days = min(days, 360)03 if loan.status in {F, W}:04 skip, log05 return halfUp(balance × rate06 × days / 360)
- ✓360-day year, capped at 360 days
- ✓Half-up rounding to cents
- ✓Frozen and written-off loans skipped
- ✓Ledger posting unchanged
Same rules · same rounding · same exceptions Not yet built
Native is the point.
COBOL endured for fifty years because it is compiled, native code that runs close to the machine, with no application server, no virtual machine and no runtime to upgrade. That is the quality worth keeping. Genyra builds native software: compiled services and applications that start in milliseconds, run on modest hardware, and depend on the operating system rather than a vendor’s runtime roadmap. A modernisation that lands on a heavier platform than the one it replaced has not modernised anything.
Keep what still earns its place.
Separate the behaviour the business needs from the platform limitations and workarounds around it. A new interface, a replaced component or an integration layer may solve the problem without rewriting the entire application. Sometimes the right modern target is a smaller native service beside the old core, not a like-for-like rewrite.
Read the application and its data.
Examine source, copybooks, JCL and batch schedules, interfaces, storage and operational dependencies. COBOL needs careful attention to file formats, packed decimals, calculations, dates and transaction behaviour. Java estates need the same attention to frameworks, container configuration, shared libraries and the hidden coupling between deployments. Neither can be migrated credibly from the outside.
Move one boundary at a time.
Define a component that can change independently and a stable interface to the rest of the system. Introduce the replacement behind that boundary, with a way to compare its behaviour and return to the previous path if necessary. The old core keeps running until the new path has earned its place.
A migration must preserve meaning.
Map fields, identifiers, relationships and historical records. Check conversions, missing values, rounding and reconciliation totals. Rehearse the migration with representative data rather than discovering an incompatible format during cutover.
Compare old and new.
Compatibility tests and parallel runs can expose differences before the replacement carries the full workload. Agree the comparison cases, acceptable differences and the cutover decision. Prepare rollback and record the result of each rehearsal.
Show us the constraint.
Tell us what the application does, what makes it difficult to maintain and what needs to change. Existing source, operating notes and a working example help shape an assessment and a staged modernisation plan.
Engineering, demonstrated
Your business logic is valuable. Your legacy technology does not have to be permanent.
Legacy modernisation
Legacy Ledger & Payroll
Reconstructing business-critical logic without losing the behaviour that matters.
2,174Exact file comparisons · Exact byte-for-byte comparison Business application reconstructionHotel Operations
Modernising an interconnected business application while preserving operational behaviour.
155Operational scenarios · Exact byte-for-byte comparisonA DECISION, BEFORE A DIRECTION The right next step
The right next step
isn’t always a rebuild.
Explore three possible directions. An assessment establishes which is appropriate for the system, the organisation and the constraints.
Keep what already creates value.
A stable system may need better documentation, clearer interfaces or a focused operational improvement. Understanding it can be the most valuable change.
Questions we are asked.
Short answers in the same terms as the page. Anything specific to your systems is agreed by enquiry.
- Is this legacy system migration or legacy modernization?
- Both words are used for the same work: moving a business-critical system off a platform, language or runtime that has become a liability while keeping the behaviour that the business depends on. Genyra treats it as reconstruction with proof: the existing system is read and documented, the logic is rebuilt, and the two are compared on the same inputs. The Engineering Lab shows that method on three published COBOL systems, verified byte for byte.
- Do you convert COBOL to Java?
- No. The Java estates built in the 2000s to replace COBOL are now the next legacy. We preserve the business rules and rebuild as native, compiled software, with no application server or virtual machine to keep upgrading.
- Is a complete rewrite necessary?
- Rarely as a first step. We move one boundary at a time: a component with a stable interface, introduced behind that boundary with a way to compare its behaviour and return to the previous path if needed.
- What happens to the data?
- A migration must preserve meaning. Fields, identifiers, relationships and historical records are mapped, conversions and rounding are checked, and the migration is rehearsed with representative data before cutover.
- How is the replacement proved before cutover?
- Compatibility tests and parallel runs against agreed comparison cases, with acceptable differences and a rollback prepared. The cutover decision and its result are recorded.
- What is COBOL, and why is it still used?
- COBOL is a compiled business language from 1959 that still runs core banking, insurance, payments and public-sector processing. It persists because the code is correct, exact with decimals, and native: no application server or virtual machine to keep upgrading.
- What is legacy modernization?
- Changing a system the organisation depends on so it can be maintained, integrated and run economically, without losing the rules inside it. For us that means recovering the rules first and rebuilding as native software, one boundary at a time.
A CLEARER NEXT STEP
Discuss a modernisation path
From an unanswered question
to an engineered possibility.