Why is replacing COBOL systems becoming critical now?
For CIOs this is no longer a theoretical question. COBOL programs often sit inside large systems whose business rules have grown over decades. Regulators and auditors expect traceable data flows. At the same time, platform costs are rising, API connectivity is weak and release cycles are slow. Experienced mainframe specialists are scarce. Every unplanned departure increases knowledge risk. That is why replacing COBOL systems moves from "optional later" to a prioritised roadmap decision—driven by the real combination of skills shortage, contract pressure and integration demand.
Operations and business owners need visibility: which functions run where, which tolerances apply in staging, which rollback levers exist. We align execution accordingly—Made in Germany from Leer, Lower Saxony.
How does migration from COBOL to modern architectures work?
A reliable process starts with thorough discovery. We map programs, copybooks, file and database access, job chains, MQ or file interfaces and partner protocols. From that we build a target picture:
- Which domains move first to a new runtime or target language
- Which interfaces become API-ready first
- Which batch windows allow shadow runs
Migration waves combine automated transformation with targeted manual correction. Tests, reconciliation rules and acceptance criteria per wave make progress measurable. There is no undocumented "year-end switch"—only a catalogue of secured steps you can explain to internal teams and external auditors.
We enforce clean separation throughout. Business rules extracted from COBOL modules land in artefacts your teams can test and deploy with modern tools. Parallel operation and shadow processing stay in place until volume, variance and runtime thresholds are met. Only then do we shift operational responsibility—and early phases remain reversible.
What does COBOL modernization cost in Germany?
Cost depends on scope, coupling, interface complexity, batch complexity and regulatory requirements. A simple "per line of code" figure would mislead. The real effort is driven by logic in copybooks, billing rules in night batches and edge cases. The sensible path is a solid analysis and architecture phase. This tags options—rehosting, staged refactoring, rewriting—with cost ranges and risk markers. Roadmaps and investment spread across budget years follow from there.
Beyond project spend, consider opportunity cost: ongoing mainframe or licence fees, expensive specialist contracts, delayed digitalisation from missing APIs. We make those elements explicit in decision documents and link them to our legacy modernization cost overview.
Automated conversion versus manual re-engineering
The table below summarises a common CIO decision: where automated conversion delivers speed, and where manual re-engineering is unavoidable—without rejecting either route.
| Criterion | Automated code conversion (transpiling) | Manual redevelopment (re-engineering) |
|---|---|---|
| Speed | High throughput for repeating patterns; first runnable target artefacts often appear early. | Slower start because domains and interfaces are remodelled explicitly. |
| Error risk | Risk at edge constructs; regression suites and manual follow-up where generators stop are decisive. | Logic defects possible if edge cases were never extracted from legacy; offset by structured reviews and tests. |
| Preserving business logic | Strong when semantics map cleanly; critical spots receive targeted adjustment. | Strong when requirements are well captured; otherwise risk of "rethinking" away legacy nuance. |
| Maintainability of target code | Depends on generator output; refactoring improves readability and team fit. | Typically high when architecture and coding standards apply from sprint one. |
Big bang versus incremental replacement: risks and the strangler pattern
The big-bang approach promises a single cut-over date. In COBOL landscapes with interconnected batch chains and partner feeds, that rarely works in practice. Edge load, first-night data variance or undocumented booking rules can turn one go-live into a company-wide incident. Once downstream systems have consumed data, rollback becomes theoretical.
The strangler fig pattern routes selected domains through new paths outside the old system while the legacy core handles the rest. Volume shifts are measured and variance stays bounded. You can still report against legacy rules while new channels use APIs from the modern side. You retire the COBOL core gradually—not in one fragile weekend.
For leadership this means fundable multi-year roadmaps and clear domain ownership. Progress does not depend on a single high-risk event. We use automation where it scales and deliberate rebuilding where business logic must be renegotiated—keeping modernisation manageable.
COBOL migration: from as-is to a deliverable plan
COBOL modernisation for mid-sized organisations is fundamentally about controlling risk and cost. As long as core processes run on COBOL and mainframes, operations depend on shrinking expertise, expensive infrastructure and poor integration with modern APIs. We plan COBOL migration so parallel operation, test data and interfaces are reliable—not as a big bang, but in controlled phases. A mainframe exit is worth reviewing when contract terms, licence costs or outage risk start hurting the business. A clear cutover and rollback plan often makes the decision manageable. In practice, legacy system modernisation means clean domain boundaries, step-by-step replacement and measurable data integrity.
Group programmes often use the terms COBOL modernization and mainframe migration side by side. We keep naming consistent in German and English so engineering, audit and suppliers share the same milestones. From Leer, East Frisia, we deliver discovery, architecture options (rehosting, refactoring, rewriting), roadmaps and delivery—Made in Germany.
If you run booking chains, inventory or public-sector case systems, prioritise COBOL modernisation early. Not for hype, but because specialists are scarcer and data flow evidence requirements are stricter. For strategy depth, see our overview of legacy modernization strategies and our service page on strategic legacy modernization for large systems.
Discovery: programs, data, jobs
We inventory programs, copybooks, databases and batch chains; critical paths and partner interfaces are prioritised. Without that foundation, COBOL migration cannot be budgeted reliably.
Interfaces and dependencies
File feeds, MQ, REST or proprietary protocols are catalogued so you see early what parallel operation or contracts affect.
Test and acceptance per migration step
Each stage gets test cases, reconciliation rules and sign-off so production and audit share the same evidence.
Mainframe exit: control cost and risk
Replacing a mainframe is often both CFO and CIO territory: platform spend, capacity limits and vendor dependency meet outage risk on core processes. We quantify savings and transition cost transparently and plan cutover windows with credible fallbacks.
Economics: MIPS, licences, people
We compare total cost of ownership over several years—including maintenance, specialist hiring and opportunity cost from slow change cycles.
Parallel operation and cutover
Shadow runs and parallel processing reduce go-live surprises; escalation paths and business communication are part of the plan.
Compliance and evidence
For regulated sectors we document data flows and migration steps so auditors and internal revision can reuse the trail without extra projects.
Legacy system modernization: architecture instead of crust
Legacy system modernization does not mean "rewrite everything". We bound domains, introduce clear interfaces and replace where business benefit or risk is highest—supported by custom software development for successor components.
Strangler pattern and domain boundaries
New capability is built outside the monolith and replaces legacy logic step by step—ongoing operations stay protected.
APIs and decoupling
Read/write access goes through defined APIs so portals, mobile or partners connect without touching legacy code directly.
Document knowledge
Workshops and reverse engineering complement the code so know-how does not depend on individuals alone.
COBOL modernization and mainframe migration: one project language
In international programmes, COBOL modernization and mainframe migration are often used side by side—we provide a shared glossary and consistent milestones so German-speaking steering and international engineering mean the same thing.
Terms and deliverables
Definition of done, interface specs and test reports are managed bilingually or with unambiguous terminology.
Vendor landscape and runtime options
Transcompilers, emulation or greenfield are judged on benefit, risk and exit options—without ideology.
Reporting for international stakeholders
Status, risks and budget variance are prepared so boards and group PMOs see the same metrics.
COBOL migration and strategy choice: rehosting, refactoring, rewriting
Rehosting
Rehosting moves the COBOL application to new infrastructure—typically from mainframe to Linux/x86—while code stays largely unchanged. The app runs in a COBOL runtime (e.g. Micro Focus, GnuCOBOL) or is translated by a transcompiler into another language (e.g. Java) and executed there. Databases and interfaces are adapted; business logic remains. That removes mainframe rent and dependency with lower risk because deep code changes are avoided.
Pros:
- Fast relief from mainframe cost and contracts
- Lower risk—proven logic stays
- Often shorter timeline (months to about a year)
- Parallel operation and phased migration possible
Cons:
- Technical debt and dated structures remain
- Long-term reliance on COBOL or transcompilers
- Limited improvement in maintainability and integration
Refactoring
Refactoring moves COBOL stepwise into modern languages and structures—business logic stays, implementation improves. Modules are reimplemented in Java, C# or similar and connected via defined interfaces; over time the legacy system is retired (strangler pattern). You gain maintainability, testability and modern APIs without a big bang.
Pros:
- Incremental modernization without full restart
- Better maintainability and tooling
- Operations continue; risk spreads across phases
- Documentation and tests through reimplementation
Cons:
- Longer overall timeline (often one to several years)
- Depends on legacy documentation and test coverage
- Cost per module can rise with tangled code
Rewriting
Rewriting rebuilds the application from requirements—not a 1:1 code lift. Requirements are extracted, prioritised and implemented in a modern architecture (e.g. microservices, cloud). You gain maximum freedom on tech and UX; effort and duration are highest and need strong governance and budget.
Pros:
- Modern architecture and UX without legacy baggage
- No dependency on COBOL or transcompilers
- Chance to drop obsolete features deliberately
Cons:
- Highest effort and longest duration on large systems
- Risk of missing "hidden" logic in legacy
- Parallel operation until full cutover—possible double maintenance
| Strategy | Description |
|---|---|
| Rehosting | Run on new infrastructure (e.g. Linux/Java) with little code change |
| Refactoring | Stepwise move to modern languages/structure; logic preserved |
| Rewriting | New build from requirements; highest effort, highest freedom |
See also VB6 replacement for desktop legacy and legacy modernization for enterprise applications.
Legacy system modernization in practice: process and scenarios
We run legacy system modernisation as a repeatable process with clear stages:
- Discovery and documentation
- Option assessment (rehost / refactor / rewrite)
- Pilot with one module or process
- Phased delivery with parallel operation and acceptance
- Rollout and decommissioning
Milestones and quality gates
Each phase ends with measurable criteria; regression tests and data reconciliations protect production.
Scenario: mid-market insurer (anonymised)
A mid-sized insurer ran policy and claims in COBOL on mainframe for decades. Infrastructure costs were high, COBOL developers were scarce, and portal or partner APIs required painful workarounds. Leadership chose phased modernisation with no outage.
Phase one rehosted to Linux/Java. The COBOL was converted to Java and deployed in containers. Mainframe costs dropped within twelve months. The business saw little change because interfaces and flows stayed the same.
Phase two refactored high-traffic modules. Core logic was rebuilt in Java with automated tests and REST APIs for portals and partners. After roughly two years, most processes ran on the new platform. Legacy COBOL served only edge cases and was then switched off.
Outcome: lower running and maintenance costs, faster delivery of products and interfaces, and a foundation for further digitalisation—with milestones, parallel operation and a clear rollback plan so risk stayed manageable.
Other patterns
Banking: core banking on COBOL/mainframe—rehosting to Linux/Java runtime while interfaces and UIs were extended stepwise.
Public sector: COBOL case systems—multi-stage refactoring: database and interfaces first, then Java modules for new requirements while legacy was retired gradually.
