The pitch is always framed as an exit. You are trapped on a mainframe: expensive MIPS, a shrinking pool of people who can touch the code, a platform the rest of the industry has stopped building for. The vendor shows up with a "modernization" path that promises to get you off it. What frequently gets delivered instead is a COBOL program mechanically rewritten into Java or C# syntax that still runs inside a proprietary runtime library the vendor owns — a shim layer that reimplements COBOL semantics (its arithmetic, its file handling, its screen I/O) underneath code that only compiles and only executes against that vendor's SDK. The mainframe lock-in is gone. A new one, licensed annually, with the same vendor as landlord, has taken its place.
This is the part that doesn't make it into the sales deck: a runtime-dependent conversion isn't a step toward vendor independence, it's a change of vendor. The buyer traded a platform they at least understood the economics of — MIPS pricing is ugly but it's decades-old and well documented — for a licensing relationship with a single company whose renewal terms they haven't seen yet, attached to code they can no longer read without that company's tooling. The COBOL is gone from the org chart's skills requirement. It has been replaced by a skill nobody outside one vendor's employee roster actually has.
How to tell a real rewrite from a relocated cage
The test is mechanical and any buyer can run it before signing anything: take the delivered source code, remove the vendor's SDK and support libraries, and try to compile and run it with nothing but a standard, open toolchain for the target language. If it builds and runs, you own working software in a language your own hiring pipeline can staff. If it doesn't — if the build fails without proprietary headers, a proprietary runtime class library, or a licensed data-access layer that only that vendor ships — what you have isn't Java or C#, it's a domain-specific language that happens to use Java or C# syntax, gated behind one company's product. The syntax converted. The dependency didn't.
Watch for the same pattern in three other places, because vendors rarely put the lock-in in the headline feature: the data access layer (does reading and writing your own files or database records require the vendor's proprietary API, or does it produce ordinary calls any developer on the market can maintain), the batch and job-control layer (does the converted code still need the vendor's job scheduler and runtime services to execute a batch run, or does it run under generic infrastructure), and the licensing model itself (is the fee a one-time cost for code you now own outright, or a perpetual per-core or per-transaction royalty that makes the "modernized" system more expensive to keep running, forever, than the mainframe ever was).
The mainframe lock-in was at least a known, priced cost. A proprietary conversion runtime is a new lock-in with an unknown price, set by a vendor who now also controls the only tooling that can read your business logic.
Why this happens on purpose, not by accident
A conversion runtime is a rational business decision for the vendor selling it, which is exactly why it needs to be evaluated as one instead of taken as a technical necessity. A rewrite that produces plain, dependency-free target-language code is a one-time engagement — the vendor gets paid for the conversion and then the buyer owns the outcome and can take maintenance anywhere. A rewrite that requires the vendor's runtime is a perpetual relationship: license renewals, mandatory upgrade cycles tied to the runtime's own versioning, and a maintenance market where the vendor who wrote the shim is structurally the only qualified bidder for every future change. Both outcomes can be marketed with the identical phrase — "converted to modern, maintainable Java" — and only one of them is true without an asterisk.
None of this means every commercial conversion tool is a trap. Plenty of automated-conversion vendors do produce genuinely portable output, and using tooling to accelerate a mechanical rewrite is a defensible engineering choice. The distinction that matters is ownership of the result, not the presence of a tool in the pipeline — and that distinction is exactly what the compile-without-the-SDK test settles, instead of a demo or a reference call ever settling it.
What to demand before you sign
Ask, explicitly, whether the delivered code compiles and runs with a standard open toolchain and no proprietary runtime, SDK, or licensed library — and get the answer in the contract, not in a slide. If the answer is no, ask for the specific ongoing per-core, per-transaction, or per-seat fee structure for the runtime, in writing, for the full expected life of the system, not just the first renewal term. Ask who else in the market is qualified to maintain the delivered code if this vendor's pricing changes or the vendor is acquired — if the honest answer is "no one," you have not modernized off a single point of failure, you have relocated it. And ask for a proof build, before commitment: hand the delivered source to a developer with no access to the vendor's tooling and see whether it runs. A vendor confident their output is genuinely portable will hand it over without hesitation. A vendor who stalls on that request has already told you what the answer is.