COBOL to Java migration cost: what actually drives the number

← All posts

Ask 5 vendors what a COBOL to Java migration costs and you’ll get 5 answers that don’t overlap.

One will quote you a per-line rate. One will quote a fixed blueprint price. One will refuse to quote anything until after a discovery phase. The spread between the cheapest and the most expensive answer is often 10x on the same codebase.

That isn’t vendors being evasive. It’s a symptom of the fact that lines of code is a poor predictor of migration effort, and everyone in the industry knows it while continuing to price against it anyway.

This piece breaks down what actually moves the number, why the published ranges are so wide, and how to build an estimate that survives contact with your own code.

The published ranges, and why they disagree

Start with what’s publicly quoted, because it’s useful context even though none of it will match your project.

Industry comparison sites put automated COBOL conversion somewhere between $1 and $25 per line of code, with the low end reserved for clean replatforming and the high end covering full-service transformation including assessment, testing, cutover and post-migration stabilisation. Conversion-only services get quoted more narrowly, usually in the $1.50 to $4.00 per line band.

Programme-level figures land differently. Automated refactoring engagements are commonly cited around $2.2 million over 12 to 24 months. Full rearchitecture runs higher, often quoted between $4 million and $15 million depending on how much of the estate is in scope.

The outlier that gets quoted most often is the Commonwealth Bank of Australia, which spent roughly $750 million over 5 years moving its COBOL estate. That number appears in academic literature on code translation as the canonical example of what a manual, human-led migration costs at national-bank scale.

Here’s the problem with all of it. A $1 per line quote and a $25 per line quote are frequently describing different projects wearing the same name.

One is moving code to a modern runtime and leaving it in COBOL. The other is producing maintainable Java, converting the data layer, building a regression suite that never existed, and running both systems in parallel until the business signs off. Those aren’t comparable units of work.

So the first question to ask any vendor isn’t “what’s your rate”. It’s “what’s inside that rate, and what’s outside it”.

Why lines of code is the wrong unit

Lines of code is easy to count, which is the only thing it has going for it.

Two 500,000-line COBOL estates can differ in conversion effort by a factor of 4. Here’s what creates that gap.

Dialect spread

COBOL isn’t one language. IBM Enterprise COBOL, Micro Focus COBOL, ACUCOBOL, RM/COBOL, Unisys and Fujitsu dialects all have distinct syntax and runtime behaviour, and most large estates contain more than one.

Every additional dialect means a separate front end, separate semantic rules and separate edge-case handling. An estate with 3 dialects isn’t 3 times harder than a single-dialect estate, but it’s meaningfully harder, and the cost shows up in the parts of the work that can’t be automated cheaply.

Copybook sprawl

Copybooks are the data contract for the whole estate. When 400 programs share 30 copybooks, the conversion is tractable. When 400 programs each carry their own near-duplicate copybook with slight variations, you’re doing 400 data model reconciliations rather than 30.

REDEFINES clauses make this worse. A single storage area interpreted 6 different ways depending on a flag has no clean equivalent in a Java type system, and every one of those needs a decision.

Embedded languages

Most production COBOL isn’t only COBOL. It contains embedded SQL, CICS commands, IMS DL/I calls, and sometimes inline assembler.

Each of those is a separate language with its own semantics, and each has to be translated in step with the COBOL around it. A tool that handles the COBOL and leaves the embedded SQL as a manual exercise has handled the easy part.

The data layer

This is where migrations go over budget more often than anywhere else.

VSAM files carry implicit schemas that exist only in the COBOL that reads them. There’s no data dictionary to consult. Moving VSAM to a relational database means reconstructing the schema from the code, then handling the fact that mainframe file access patterns and SQL access patterns have almost nothing in common.

The PostgreSQL numeric type documentation is a useful reference here, because it makes clear how much thought exact-precision decimal storage requires. COBOL’s packed decimal fields need that precision preserved, and a naive mapping to a floating point column will silently corrupt financial data.

Dynamic CALL

Static call graphs can be resolved by analysis. Dynamic CALL with a program name held in a data field can’t, at least not fully, because the target is only known at runtime.

Estates that use dynamic dispatch heavily require runtime observation on top of static analysis, and that’s a separate workstream with its own cost.

