Making accurate estimates for legacy modernization is an exercise in risk management. Every pricing model is really an answer to one question: where does the risk accrue? Is it the customer, the system integrator, or the software vendors?

Our thesis is that AI can help us scope modernization programmes more accurately—and our verification-first approach can increase confidence in delivering the right outcomes. That’s why we quote a fixed number of credits for a particular legacy estate before the work starts, metered on proven equivalence rather than on effort. That gives a system integrator (SI) something new: a known cost for what has been the hardest, least knowable part of the job.

‍

The hot potato

Ask anyone who has bid on a mainframe modernization program what kept them up at night, and chances are it wasn’t “what technology do we apply,” but rather, “how much do I charge?”

A legacy estate is unknowable from the outside. For example, there will be sections of dead code, arcane interdependencies coupling batch jobs to obscure databases, or twenty-year-old “special cases,” that now apply to a quarter of the calendar. The institutional knowledge has left as the people who wrote it have retired. The documentation, even if updated, is merely a snapshot in time.

But needs must. So the SI produces an estimate almost blindly, unsure how much money they’re leaving on the table — or if any profit will be made at all.

For fixed bids, SIs price in a contingency large enough to survive being wrong, which makes the bid expensive and uncompetitive. If the SI bids time and materials, the customer bears the risk, a scenario that is increasingly (and understandably) questioned by customers who are convinced that, surely, AI must be helping with all of this.

This is a pricing problem first and foremost, one rooted in uncertainty. And it is the one we set out to solve.

‍

The elusive outcome

We start with the outcome, because at the end of the engagement, that’s the core unit of value.

While customers modernizing a mission-critical legacy system want agility and the ability to make changes quickly, the safest and ultimately fastest way is to first duplicate the exact behavior of that system, running on modern code on a modern stack in the cloud, containerized, with a test suite, with proven equivalence to the system it’s replacing. Not “translated.” Not “refactored.” Equivalent, demonstrated against the observed behavior of the original, byte for byte.

That phrase, “observed behavior,” is critical. We do not read the legacy code and infer intent from it. We observe the running system, characterize its actual behavior into a corpus of real cases, and then build the new system while verifying against that corpus. The same inputs should produce the same outputs. Equivalence is not an opinion someone offers at the end of the program, nor a codebase that passes the tests it wrote for itself. It is a measurement, taken continuously, against evidence the customer is using today.

This equivalence is a waypoint, not the destination. Rebuilding what you “already have” may sound counterintuitive. Why not extract the business rules, skip the equivalence step, and leapfrog straight to the future state? In fact, it is reliably slower, because it takes on two risks simultaneously. You are changing the platform and changing the behavior in the same motion, with no way to determine the root cause of the inevitable gaps. Every defect becomes an argument between the technology team and the business: those arguments stall these programs in the testing and integration phases for quarters at a time.

Reaching equivalence first separates the two risks. It produces: 1) a system whose behavior is known rather than assumed; 2) a test suite derived from real production behavior rather than from someone’s reading of the code (which is what makes the next change cheap and safe to make, and the one after that); and 3) a legacy system you can actually turn off, which stops the cost, talent, and security clocks from ticking onward while the future-state design is still being argued about. Innovation after equivalence starts from a proven baseline. Innovation instead of equivalence starts from a set of assumptions about what the old system did.

‍

‍

Equivalence is a measurable gate

That is also why equivalence is the unit we meter on. It is the one point on the journey that is objectively verifiable. Not a percentage complete, not a milestone someone declares, but a comparison against the customer’s own system that either matches or it does not. If you are going to price an outcome, you have to price the part that can be proved.

Notice what is absent from that description. The customer does not want seats. They do not want hours. They are indifferent to how many inference passes it took, how many attempts failed, or how much compute was burned getting there. Bids built on those factors charge the buyer for internal difficulties, which is a strange thing to ask someone to fund.

So we price the outcome. Imogen is metered on legacy code modernized and accepted into equivalence. It is never priced on seats, time, tokens, or attempts.

‍

‍

Three layers: a unit, a conversion, a rate

The mechanism has three parts: keeping them separate is what makes it stable.

The unit of measurement is the Imogen Credit. It is what a partner commits to, draws down against, and is billed on. It is not the product. It is a unit of measurement that means the same thing across very different codebases, because it captures the different levels of difficulty in various codebases.

The conversion is lines of code, adjusted for difficulty. The Analyze component of Imogen reads the estate before any modernization work begins and converts it, program by program, into credits: lines of code multiplied by a difficulty surcharge drawn from the language, the data technology, and the workload, with shared code counted once. Plain COBOL batch is the current reference point — one line, one credit. Generated code sits below it, because it is easier for our pipeline. Assembler, PL/I, and densely coupled online workloads sit above it. Those surcharges are based on relative difficulty, not price. The same table applies to every partner.

The rate is dollars per credit, negotiated once. This is where commercial flexibility lives. Larger commitments earn a lower rate per credit, similar to any committed-use curve you have signed with a hyperscaler. Commit more, pay less per credit.

‍

‍

‍

