Software and tools · 21 Oct 2026

Platform licensing or a modernization service: who owns the outcome?

When an old business system has to be rebuilt, buying a tool and buying a result are different contracts with different risks. A practical guide for US technology leaders on who is accountable when a legacy modernization runs late, breaks something or quietly changes the business rules.

By PrimetimeGeek Tools Desk

Ink illustration of two people on a stone bridge between an old mainframe and a modern cloud skyline, passing a baton marked with a checkmark. — The handoff is the hard part: someone has to own the result, not just the tools. Original conceptual artwork.

Most conversations about modernizing an old application start with technology: COBOL or Java, monolith or microservices, rehost or rewrite. The question that decides whether the project ends well usually comes later, and often too late: when something goes wrong, whose problem is it?

That question has become sharper because modernization is now sold in two quite different shapes. In one, you license a platform — increasingly one that uses AI to read old code, document it, suggest a target design and convert large parts of it — and your own engineers or a systems integrator do the work. In the other, a provider takes the system in and hands back a working, tested application. Both can be reasonable. They are not the same purchase, and the contract should not pretend they are.

This guide is written for CIOs, engineering leaders, procurement teams and founders in the United States who are weighing those options. It is not a vendor ranking. Where we mention a specific company, it is to show how the two models look in practice, and what a buyer should ask about each.

Why this matters more than it used to

Legacy systems are not a niche problem. In a July 2025 report, the US Government Accountability Office said the federal government spends more than $100 billion a year on IT and that agencies typically report about 80 percent of that going to operating and maintaining existing systems. GAO reviewed 69 federal legacy systems and named 11 as most in need of modernization; eight used outdated languages, four had unsupported hardware or software, and seven were running with known cybersecurity vulnerabilities. Of the 10 critical systems GAO flagged in 2019, agencies had completed only three modernizations as of February 2025.

Those are government figures, and private companies are not obliged to look the same. But the pattern will be familiar to anyone who has run a long-lived insurance, banking, logistics or healthcare platform: the people who understood the system have moved on, the documentation is thin, and the cost of keeping it alive crowds out new work. The GAO also found that most agencies responsible for those critical systems had not fully documented their modernization plans. A plan that nobody owns is the most common way these projects stall.

The two models, described plainly

Platform licensing means you pay for access to software and support. The provider is accountable for the tool doing what it says — producing an assessment, generating documentation, converting code, generating tests. Your organization, or the integrator you hire, is accountable for deciding what to build, reviewing the output, fixing what the tool gets wrong, testing it against real behavior and putting it into production.

A modernization service (sometimes called turnkey or managed delivery) means you pay for a defined result: a modernized application that meets agreed functional, performance and security criteria. The provider is accountable for getting there, including the parts no tool handles well — undocumented business rules, odd data, brittle integrations and the long tail of edge cases.

Plenty of arrangements sit in between: a license plus a block of expert hours, a pilot delivered as a service followed by licensing for the rest of the portfolio, or an integrator who uses a vendor platform under its own contract. That is fine, as long as the paperwork says clearly who owns each piece.

What one provider's offer looks like

Legacyleap, a US-facing application modernization company, is a useful example because it openly sells both models. Its website describes Turnkey Modernization Services — “We take full ownership from start to finish,” with managed delivery, validation checkpoints and production-grade output — and Platform Licensing, where customers deploy its Studio (web interface, IDE and command line) inside their own environment and work with internal or integrator teams. Its FAQ frames the choice directly: let the Legacyleap team “own the outcome,” or license the platform and run the work yourself. Legacyleap

The company describes a set of AI agents for assessment, documentation, recommendations, code modernization and test generation, and says these automate roughly 70 percent of modernization work, with assessment and documentation of an application taking two to five days. Those figures are the provider's own claims; we have not independently tested them, and buyers should ask for evidence from a codebase that resembles theirs. What the example shows well is the structural point of this article: the same underlying technology can be sold as a tool or as an accountable result, and the risk lands in different places depending on which you choose.