Dead code

Most estates carry 20% to 40% code that hasn’t executed in years. Converting it is wasted money, and identifying it reliably takes analysis effort.

The cheapest line of code to migrate is the one you delete first. Very few estimates account for this properly, and it’s one of the few drivers that pushes cost down rather than up.

Where the money actually goes

Here’s the distribution that surprises people. Conversion is rarely the biggest line item.

Industry analysts have put testing at over 70% of migration time on some programmes. Even at the more conservative 30% to 40% of cost, it’s the largest single line.

That has a direct implication for how you evaluate quotes. A vendor quoting a low per-line conversion rate while leaving testing to you hasn’t given you a cheaper project. They’ve given you a smaller invoice and a bigger internal cost.

The residual problem, or what 95% automation leaves behind

Every vendor in this market quotes an automation percentage. Published figures cluster around 70% to 85% for automated COBOL to Java conversion, up from roughly 40% in 2020.

The number is close to meaningless without a definition, because vendors compute it differently:

• Lines converted without manual edit. The most generous denominator. Boilerplate inflates it.
• Programs converted without manual edit. Stricter, and a better predictor of effort.
• Programs requiring zero human review before test. Strictest, and almost nobody quotes on it.

The same project can honestly report 95% or 60% depending on which of those you use.

More importantly, the residual isn’t randomly distributed. The 5% that resists automation is concentrated in exactly the places where the business logic is densest and least documented: the arithmetic, the edge-case handling, the code nobody has touched since the person who wrote it left.

So the last 5% routinely consumes 30% or more of the conversion effort. When you’re modelling cost, treat the automation percentage as a description of where the difficulty is concentrated rather than a discount on the total.

Ask one normalising question of every vendor: “Of the programs you convert, what percentage go to test with no human editing the output?” That cuts through most of the definitional variance.

The Gen AI discount, and how much of it is real

Since the hyperscaler launches, a lot of quotes have come down. Some published figures now cite average programme costs dropping from around $9.1 million to $7.2 million, attributed to increased automation.

Some of that is real. Gen AI is genuinely good at several things that used to consume expensive human hours: generating documentation for undocumented programs, drafting test cases, explaining what a routine does, and reviewing converted output for obvious problems. Used as an augmentation layer around a deterministic conversion, it takes real cost out of discovery and testing.

What it hasn’t done is make the conversion itself cheap and reliable at enterprise scale.

Published benchmarks show accuracy on code migration tasks falling sharply as codebase size grows, with pass rates above 90% on small samples and dropping below 20% on repositories over 50,000 lines. AWS-affiliated researchers published a study in 2026 (arXiv:2605.21537) that ran nearly 2,000 modernization tasks across 11 production models and found semantic drift in 39.7% of attempts on code containing semantic traps, with models catching only 68.3% of their own errors on self-review.

The cost implication is direct. If the generated output needs human verification at a rate you can’t predict, the review cost is unbounded, and it lands on your team rather than the vendor’s.

We’ve written more on where that boundary sits in why Gen AI alone is not enough for modernization.

The other side of the ledger: what not migrating costs

A migration business case that only counts project cost is only half a business case. The run rate on the current estate is the other half, and it isn’t flat.

Mainframe operating costs. MIPS charges, compiler licences and hardware refresh cycles. Published estimates put annual increases at 10% to 15% for organisations running significant workloads.

Talent. COBOL developer salaries in the US sit around $115,000 to $125,000, with contract rates between $100 and $180 per hour. Roles take 2 to 3 times longer to fill than equivalent modern-stack positions, and roughly 85,000 mainframe developers retire globally each year against a training pipeline that doesn’t replace them. We’ve covered this in depth in the talent shortage for legacy code.

Change velocity. The cost nobody puts in the spreadsheet. When every change request takes 6 months because testing is manual and nobody’s confident about hidden dependencies, the business is paying in opportunity cost every quarter.

Regulatory exposure. Unsupported and unpatchable systems are becoming a compliance problem with dates attached. The NIS2 directive and DORA both place obligations on organisations running critical systems, and both put duties on the management body personally. Our piece on security debt as a modernization deadline goes further into this.

