Paying for converted code can reward preserving work that a modernization programme could remove. The mismatch arises when commercial progress increases with conversion volume while eliminating an unnecessary process reduces that volume without earning equivalent recognition.
This is a conditional incentive analysis, not evidence that suppliers deliberately inflate code or that every conversion contract performs poorly. A volume measure can fit a deliberately scoped conversion; it becomes problematic when the buyer’s objective includes simplification that the measure does not recognize.
The artifact measure can diverge from the outcome
Take a constructed application containing a report used only by a process that the business has authorized to end. Converting the report increases converted-object progress. Retiring it can achieve the desired outcome with less implementation work.
If only conversion counts toward a milestone, the measurement system favors the first result even though the second removes future maintenance. The effect can arise through ordinary planning incentives without any bad intent.
The contract should therefore distinguish required behavior, expendable implementation, and process elimination. Discovery needs a route to change that classification when legitimate new evidence appears.
Conversion still needs a meaningful acceptance boundary
Source transformation addresses a particular representation. Babel’s separation of syntax transformation from runtime polyfills illustrates why emitted code and complete execution support are different properties in its JavaScript context.
A conversion count can omit runtime helpers, manual repairs, integration, and the effort of later maintenance. Those dependencies belong in acceptance even when preserving the original behavior is the chosen goal.
A representative maintenance change can test whether the receiving team understands and can modify the result. More generated code is not itself evidence of greater business value or a workable maintenance path.
Milestones can recognize several valid outcomes
A milestone can accept converted functionality, validated retirement, reconciled data, or demonstrated recovery. Each needs a deliverable, verification method, and prerequisites appropriate to its purpose.
US FAR performance-based financing distinguishes independent from cumulative events in its own federal context. That distinction helps explain dependencies between progress events without turning a finance trigger into proof of production readiness.
The broader proposal here is to recognize accepted removal where removal satisfies the objective. A supplier should not have to recreate an unwanted report merely because the progress definition has no way to count its justified retirement.
Outcome measures have their own failure modes
Replacing conversion volume with a business metric does not automatically create a sound arrangement. The outcome needs a population, baseline, measurement period, quality constraints, and a defensible account of supplier influence.
US FAR performance-work-statement guidance favors required results and measurable standards, but does not itself define an outcome-based payment formula. Attribution and payment terms require separate design.
A metric can improve while difficult cases are excluded or required controls deteriorate. A measurement rehearsal should include those cases and preserve minimum service and quality requirements.
Elimination needs proof that work can cease
An old application can disappear while users recreate its process in spreadsheets or manual work. GOV.UK retirement guidance distinguishes a vanished need from a need served elsewhere; the latter still requires a working destination.
Accepted elimination therefore needs authority, consumer resolution, treatment of open work and records, and evidence across relevant business cycles. Removing code without meeting those conditions would reward another incomplete result.
The incentive hypothesis weakens when contracts already recognize justified removal and measure complete outcomes. It strengthens when accepted simplification reduces reported progress despite satisfying the need. Reviewing that relationship makes commercial milestones reflect the intended modernization result rather than the amount of implementation preserved.