COBOL to Java now has a price tag: £200k to £800k, and the risk is your decimals

A UK enterprise guide published on dev.to has put numbers on something that usually arrives as a vague board request: a mid-size COBOL to Java migration typically costs £200,000 to £800,000 and takes one to two years, with the data access layer and undocumented business logic named as the biggest risks ^[1][2]. That moves the conversation from platform strategy to budgeting, which is where these programmes are actually won or lost.

Treat the range as an anchor rather than a quote. It is four times as wide at the top as at the bottom ^[3], and the schedule range doubles independently, so the implied monthly burn runs from about £8,300 to about £67,000, a spread of roughly eight times ^[4]. A number that loose is not a costing; it is a statement that scope discovery has not happened yet. Anyone approving spend against it should expect the discovery work to be the first line item.

The technical failure mode the guide treats as most important is arithmetic typing. COBOL `PIC 9` clauses and `COMP-3` packed-decimal fields hold exact base-10 values, which is what financial systems require ^[5]. Java's `double` and `float` use binary IEEE 754 floating point and will introduce rounding errors in monetary calculations ^[6]. The correct mapping is `BigDecimal`, with scale and precision carried over from the original `PIC` clause ^[7], and according to the guide any migration that converts `COMP-3` to `double` to keep the code simple is introducing production defects ^[8]. `BigDecimal` is more verbose because it is an object with an explicit API rather than a primitive ^[9], which is the stated reason some organisations already on .NET prefer C# and its native `decimal` type ^[10]. That is a real trade: verbosity you can review versus rounding you cannot see until a reconciliation fails.

The second failure mode is the one you cannot buy your way out of. Strong static typing catches whole categories of error at compile time, which matters when translating decades of business logic that no one fully documents ^[11]. Note the framing: the type system is a partial mitigation for missing documentation, not a substitute for it.

On approach, the guide describes three options with different risk and cost profiles, automated conversion, parallel rewrite, and incremental strangler fig, and says most UK enterprises use a hybrid ^[12]. Automated conversion done well yields idiomatic Java 17 with typed fields and structured exception handling; done naively it produces an unreadable transliteration that is harder to maintain than the COBOL it replaced ^[13]. No tool produces a finished system ^[14]. `EXEC SQL` against DB2, `EXEC CICS`, and VSAM have no drop-in Java equivalent and need deliberate redesign onto JDBC, JPA/Hibernate, or Spring Data ^[15]. Copybooks, including nested ones, must be resolved ^[16], and EBCDIC fixed-width layouts need explicit conversion to Unicode and typed models ^[17].

What to watch in any proposal built on these figures: whether the quote separates discovery from conversion, whether the acceptance criteria include decimal-exact reconciliation against the mainframe rather than test pass rates, and how the CICS and VSAM redesign is priced ^[15][2]. Those three lines explain the gap between £200,000 and £800,000 ^[1].