COBOL still in production? Let's modernize it methodically.
There are still today COBOL systems in production in Italy running critical business pieces: peripheral banking, historical ERPs, public-sector systems. When COBOL programmers retire and the documentation is stuck in the '90s, modernization becomes urgent.
What happens today.
COBOL is one of the longest-lived languages in the history of computing: still today COBOL systems run in Italy on IBM mainframes, AS/400, or smaller environments. They work, they are stable, but the pipeline of COBOL programmers has nearly dried up: experts retire, universities no longer teach COBOL, knowledge risk is at its peak.
Modernizing a COBOL system needs a specific approach: business-logic reverse engineering often undocumented, knowledge recovery from the few remaining experts, progressive migration with rollback criteria. No big-bang, because the risk is too high on systems that have run in production for 20-40 years.
COBOL is not dead. It is just that nobody speaks it anymore. Time to translate it into something the next team can read.
The solution, broken into parts.
-
Knowledge recovery from the senior team
Structured sessions with senior programmers (even part-time or as post-retirement consultants) to extract business logic from the code and from their heads. We document everything so the knowledge is not lost.
-
Code reverse engineering
Static analysis of COBOL code: identification of programs, functions, dependencies, business rules crystallized in complex if/else chains. Output: complete documentation of the current system behavior.
-
Progressive migration
Strangler pattern, as for AS/400: the COBOL system stays operational; modules are rewritten one at a time in a modern language (TypeScript/Java/Go), with parallel run and automatic reconciliation.
The typical profiles who benefit.
-
Finance with peripheral COBOL systems
Financial institutions, insurance, mutual funds with COBOL systems accessory to the core (reporting, overnight batches, historical systems). The regulated core stays intact; accessories are modernized.
-
SMEs with historical COBOL ERPs
Italian companies (manufacturing, distribution, services) with COBOL ERPs on mid-range mainframes or AS/400. Programmers retire, evolution is stuck, integration with modern systems impossible.
Transparency on what the client does.
Before we start we need a few accesses and decisions. All reasonable, no surprise asks.
-
System access
- Read access to the COBOL code and the source databases/files
- Senior internal (or former) programmers available even a few hours a week
- Existing documentation (even fragmentary)
-
Operational decisions
- Priority: which COBOL modules to modernize first
- Target architecture (cloud, modern on-prem, hybrid)
- Compliance constraints (regulated sector, audit, GDPR)
Indicative numbers, not quotes.
- TIME
- Audit + knowledge recovery 6-12 weeks. Full migration 9-24 months depending on scope.
- COST
- Audit €20,000-60,000. Full migration €150,000-700,000 depending on scope and how much knowledge is recoverable.
- MODEL
- Audit on fixed milestone, migration in phases with stop possible after every module.
Indicative numbers. For an accurate quote, let's talk.
Answers to the most common questions.
Is it better to keep COBOL or migrate?
It depends on operational risk. If the system works and internal programmers have 10+ years of career ahead, keeping it can be the cheapest choice. If programmers are close to retirement, evolution is stuck, missing integrations weigh on you: migrating is less risky than staying. Initial audit to understand where you stand.
Can COBOL code be converted automatically?
COBOL→Java or COBOL→C# transpilation tools exist that can give a baseline, but the result is rarely production-ready: generated code is unreadable, keeps the antipatterns of the original COBOL, and loses the documentation opportunity. We prefer to rewrite by hand with documented logic, in modern languages, readable by future teams.
What if we lose access to the senior programmer during the migration?
That is why we do knowledge recovery as the first phase: everything the senior knows is documented before migration starts. If the senior leaves mid-migration, the collected documentation allows us to continue. The initial audit also identifies the 'dark zones' of the code where knowledge is critical and must be extracted first.
Recognize your case?
Write a couple of lines about your context. We'll reply within 24-48 hours with an initial assessment and a first orientation on time and cost.
Let's talk