Why bother with the middle layer at all? Why not just price on lines of code? Because a flat "one line, one credit" model reintroduces the mix risk that the credit exists to absorb. A pool denominated in raw lines is a wager on what kind of code shows up, and it misprices in both directions: generated code is verbose but easy, so the buyer burns the pool quickly on lines that cost us little; dense PL/I is the reverse, a smaller number of lines that consume far more than a flat rate would charge for them. Credits only do their job because a difficulty surcharge sits underneath them.
‍

‍

Commit once, draw down per project, true up at the end

For a partner running a pipeline of modernization opportunities rather than a single deal, the structure may look familiar. This is on purpose.

You commit to a pool of credits at your rate, sized to your pipeline. Each engagement draws a block from that pool, sized by running that customer’s estate through our Imogen Analyze capabilities and the surcharge table. Credits retire as outcomes land. At the end of the term, undeployed credits reconcile per the agreement, and overage bills at the same rate you committed. This way, what is consumed is never more than billed, what you’re billed is never more than committed, and the difference between committed and billed is the pool that’s still free to apply to other engagements.

‍

This construct is intentionally similar to a hyperscaler committed-use agreement, so that it is familiar to enterprise procurement teams.

‍

For system integrators: win with outcome-based pricing

On a traditional modernization engagement, delivery labor consumes the overwhelming majority of the contract value.

Apply the mechanics and pricing of Imogen, and that linear link collapses. The analysis, code generation, equivalence verification, the work that used to require people, is largely absorbed by the platform. What remains for the SI is the work that genuinely needs human judgment and client relationship: the internal selling and the last mile: productionalization, data migration, integration, the change management. This level of certainty benefits both the SI and its clients. Specifically for SIs:

You can bid lower and still make more. A known platform cost plus a much smaller labor line means you can price beneath competitors who are still pricing labor plus contingency, and hold a better margin doing it. Our published estimate is that behavior-led modernization with Imogen runs roughly 18x faster than a traditional SDLC with AI assistance on the same problem.

‍

Your margin becomes forecastable. Fixed platform cost, known scope of remaining labor. You can commit to a fixed-price engagement without pricing in your fears.

The gap widens over time. Imogen keeps getting faster. The equivalence generation step alone improved 6x over a single quarter. Every velocity gain shows up as less delivery cost on your side, against a platform fee that was fixed when you signed.

‍

Shift the risk to us

When we quote a certain number of credits to tackle a legacy estate, we are taking a position. The difficulty surcharges are our judgment about how hard that code will be for our pipeline. If we are wrong — the interdependencies are more extreme than our analysis suggested, or a novel language mix behaves in unusual ways — we absorb it. The credit number is fixed for you.

The explanation for this approach is simple:

We believe the risk belongs with the party who can actually price it. We have the Analyze output, the surcharge history, and the delivery data from every prior modernization engagement. An SI bidding on that estate has none of that, however well it knows the client. Part of the reluctance to modernize in general is based on wildly inaccurate estimates stemming from this lack of information.

To be sure, the exposure cuts both ways. If the platform continues to improve and we get better at using cheaper and open models where they are good enough, we come in under our own estimate and keep the difference. Outcome metering means we can only bank that upside by still clearing equivalence. Cheaper models that fail the acceptance bar cost us more, not less.

This is a structural alignment rather than a claim about our character. That is the trade: we hold the variance in exchange for the upside on our own engineering. It is a bet on the software, which is the primary bet a software company should be making.

‍

Questions to ask anyone selling you modernization velocity

If you are evaluating platforms to put behind your bids, the useful questions are not about speed claims.

• Can you give me a fixed cost for the platform’s share of this estate before the work starts?
• What is that number metered on? Provable outcomes, or effort expended?
• If the estate turns out harder than your estimate, whose problem is that?
• Is “done” defined by evidence I can inspect, or by your assurance that it worked?
• When your platform gets faster next quarter, who captures the gain?

‍

Distributing risk fairly

A pricing model is a statement about who you think should carry the risk. The customer knows their business and their operational reality better than we ever will. An SI twenty years into that account knows the landscape, the politics and the integration surface better than we ever will. The estimate in question is narrower than any of that: how much work this specific code will be for our pipeline to modernize and prove equivalent. That is a question about our software rather than about their system, and we assert that we can obtain better data on that than either party.

This way, each party is responsible for the estimate it is best equipped to make. The customer owns what the system must do and what they will accept. The SI owns the client relationship, the integration landscape and the last mile, and prices those (in addition to the forward-looking innovation cycles). We own how hard the code is for Imogen, and price that accordingly.

Hundreds of billions of lines of this code still run the world’s payments, policies, claims, and ledgers, and more than a trillion dollars a year goes into keeping it alive rather than moving it forward. An estate that size does not get modernized one, brave fixed-price program at a time, nor does it move forward with a time-and-materials bid estimated based on little more than a coin flip. It gets modernized when the estimate inspires the confidence to start.

Pricing is not a commercial detail downstream of the technology. It is part of the work. We built Imogen to modernize the software the world runs on. And we priced it so that modernization can happen at that scale.

‍