Most organisations that run the full comparison find the break-even lands somewhere between 18 and 36 months post-cutover. Where total mainframe cost of ownership exceeds roughly $500,000 a year, that window tightens considerably.

How to build an estimate you can defend

You need a number before you can get funding. Your vendor needs discovery before they can give you an honest one. That tension is real, and the way through it is staging.

Stage 1: Inventory, 1 to 2 weeks

Count what you have. Programs, lines, copybooks, JCL members, dialects present, database and file types, embedded language usage.

This is cheap, it’s mostly automated, and it gets you an order-of-magnitude range. Expect error bars of plus or minus 50% at this stage, and say so out loud when you present it.

Stage 2: Complexity assessment, 3 to 6 weeks

This is where the estimate becomes defensible. Dependency graph construction, dead code identification, dialect confirmation, copybook reconciliation analysis, dynamic call resolution, data schema reconstruction.

Error bars come down to plus or minus 20%. Complexity assessment is the first deliverable of any credible modernization programme, and any vendor willing to give you a firm price without it is either padding heavily or planning to raise change requests later.

Stage 3: Pilot, 8 to 12 weeks

Convert a representative subset. The word doing the work there is representative.

A pilot on a clean, well-structured, single-dialect module tells you almost nothing, because that’s the code that was always going to convert cleanly. Pick modules that contain the things you’re worried about: the dynamic calls, the gnarly copybooks, the arithmetic-heavy financial routines.

A pilot designed to succeed is a marketing exercise. A pilot designed to find the boundary is an estimating instrument.

Stage 4: Programme

By now you should have a per-module cost derived from your own code rather than from a rate card. That’s the only estimate worth taking to a board.

What to ask before you sign

A short list that separates a real quote from a hopeful one.

1. What’s your denominator for the automation percentage you quoted?
2. Which COBOL dialects does your front end handle natively, and which need custom work?
3. Is embedded SQL, CICS and IMS conversion inside the quoted price?
4. Is data migration inside the quoted price? Is schema reconstruction?
5. Who builds the regression test suite, and is it in scope?
6. What happens to the estimate if we find a dialect you didn’t expect?
7. How is the converted code verified, and what evidence do we receive?
8. Do we own the output outright, and does it depend on your runtime?

That last one matters more than it looks. Some conversion approaches produce code that only executes against a proprietary runtime, which converts a one-off project cost into a permanent licence cost.

The 3 pricing models, and what each one shifts onto you

Quotes arrive in 3 shapes. Each moves risk to a different party, and that’s really what you’re choosing between.

Per line of code

The most common, and the easiest to compare on the surface. You pay a rate multiplied by a count.

What it shifts onto you: everything the rate doesn’t cover. Per-line pricing almost always covers conversion only. Discovery, data migration, testing and cutover sit outside it, and those are 60% or more of the real programme.

It also creates an incentive misalignment worth naming. A per-line vendor has no reason to help you delete dead code, and dead code is commonly 20% to 40% of an estate. Every line removed before conversion is a line you don’t pay to convert, test or maintain.

Ask for the rate to be quoted after dead code elimination, and make the elimination analysis a separate deliverable you receive regardless.

Fixed price or blueprint

A single number for a defined scope, usually offered after an assessment phase.

What it shifts onto you: the definition of scope. Fixed price is only fixed until something arrives that wasn’t in the definition, and on a 30-year-old estate something always does. A dialect nobody catalogued. An assembler module in the execution path. A file whose layout changes depending on a record type flag.

Fixed price works well when the assessment was thorough and the change control process is defined in advance. It works badly when the fixed number was produced to win the deal and the change requests were always the plan.

Read the assumptions schedule before the price. If the assumptions list is short, the price isn’t fixed, it’s provisional.

Time and materials

You pay for effort. The vendor carries no delivery risk.

What it shifts onto you: all of it. This can still be the right model when the estate is genuinely unknown or when you’re running a discovery-heavy first phase, and it’s honest in a way the other two sometimes aren’t.

The control that makes it workable is a velocity metric agreed at the pilot. Programs converted and validated per sprint, tracked openly. Without that, time and materials on a multi-year programme has no natural stopping point.

The model we’d argue for

