“How much will it cost to move off COBOL?” is the first question every board asks, and the honest answer is that it depends on more than the size of the codebase. This guide breaks down what actually drives the cost of a COBOL migration in the UK, realistic budget and timeline ranges, and the risks that turn a well-planned project into an overrun.
TL;DR
- A mid-size UK COBOL migration typically costs £200,000 to £800,000 and takes one to two years; full mainframe decommissions run into the millions and multiple years
- Cost is driven far more by codebase complexity, undocumented business logic, and data access redesign than by raw line count
- The choice of target language and migration approach materially changes the budget
- The most common reason projects overrun is underestimating scope, especially undocumented business rules and the data access layer
What Actually Drives COBOL Migration Cost
Line count is the headline number, but it is a weak predictor on its own. The real cost drivers are:
Complexity, not just size. A 100,000-line system of clean batch programs is cheaper to migrate than a 50,000-line system dense with EXEC CICS, dynamic CALLs, and intricate REDEFINES. Transaction processing systems cost more than batch systems of the same size.
Undocumented business logic. COBOL systems often carry 30 to 40 years of business rules embedded in code with no external documentation. Rediscovering and validating those rules is frequently the single largest and least predictable line item.
The data access layer. EXEC SQL against DB2 and VSAM file handling rarely convert automatically. They must be redesigned onto the target platform’s data access technology, and this is often the biggest work item after business-logic discovery.
Data format conversion. Packed decimal (COMP-3), EBCDIC encoding, and fixed-width layouts all need explicit mapping and testing with real data.
Target language and approach. These shift the budget in predictable ways (covered below).
Testing and cut-over. Building a regression test suite that proves output parity, and executing a safe cut-over with rollback, is real, non-trivial effort that inexperienced estimates omit.
Indicative Cost and Timeline Ranges (UK)
These ranges cover analysis, migration, testing, and go-live support. They exclude ongoing operational costs, training, and downstream integration work that often surfaces mid-project.
| System Size | Approach | Estimated Cost | Typical Timeline |
|---|---|---|---|
| Small (< 50,000 lines) | Parallel rewrite | £80,000 to £200,000 | 3 to 9 months |
| Medium (50,000 to 500,000 lines) | Strangler fig | £200,000 to £800,000 | 12 to 24 months |
| Large (500,000+ lines) | Automated + incremental refactor | £500,000 to £2,000,000+ | 2 to 4 years |
| Legacy mainframe decommission | Full programme | £1,000,000 to £10,000,000+ | 3 to 5 years+ |
Treat these as planning ranges, not quotes. A proper estimate requires a code assessment; the spread within each band is driven by the complexity factors above.
How the Target Language Affects Cost
The destination language changes both the effort profile and the long-term cost of ownership. In broad terms:
- Python maps naturally to COBOL’s procedural style and has the largest developer pool, which tends to lower conversion and long-term maintenance cost.
- C# is efficient for organisations already on the .NET and Azure stack, and its native
decimaltype reduces the effort of getting financial precision right. - Java suits JVM-based enterprises;
BigDecimalhandles precision correctly but adds some verbosity. - Go is efficient to build and deploy, but the lack of a native decimal type adds review effort for financial fields.
- Rust tends toward the upper end of any size band because its ownership model adds up-front design effort.
The COBOL migration overview compares all six target languages side by side to help you choose.
How the Migration Approach Affects Cost
- Automated conversion reduces the mechanical translation effort but never produces a finished system; budget for the manual work the tooling flags (embedded SQL, CICS, dynamic calls, decimal precision).
- Parallel rewrite roughly doubles operational cost during the transition because two systems run at once, but it minimises continuity risk. It suits smaller, mission-critical systems.
- Incremental (strangler fig ) spreads cost over time and reduces big-bang risk, at the price of a longer hybrid period. It is the most common approach for large UK enterprise systems.
Most real projects blend automated conversion with an incremental rollout.
The Risks That Cause Overruns
Migrations overrun for predictable reasons. The big five:
- Underestimated business-logic discovery. The rules are in the code, not in a document. Budget explicit discovery time.
- Data access redesign. DB2 and VSAM access does not port automatically. Treat it as its own workstream.
- Inadequate regression testing. Without output-parity testing on real data, you cannot prove the migration is correct. Build the test suite before migration starts.
- Decimal precision errors. Financial fields mapped to floating-point types silently corrupt money. Map to the correct decimal type for the target language.
- Cut-over failure. The switch to production is the highest-risk moment. A detailed cut-over plan with rollback and reconciliation is mandatory.
How to Get an Accurate Estimate
A reliable number comes from a code assessment, not a line count. A good assessment inventories programs and copybooks, identifies EXEC SQL / EXEC CICS / dynamic-call hotspots, gauges business-logic density, and maps the data access surface. The Mecanik COBOL migration service
provides UK enterprise assessments and full-service migration; for mainframe estates on IBM z/OS, the legacy mainframe migration service
covers the infrastructure decommission alongside the code.
Key Takeaways
- A mid-size UK COBOL migration typically costs £200,000 to £800,000 over one to two years; mainframe decommissions run into the millions.
- Complexity, undocumented business logic, and data access redesign drive cost far more than line count.
- Target language and migration approach both move the budget in predictable ways.
- Overruns come from underestimating discovery, testing, and cut-over; a proper code assessment is the only reliable basis for a quote.
Frequently Asked Questions (FAQ)
How much does a COBOL migration cost in the UK? A small system typically costs £80,000 to £200,000, a mid-size system £200,000 to £800,000, and large systems £500,000 upward. Full mainframe decommission programmes run from £1,000,000 into the tens of millions. Complexity, not line count, sets where you land in the range.
How long does a COBOL migration take? Small, well-documented systems take three to nine months. Mid-size enterprise systems run twelve to twenty-four months. Large mainframe programmes take three to five years or more for full decommission.
Why do COBOL migration costs vary so much? Because complexity varies enormously. Undocumented business logic, embedded SQL and CICS, data format conversion, the target language, and the migration approach all move the cost. Two systems of the same line count can differ by an order of magnitude.
Does automated conversion reduce the cost? It reduces mechanical translation effort, but no tool produces a finished system. You still budget for the data access layer, decimal-precision decisions, testing, and cut-over that the tooling flags for manual work.
What is the biggest cause of COBOL migration overruns? Underestimating scope, especially undocumented business logic and the data access redesign. Building a regression test suite for output parity before migration begins is the single most effective way to control that risk.
Comments