Buying COBOL modernisation services is unlike buying any other kind of software work. The system in question has been running for thirty or forty years, nobody currently employed fully understands it, and the consequences of getting it wrong are measured in regulatory reporting failures rather than missed sprints. Meanwhile the proposals on your desk all promise the same outcome at wildly different prices.

This guide sets out what a serious engagement actually contains, how the vendor types differ, and which questions separate a bid built on evidence from one built on optimism. It assumes you are the person who has to defend the decision afterwards.

What to look for: A credible COBOL modernisation proposal includes discovery, target design, data migration, conversion or rehosting, a comparison-based testing programme, a parallel run, cutover planning and knowledge transfer. If a bid prices only the code conversion, it is not a programme plan. It is the cheapest quarter of one.

What COBOL Modernisation Services Actually Include

Ask three vendors for a proposal and you will receive three different definitions of scope. Standardising the list before you compare prices is the single most useful thing you can do, because a bid that omits half the work will always look better on the summary page.

Discovery and analysis comes first. The vendor parses the entire estate, builds dependency and data lineage maps, identifies dead code, and produces an inventory of programs, copybooks, job streams and database objects. This phase should also flag the constructs that drive cost: Assembler modules, unusual transaction patterns, variant record layouts and anything the compiler has been tolerating for decades.

Target architecture follows. Someone has to decide what the system becomes: a rehosted COBOL workload, a converted codebase in a modern language, a set of services, or some combination staged over time. This decision belongs before conversion begins, and it should be documented with the reasoning visible rather than asserted.

Data migration covers schema design, extraction, conversion and reconciliation. Mainframe data formats carry meaning that a relational schema cannot express directly, so this work is analytical rather than mechanical.

Code conversion or rehosting is the part everyone focuses on, and it typically accounts for a minority of the total effort. Our guide to mainframe migration tools covers what automation can and cannot do here.

The Phases Buyers Most Often Cut

Testing and comparison is where the money goes. A proper programme builds a harness that runs the old and new systems against identical inputs and compares outputs field by field, then works through the differences until each one is either fixed or formally accepted. This is a software project in its own right and should be priced as one.

Parallel running and cutover means operating both systems for a defined period with real production volumes, then switching over with a tested rollback plan. Programmes that skip this stage to save time are the ones that appear in case studies for the wrong reasons.

Knowledge transfer and support closes the engagement. Your team must be able to operate and change the result without the vendor. If that is not an explicit deliverable with acceptance criteria, you have not bought a modernisation. You have bought a dependency.

The Three Kinds of Vendor, and What Each Is Good At

The market divides into three groups with genuinely different strengths, and the right choice depends more on your estate than on any ranking.

Tool vendors and their partners lead with automated conversion or a rehosting platform. Their technology is usually mature and their conversion throughput is genuinely impressive. The consideration is alignment: their commercial interest lies in maximising the proportion of work their product performs, which is not always the same as producing a codebase you will enjoy maintaining. They also tie your production estate to their runtime, which is a dependency worth pricing.

Global system integrators bring scale, programme governance and the ability to staff a large multi-year effort. If your estate runs to millions of lines across several business units, this capacity matters and few others can supply it. The trade-off is cost structure and the distance between the people who wrote the proposal and the people who will do the work. Ask specifically who is on the team, where they sit, and what their experience is.

Specialist engineering firms are smaller, work with senior people throughout, and are usually tool-agnostic because they have no product to sell. They suit estates in the hundreds of thousands of lines, phased programmes, and situations where the hard part is the business logic rather than the volume. They cannot staff a two-hundred-person programme, and they should say so.

There is no universally correct answer. There is a correct answer for a given estate, and any vendor who claims their model suits every situation is telling you something useful about how they sell.

Questions That Expose a Weak Bid

Procurement questionnaires rarely surface what matters. These do.

“Convert our worst module and show us the output.” Choose the program everyone avoids, ideally one that calls Assembler and uses a multi-level variant record. Ask to see the generated code, not a summary of it. A vendor confident in their approach will do this within a fixed, modest scoping fee. Reluctance is an answer in itself.

“How do you handle decimal arithmetic and sort ordering?” Packed decimal fields and the mainframe collating sequence both produce differences that only appear in financial results and report ordering. Answers should be specific and technical. Vagueness here predicts a difficult user acceptance phase.

“What exactly is in your testing scope, and who writes the comparison harness?” You are looking for a named deliverable, an estimate of effort, and clarity on who supplies production-representative data. If testing is described as a percentage of the build, the vendor is guessing.

“What happens to the differences you cannot explain?” Every programme finds outputs that differ and nobody can account for. Good vendors describe a triage process with business sign-off. Vendors who say this does not happen have either never finished a programme or are not being candid.