Stage it. Fixed price for assessment, because the scope is genuinely knowable. Fixed price per wave for conversion, priced after the pilot has produced a real velocity figure. Time and materials only for the residual, because that’s the part nobody can size accurately in advance.

That structure puts fixed pricing where fixed pricing works and keeps flexibility where the uncertainty actually lives.

A worked example

Numbers here are illustrative and drawn from published market ranges. The point is the shape of the model, not the figures.

Take a 750,000 line COBOL estate. 2 dialects, VSAM as the primary data store, moderate use of dynamic CALL, no regression test suite, financial services.

Discovery finds: 640 programs, 84 copybooks, 310 JCL members, 22% dead code, 40 programs with embedded assembler.

First adjustment. Removing dead code takes the conversion scope to roughly 585,000 lines. At a mid-range conversion rate that’s a saving of several hundred thousand dollars before anything else happens, and it reduces the testing scope by the same proportion.

Second adjustment. The 40 assembler-adjacent programs come out of the automated path and into a separate manual workstream. That’s 6% of programs consuming perhaps 25% of the conversion effort.

Third adjustment. VSAM schema reconstruction across 84 copybooks and 310 JCL members is its own workstream, and on this profile it’s 20% of programme cost rather than the 10% a generic plan would allocate.

Fourth adjustment. No regression suite means the testing phase includes building the oracle. Record and replay against production data needs a data pathway, and in financial services that needs a security review, which is 6 weeks of elapsed time that isn’t on anyone’s technical plan.

Run those 4 adjustments and the estimate moves substantially in both directions. Dead code removal takes cost out. Assembler, data and test construction put it back, and land the programme materially above where a naive per-line calculation would have put it.

That’s the value of assessment. Not a smaller number, a truer one.

Where deterministic transformation changes the arithmetic

Automated conversion approaches split broadly into two families, and they have different cost profiles.

Generative approaches produce output that then has to be checked, because correctness is established after the fact. The verification cost scales with the volume of output, and it’s difficult to forecast because the error rate isn’t stable across code types.

Deterministic transformation works differently. Semantic Designs’ DMS platform, which fuses symbolic AI with enhanced compiler technology, parses the source into a formal representation and applies transformation rules that preserve meaning by construction. The same input produces the same output every time, and the correctness argument sits in the transformation rules rather than in a review pass.

The cost consequence is that verification effort becomes predictable rather than open-ended. You still test, because you should always test. But you’re confirming an expected result rather than hunting for unknown defects across the whole output.

You can read more on the mechanics in how deterministic software transformation works, and about the platform itself on the DMS platform page.

Frequently asked questions

How much does a COBOL to Java migration cost per line of code?

Published industry ranges run from $1 to $25 per line depending on scope. Conversion-only services cluster between $1.50 and $4.00. The wide spread reflects genuinely different work rather than genuinely different rates, so always establish what’s inside the quote.

Is a 500,000-line estate half the cost of a 1 million-line estate?

Rarely. Cost scales with complexity more than with volume. A 500,000-line estate with 4 dialects, heavy dynamic calls and VSAM data can cost more than a clean 1 million-line single-dialect estate.

How much of the budget should go to testing?

Plan for 30% to 40% of programme cost, higher if no regression suite exists today. Underfunding testing is the most common reason migration budgets get exceeded rather than missed.

Does AI reduce the cost of migration?

It reduces cost in discovery, documentation and test generation, where it works well. Claims of large savings on the conversion itself should be checked against how the output gets verified, because unverified output moves cost rather than removing it.

When does a migration pay for itself?

Commonly 18 to 36 months after cutover, driven by mainframe operating costs, licence reduction and hiring economics. Organisations spending more than roughly $500,000 a year on mainframe total cost of ownership tend to reach break-even faster.

Can we get a fixed price?

Yes, after a complexity assessment. A fixed price offered before assessment is either heavily padded or heavily conditional, and in both cases you’re carrying the risk.

Next step

The single fastest way to turn a range into a number is to point analysis at your actual code.

Modernize Software runs a free codebase assessment that inventories your estate, identifies dialects and dependencies, and produces a complexity profile you can estimate against. It takes a code drop and a couple of weeks, and it gives you something more useful than a per-line rate.

If you already know your target, the COBOL to Java migration and COBOL to C# service pages cover how the transformation works in each direction.