Build1 distinct publisher3 min readPublished
A UK enterprise guide prices a mid-size COBOL rewrite at GBP 200,000 to GBP 800,000 over one to two years, and the packed-decimal review does most of the work of choosing a target language, well ahead of the concurrency win.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
Follow any of these and your For You feed starts watching them — no settings page required.
build
COBOL to Java now has a price tag: £200k to £800k, and the risk is your decimals1 distinct publisher
build
OpenTelemetry's maintainers say the helper class you are about to write is the bug1 distinct publisher
build
SSE in Go breaks twice before your handler runs: an illegal header, then a 30-second timeout1 distinct publisher
build
A green @DataJpaTest can prove only that Hibernate handed back the same object1 distinct publisher
The packed-decimal mapping is dangerous because it is legal. COBOL `PIC 9` and `COMP-3` fields hold exact base-10 values, which is the property financial code is built on [2]. float64 is IEEE 754 binary, and the guide is explicit that the default mapping can introduce rounding errors in monetary calculations [1]. Nothing in the conversion fails, and arithmetic on the result is well defined; the defect surfaces downstream in a reconciliation that is out by pennies, by which point the translation is months old.
That's why I'd actually defend the report as the better piece of engineering here, ahead of the parser itself. The Mecanik converter maps decimal fields to float64 by default and then flags every one of them, so the call is made per field by someone who knows whether that field is money, and the guide's instruction is to never ship money code on float64 without that review [3]. Defaulting to something that compiles and flagging it beats defaulting to something safe and quiet, because a flag produces a list you can count and sign. Worth noting who is writing: the guide runs on dev.to and recommends the converter built by the same outfit [4].
Inside Go, the route for financial logic is a decimal package such as `shopspring/decimal` [5]. That means a third-party numeric type threaded through every money path, reviewed and re-reviewed, which is why a Go migration guide is willing to name other targets for decimal-heavy portfolios [6]. If your estate is mostly money arithmetic, that is the trade you are accepting. If it is mostly sequential batch, the case reads differently: goroutines and channels let a serial nightly job be restructured to process partitions concurrently [7], and the single self-contained binary takes the runtime install out of deployment onto Linux or containers [8].
Then the money. Four times separates the top of the quoted band from the bottom [9]. Spread across the stated window, that is GBP 100,000 a year at one end and GBP 800,000 at the other, an eight-fold spread [10]. A range that wide is a scoping statement rather than a quote. For it to transfer, several things have to hold on your side: your embedded surface looks like theirs, with `EXEC SQL` against DB2, `EXEC CICS` and VSAM all needing redesign onto `database/sql`, `sqlx` or GORM [11]; your files carry the same EBCDIC and fixed-width to Unicode conversion load [11]; your nested copybooks resolve [11]; and you pick the same one of the three approaches, since automated conversion, parallel rewrite and strangler-fig replacement are described as carrying different risk and cost profiles [12]. The mechanical translation is the cheap half. Group items become structs with exported PascalCase fields and `EVALUATE`/`WHEN` becomes a `switch` [13], and a tool does that in an afternoon. What the band is really pricing is the human review that the flags generate, plus the data access layer, which the guide names alongside the decimal decision as the critical planning item [14].
Ranked by verification strength, evidence, and original report placement.
Go has no native decimal type; the default mapping for a COBOL decimal field is float64, which uses IEEE 754 binary floating point and can introduce rounding errors in monetary calculations.
COBOL PIC 9 and COMP-3 fields hold exact base-10 decimal values, which is what financial systems depend on.
The guide is published on dev.to and recommends the Mecanik COBOL to Go migration tool by name.
For any financial or decimal-sensitive logic the guide says the correct approach is a decimal package such as shopspring/decimal in place of float64.
The guide says that if exact decimal precision without any extra library is a priority, C# (native decimal) or Java (BigDecimal) may be a better fit than Go.
Goroutines and channels make it straightforward to parallelise the sequential record-by-record batch processing typical of COBOL, and a nightly batch job that ran serially on the mainframe can often be restructured to process partitions concurrently.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 30, 2026
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One vendor guide, no second voice
Split the guide in two and it grades very differently. The language facts — Go has no decimal type, IEEE 754 rounds, PIC 9 and COMP-3 hold exact base-10 — are verifiable outside this document and uncontested. The two claims a buyer would act on are not: the GBP 200,000 to GBP 800,000 band and the Migration Report that supposedly flags every decimal field both come from the firm selling conversion, and nothing else in this reporting touches them.
No migration on the record
Not one project is named. No client, no line count, no before-and-after batch window, no figure for how many teams have run the converter — the guide explains what a migration involves without pointing at one that happened. Uptake cannot be measured from this.
The numbers outrun the record
The technical half is more honest than a sales document has to be: it tells you to clear float64 mappings by hand and concedes that C# and Java handle decimals better out of the box. The stretch is arithmetic. A band whose top is four times its bottom, spread over a window that itself doubles, works out to anything from GBP 100,000 to GBP 800,000 a year and is offered as guidance with no engagement behind it.
The guide sells what it recommends
The byline is mecanik-dev. The one converter named as making the precision decision visible is Mecanik's; the closing paragraphs route the reader to Mecanik's assessment, conversion, data-access and parity-testing services and its z/OS practice. Even the cost band does double duty as a price anchor for whoever picks up the phone.
Firm on a narrow document
What this is, we can say without hesitation: technically literate, commercially motivated, and accurate wherever its claims can be checked against the languages themselves. What one document cannot settle is whether the pricing survives contact with a real codebase, whether the report behaves as described, or whether strangler-fig-plus-automation is the right default outside the author's own engagements.