Choosing COBOL modernization consultants is one of the few decisions in a modernization program that is hard to reverse. Once a firm has run your assessment, chosen the target architecture and started converting code, switching partners means paying twice for the same understanding of your system. This guide is for the IT leader, enterprise architect or procurement lead who has been asked to find a partner and wants a method that holds up in front of a steering committee.
It covers what you are really buying, the four kinds of firm that describe themselves as COBOL modernization consultants, the twelve criteria that separate them, how to write the RFP, how to run a pilot that produces evidence, how to score responses, and which contract terms protect you once the work starts. It does not name or rank firms. A ranked list reflects visibility more than fit, and the criteria below are designed to test fit against your own estate.
What you are hiring COBOL modernization consultants to do?
Most searches for “best COBOL modernization consultants” start with a vague brief. Someone senior has decided the COBOL estate is a risk, a budget line exists, and the question has become “who do we call?” Before calling anyone, it helps to separate the jobs a consultant might do, because very few firms are equally strong at all of them.
- Assessment. Inventory the estate, measure its size and complexity, find the dependencies, and estimate effort. A good assessment tells you how many programs exist, how many are dead, which copybooks are shared, which programs touch which datasets, and where the dialect-specific or platform-specific code sits.
- Strategy. Decide what should happen to each part of the estate: leave it alone, expose it through APIs, rehost it, translate it, rearchitect it or replace it with a package. This is where commercial interests show most clearly, because a firm that sells one approach tends to recommend it.
- Conversion. Change the code. Depending on the strategy, that might mean recompiling for a new runtime, translating COBOL to Java or C#, or rewriting from extracted requirements.
- Data migration. Move VSAM, IMS, Db2 or flat-file data into the target stores, convert encodings and packed fields, and reconcile the results.
- Verification. Prove the new system produces the same results as the old one, across online and batch, through month-end and year-end processing.
- Cutover and decommissioning. Plan the switch, run in parallel, retire the old platform and close out licenses and contracts.
- Knowledge transfer. Leave your team able to maintain what was delivered without the consultant.
When you write the brief, say which of these you want the consultant to own, which you will do yourselves, and which you have not decided. A firm that is excellent at conversion and verification may be the wrong choice to lead strategy, and the reverse is common too.
The four kinds of firms that sell COBOL modernization
Firms that appear in response to “COBOL modernization consultants” fall into four broad groups. Each has a legitimate place, and each has a characteristic blind spot.
Large systems integrators
Global integrators bring program management, large delivery teams, industry experience and the ability to absorb risk on very big contracts. They are often strongest at governance, change management and running many workstreams at once. Their conversion work is frequently delivered through partner tools or subcontracted specialists, so the people who sold the engagement may not be the people who change your code. Ask who does the conversion, with what technology, and whether that party is contracted to you or to the integrator.
Specialist translation and tooling firms
These firms own the technology that parses and transforms code. Their depth sits in language semantics, dialect coverage and repeatable automated conversion. They are usually smaller, and some rely on a partner or on the client for program management and business change. Ask how they handle the work around the code: data, testing, cutover and the people side of the program.
Platform and rehosting specialists
Some firms focus on moving COBOL off the mainframe while keeping it as COBOL, running it on a compatible runtime on distributed servers or in the cloud. Rehosting can cut infrastructure cost quickly and reduce risk in the short term. The blind spot is that the language, the skills problem and often a runtime license remain. Ask what the estate looks like in year three, and what it would take to move from the rehosted state to a translated one later.
Independent advisors and staff augmentation
Independent advisors help with assessment, business case and vendor selection without a stake in the delivery approach. Staff augmentation firms supply COBOL developers, testers or architects to work inside your team. Both are useful, and neither usually carries delivery risk for the conversion. Ask what outcome the advisor is accountable for, and whether augmentation staff have worked on a migration or only on maintenance.
Most serious programs combine at least two of these. A common pattern is an independent advisor for assessment and selection, a specialist firm for conversion and verification, and an integrator or internal team for program management. Knowing the categories lets you decide which combination you are buying instead of accepting whatever bundle arrives in a proposal.
Decide these four things before you shortlist anyone
Consultant selection goes wrong most often because the buyer has not decided what they want, so every firm answers a different question and the responses cannot be compared. Settle four things first.
The driver. Is the program about skills risk, cost, a platform end of support, integration speed, regulatory pressure or a combination? The driver decides which strategy is sensible and which evaluation criteria carry the most weight. A skills-driven program that picks a rehost, for example, has solved the wrong problem.
The target. You do not need a final architecture, but you need a direction. Java or C#? Cloud, on premises or both? Relational database or keep the file structures for now? If you leave the target fully open, you will receive proposals shaped by each firm’s preferred stack.
The scope boundary. Which applications, which environments, which interfaces? The surround of a mainframe estate, including JCL, schedulers, utilities, security rules and reports, is often larger than the COBOL. Decide whether it is in scope.
The constraints. Regulatory freeze windows, peak trading periods, contract end dates for hardware or software, staff you must retain and data you cannot move offshore. These rule firms in or out before any scoring.
Write these down in two pages. They become the first section of the RFP and the reference point for every scoring discussion afterwards. The GAO’s review of federal legacy systems found that agencies with weak modernization plans typically lacked three things: milestones, a description of the work needed, and a plan for disposing of the legacy system (GAO-19-471). Those three elements are a useful minimum for your own brief too.
Twelve criteria for evaluating COBOL modernization consultants
The criteria below apply whichever category of firm you are assessing. Weighting them is covered later. For the tool-level questions that sit underneath several of these, such as automation rates and how converted output is verified, our piece on whether automated COBOL to Java conversion is reliable goes deeper.
1. Dialect and ecosystem coverage
Enterprise applications rarely conform to a single, standardized version of a programming language. Languages such as COBOL have numerous dialects, compiler extensions, and implementation-specific behaviors. Applications also depend on a broader ecosystem of technologies: transaction processing systems, databases, file systems, schedulers, middleware, and other platform-specific components. These variations can significantly impact the complexity and outcome of a modernization effort.
When evaluating modernization vendors, organizations should look for flexibility and extensibility in the transformation technology. A capable modernization platform should be able to adapt its translators and analysis to support additional language dialects, proprietary extensions, and technologies that may be unique to a customer’s environment. This is particularly important when applications contain constructs or dependencies that fall outside a vendor’s standard capabilities. The ability to extend the technology provides greater flexibility to address real-world application environments and reduces the risk of being constrained by a fixed set of supported languages and technologies.
2. Evidence on your own code
A firm’s slides describe other people’s systems. Ask every shortlisted firm to process a sample of your code: a few programs with their copybooks, ideally including one that uses REDEFINES heavily, one with CICS, one with complex arithmetic and one batch job with its JCL. What comes back, how long it takes, and how many questions they need to ask will tell you more than any reference.
3. Verification method
Every firm will say it tests. The useful question is how it proves equivalence between old and new. Ask for the method: how test data is chosen, whether they run the old and new systems side by side on the same inputs, how differences are triaged, who signs off acceptable divergence, and what evidence the business receives. A method that relies on user acceptance testing at the end of the program is a warning sign.
4. Maintainability of the output
Converted code that runs but that your developers refuse to maintain has moved the problem somewhere else. Establish architecture and code style standards and ask the potential vendor how they achieve those standards.
5. Ownership and runtime dependency
After the modernization project, what do you own and what do you still license? Some approaches leave you dependent on a proprietary runtime or library to execute the converted code. That may be acceptable, but it should be explicit. Ask whether the delivered code compiles and runs with standard, openly available toolchains, and what happens to your system if the firm stops trading.
6. Data migration capability
Code conversion gets the attention, but data migration is where schedules slip. Ask how the firm converts packed decimal and binary fields, handles EBCDIC to ASCII or Unicode, maps REDEFINES and OCCURS DEPENDING ON into a relational design, and reconciles record counts and control totals after each load. Ask who wrote the data migration tooling and how often it has been used.
7. Handling of business rules
Decades of changes live in the code, and much of it is undocumented. Ask how the firm extracts and replicates business rules. The right answer usually preserves current behavior first and fixes defects as a separate, visible decision.
8. The team that will do the work
Ask for named people for the key roles, their actual experience, and a clause that stops substitution without your agreement. Check the ratio of senior to junior staff, where the team is located, and how much of the work goes to subcontractors. A strong bid team followed by an unknown delivery team is a common pattern.
9. Knowledge transfer
The consultant will leave. Ask what your team will be able to do on the day they do: build, test, deploy and change the new system without help. Ask how knowledge transfer is scheduled, whether it is measured, and whether your developers work inside the conversion team from the start or receive a handover at the end.
10. References in comparable estates
References are only useful if the estate resembles yours. Ask for references with similar dialects, similar size, a similar target and, ideally, the same industry. Speak to the reference’s technical lead as well as the executive sponsor. Questions for references are covered later in this guide.
11. How the commercial model allocates risk
This guide does not cover prices, but the structure of the commercial model matters for selection because it decides who carries the risk of surprises. Per-line pricing, fixed price, time and materials and outcome-based models each move risk differently. Our piece on what drives COBOL to Java migration cost walks through each model. In the RFP, ask each firm to state which risks it carries under its proposed model, in plain words.
12. Security and supply chain controls
A modernization partner will handle source code, production-like data and sometimes credentials. Ask how code and data are stored and transferred, whether any processing happens in third-party services, how test data is masked, and which subcontractors or tools touch your assets. NIST’s guidance on cybersecurity supply chain risk management is a useful structure for these questions (NIST SP 800-161 Rev. 1). If a firm uses Gen AI services during conversion, ask where prompts and code are sent, and whether they are retained.
Red flags in COBOL modernization proposals
Some patterns in proposals predict trouble. None of them is disqualifying on its own, but each should prompt a direct question.
A single automation percentage with no definition. “95% automated” means nothing until you know what was counted, over which code, and what the other 5% contains. The residual is often the hardest code in the estate. The patterns behind this are covered in our piece on why mainframe modernization projects fail.
Redesign during migration. Proposals that promise to convert and add features at the same time add risks. It can be done, but the proposal should explain how the firm keeps those changes separable and testable.
No named people. A proposal that lists roles without names has not committed a team.
Vague answers on ownership. If the firm cannot say plainly whether you can run the output without its runtime or libraries, assume you cannot.
An estimate before an assessment. Be cautious of vendors that commit to a fixed price for a large modernization program before conducting a meaningful assessment of your source code. Without understanding the actual complexity, code quality, dependencies, dialects, and unique characteristics of the application, a firm fixed price necessarily relies on assumptions and contingency.
Those assumptions are built into the price you pay, whether or not the anticipated complexity actually exists in your system. A more transparent approach is to perform an initial assessment to establish the true scope and technical requirements, then use that information to develop a firm, defensible price and project plan. This approach aligns the cost of the modernization with the actual characteristics of your application rather than paying upfront for risks that may never materialize.
Unexplained use of Gen AI. Gen AI tools help with documentation, test generation and code explanation. A proposal that relies on Gen AI to translate core business logic should explain how nondeterministic output is verified and reproduced.
Questions to ask a consultant’s references
When you speak to references, ask for the technical lead as well as the sponsor. Useful questions include:
- What did the estate look like when you started, and how close is it to ours?
- How accurate was the original estimate, and what caused the difference?
- What was the hardest part of the program, and how did the firm handle it?
- Did the named team stay on the program?
- How were differences between the old and new systems found and resolved?
- Can your developers maintain the delivered code today without the firm?
- If you started again, what would you change about how you worked with them?
- Would you hire them again for the next phase?
Contract terms that protect you once the work starts
Selection is only half the protection. The contract decides what happens when the program meets reality.
An exit condition for each phase. Every phase needs a written definition of done that both sides can test. Without one, phases blur and the program drifts.
Acceptance tied to equivalence evidence. Acceptance should depend on the agreed verification results. A delivery date or a handover of files is not evidence of correctness.
Ownership of the output and of the knowledge. You should own the converted code, the test assets, the rule documentation and the data migration scripts. If the firm’s tools remain its property, the contract should still guarantee you can build and run the output without them.
Key personnel. Name the people who matter and require your agreement before they are replaced.
Change control for scope discoveries. Assessment always misses something. Agree in advance how newly found programs, interfaces or data are priced and scheduled.
Knowledge transfer milestones. Make knowledge transfer a measured deliverable with its own acceptance criteria, scheduled throughout the program.
Termination and transition assistance. If you need to change partners, the outgoing firm should hand over everything needed for a successor to continue.
Programs that plan to replace legacy functions gradually, routing traffic from old to new component by component, need contract phases that match that incremental shape. Martin Fowler’s description of the strangler fig pattern is a useful reference when you design phase boundaries around incremental cutover.
Where Modernize Software fits
Modernize Software is the modernization arm of Semantic Designs, which has built language processing technology for decades. Our engagements center on the parts of a program where the code itself changes: assessment of the estate, translation of COBOL to Java or C#, and the verification that the new system behaves like the old one.
The translation work uses DMS, which combines symbolic AI with enhanced compiler technology to parse each program in its dialect, understand its meaning, and apply transformation rules consistently across the whole estate. The same input produces the same output every time, which makes the results repeatable and auditable. Gen AI serves as a separate augmentation layer for documentation, test generation and code review.
We are comfortable working alongside an integrator, an internal program office or an independent advisor, and we expect to be evaluated on a pilot using your own code. If you are preparing an RFP, the COBOL modernization page describes the scope we typically take on.
Frequently asked questions
1. How many COBOL modernization consultants should we shortlist?
Three to five for the RFP stage is manageable, narrowing to two or three for a paid pilot. More than that makes scoring harder and discourages strong firms from investing in a thorough response.
2. Should the same firm do the assessment and the conversion?
It can, and continuity has value. The risk is that a firm assessing an estate it hopes to convert may shape the assessment around its own approach. Some buyers use an independent advisor for assessment, or make the assessment a separately priced phase with no guarantee of the follow-on work.
3. How long does it take to select a COBOL modernization partner?
A realistic selection, pilots and contract negotiation can take several months. The pilot is the longest part. Compressing selection starts with clearly defining objectives upfront, so they do not have to be discovered during negotiations.
4. Is a paid pilot worth it if we already trust a firm?
Yes. The pilot tests the fit between the firm’s approach and your specific code, which no amount of trust can predict. It also produces your first verified assets, test data and effort baseline, all of which are useful whoever does the rest of the work.
5. Can we use Gen AI tools instead of consultants?
Gen AI tools are useful for explaining unfamiliar code, drafting documentation and suggesting test cases. Converting a large, business-critical estate still needs a repeatable translation method, a verification process and people who understand both platforms. Most programs use Gen AI as one part of that method.
6. What should we prepare before contacting COBOL modernization consultants?
A short brief covering the driver, target direction, scope and constraints; the best inventory you can produce; a representative code sample that can be shared under NDA; and a list of the business functions that must be proven equivalent. That preparation makes every conversation with a consultant more productive.
.png)
info@semanticdesigns.com