“Who owns the resulting source code, and can we leave?” The answer should be that you own everything outright, with no runtime licence required to keep operating. If any part of the answer involves ongoing licensing of a proprietary layer, understand exactly what happens to your production system if you stop paying.

“Show us a programme that went badly and what you changed.” Every organisation that has done more than a handful of these has one. The answer tells you whether you are talking to engineers or to a sales function.

How COBOL Modernisation Services Are Priced

Pricing models vary, and each one distributes risk differently. Understanding that distribution matters more than the headline number.

Time and materials is the most honest model for work with genuine unknowns, and the most uncomfortable for a board. It suits discovery, which should almost always be procured separately and first, precisely so that the rest can be priced against evidence rather than assumption.

Fixed price per module or per thousand lines is common for conversion work and reasonable once discovery has established what the modules contain. Read the exclusions carefully. These prices generally assume code within a defined complexity band, and anything outside it is re-priced individually, which is where the variance lives.

Outcome-based pricing, where payment is tied to accepted functional equivalence, aligns incentives well but requires acceptance criteria precise enough to arbitrate. Defining those criteria properly is worth the effort it takes.

Be sceptical of a firm fixed price for an entire programme quoted before discovery has run. It is not a display of confidence. It is either priced with enough contingency to cover the worst case, in which case you are paying for risk that may not materialise, or it is priced optimistically and will arrive as change requests once the difficult modules surface. Neither is a bargain.

On the question of discounts, this market does not really work that way. Meaningful reductions come from narrowing scope, staging the programme so later phases benefit from what the first one learned, or retiring code that discovery shows is no longer used. A vendor who cuts their price substantially without changing the scope has told you the first number was arbitrary. Our COBOL migration cost and timeline guide breaks down where the budget genuinely goes.

Contract Terms Worth Insisting On

A few clauses do more to protect the outcome than any amount of governance.

Insist on unencumbered ownership of all delivered source code, schemas, scripts and test assets, including the comparison harness. That harness is an asset you will use again for years.

Define acceptance as demonstrated functional equivalence against agreed data sets, not as delivery of code. The distinction between “the conversion is complete” and “the outputs match” is the entire project.

Require a staged structure with genuine exit points. A programme split into discovery, pilot, phased conversion and cutover lets you stop after any phase with something of value in hand. A single monolithic engagement does not.

Name the key people in the contract, and include a clause about substitution. The gap between the team that pitched and the team that arrives is the most common complaint in this market.

Finally, make knowledge transfer a deliverable with its own acceptance criteria, evidenced by your team performing a real change unaided. Otherwise it becomes a slide deck delivered in the final week.

Talk to Engineers Rather Than Resellers

Mecanik works on COBOL modernisation and COBOL migration programmes as an independent engineering firm. We do not resell a conversion platform, so our recommendation on tooling reflects what your codebase needs rather than what we license.

We start with discovery and a paid pilot on your most difficult module, because that produces an estimate grounded in your actual code instead of an industry average. From there we can convert, rehost, or advise you that neither is currently justified, which is occasionally the correct answer. Our COBOL migration service pages set out the phases in more detail, and our guide to mainframe modernisation strategy covers the rewrite, refactor and replatform decision that comes first.

Tell us roughly how large the estate is and what is forcing the timing, and we will tell you what a realistic programme looks like.

Related reading: COBOL to Java Migration - A UK Enterprise Guide 2026 , COBOL to C# Migration - A UK Enterprise Guide 2026 , COBOL to Python Migration - A UK Enterprise Guide 2026 and COBOL to Go Migration - A UK Enterprise Guide 2026 .

Frequently Asked Questions

What is included in COBOL modernisation services? A complete engagement covers discovery and analysis, target architecture design, data migration, code conversion or rehosting, a comparison-based testing programme, parallel running, cutover planning and knowledge transfer. Proposals that price only code conversion are covering a minority of the actual work.

Who provides COBOL to modern language migration? Three groups do: tool vendors and their implementation partners, global system integrators, and independent specialist engineering firms. Tool vendors offer mature automation, integrators offer scale for very large estates, and specialists offer senior engineers and tool independence for mid-sized programmes.

How are COBOL modernisation projects priced? Common models are time and materials, fixed price per module or per thousand lines, and outcome-based pricing tied to functional equivalence. Discovery should be procured separately and first, so that the remainder can be priced against evidence rather than assumption.

Should I accept a fixed price before discovery? Generally no. A fixed price quoted without analysis is either padded with contingency you may not need or optimistic and destined to arrive as change requests. Buy discovery first, then use its findings to obtain firm pricing for the phases that follow.

How do I verify a vendor can handle my codebase? Ask them to convert your most difficult module during scoping and show you the generated output. Choose something containing Assembler calls, variant record layouts and packed decimal arithmetic. What they produce, and how readily they agree, tells you more than any reference call.