Who owns what: a practical split

Understanding the old system. Under licensing, the platform may produce the assessment and documentation, but your team owns whether it is correct and complete. Under a service, the provider should own discovery, including interviewing the people who still know where the bodies are buried.

Choosing the target architecture. Under licensing, recommendations are input; the decision and its consequences are yours. Under a service, the provider proposes, you approve, and the contract should say what happens if the approved design turns out not to fit.

Code conversion and its errors. This is where the difference bites. If a licensed tool converts 70 percent of the code and gets part of that subtly wrong, finding and fixing it is your labor and your schedule. Under a service, defects in delivered code are the provider's to fix within the agreed acceptance terms.

Proving nothing changed that should not have. “Functional parity” — the new system behaving like the old one where it should — is the real finish line. Under licensing, generated tests help, but your QA team owns the verdict. Under a service, parity should be a written acceptance criterion with named test suites, data sets and sign-off steps, not a slogan.

Security and compliance. Either way, your organization remains accountable to regulators and customers. A provider can take on contractual obligations, but it cannot absorb your legal duty. Ask where code and data are processed; a platform that runs inside your environment changes the exposure compared with one that requires uploading source code.

Running it afterward. Neither model ends at cutover. Decide before signing who handles the first months of production issues, how knowledge transfers to your team, and whether you can maintain the new code without the vendor's platform.

When licensing is the better fit

Licensing tends to work when you have a capable internal engineering team or a trusted integrator, a portfolio of similar applications to modernize over time, and a strong reason to keep the work and the know-how in-house. It is often cheaper per application at scale, and it builds skills you keep. The trade-off is that you are buying productivity, not certainty. If the program slips, the vendor has usually done what it promised.

When a service is the better fit

A service tends to work when the system is critical, fragile and poorly documented, when your team is already stretched keeping it running, or when leadership needs one accountable party and a fixed definition of done. You pay for the provider carrying risk, and you should expect that premium in the price. The trade-off is dependency: you must insist on documentation, code ownership and knowledge transfer so you are not swapping one black box for another.

Questions to put in writing before you sign

1. What exactly is “done”? Name the acceptance tests, environments, performance thresholds and who signs off. 2. Who pays for rework? If converted code fails acceptance, is the fix included, billable, or your problem? 3. How is parity proven? Ask for the method — differential testing against production-like data, regression suites, side-by-side runs — not just a percentage. 4. What happens to undocumented behavior? Old systems often contain rules nobody wrote down. Who is responsible for finding them? 5. Where does the code go? Clarify whether source leaves your environment, who can see it, and what is retained. 6. Who owns the output? Confirm you own the modernized code and generated documentation outright, and can maintain it without a continuing license. 7. What evidence backs the speed claims? Ask for a pilot on one representative application, with your engineers reviewing the output.

For public-sector buyers, the Federal Acquisition Regulation's performance-based acquisition rules already push in this direction: they ask agencies to describe requirements in terms of results rather than methods and to define measurable performance standards. Private buyers do not have to follow the FAR, but the logic transfers well — pay for outcomes you can measure.

A sensible way to decide

Start with one representative application rather than the whole portfolio. Several providers, Legacyleap among them, offer a no-cost assessment of a single codebase; treat it as a chance to see the quality of the output, not as a sales formality. Have your own architects review the documentation and recommendations. If the result is strong and your team can act on it, licensing may be the efficient route. If the assessment reveals more hidden complexity than your team can absorb, a delivered outcome with clear acceptance terms is likely worth the premium.

The point is not that one model is better. It is that someone must own the outcome, and you should know who it is before the first line of code changes.

Evidence limits

Provider figures in this article, including automation percentages and timelines, are self-reported and were not independently verified by PrimetimeGeek. The GAO findings describe federal systems and may not represent private-sector conditions. We are not aware of an independent, controlled study comparing licensing and managed delivery outcomes for comparable legacy applications. This article is general information, not legal or procurement advice. It was not commissioned or paid for by any company mentioned.