Halfway Through a Rewrite, the Money Is Spent and Nothing Ships. Let the Old Product Be the Judge.

The rewrite has four thousand tests, and all of them pass. The dashboard is green from top to bottom.

A customer in the trial sends a file. It is a real month of their work, run through the old product and through the new. The invoices do not match. Thirty of them differ by small amounts, and two are missing.

The team looks for the failing test. There is none. Every test was written from the new specification, and the new product does exactly what the specification says. It simply does not do what the old product does.

What We Found

For this article we went through the public record on how a rewritten product is checked against the one it replaces: one large software firm’s engineering account, one seller’s own experiment in converting old code with AI tools, one survey of developers who work in PHP, one developer’s own account of old code, and one product firm’s own remark in a case study published by a vendor.

Four findings stand out.

Code that reads correctly can behave differently. One large software firm, writing about its own move of old code, found that translating individual files without the code they depend on gave partial rewrites that looked correct as code but did not behave as expected when they ran. In plain words: the new code read correctly, and did something else when run.

Most of what a tool converts still needs a person. One seller of paid support for an old web framework, reporting its own experiment with AI tools, wrote that between half and three-quarters of the code converted successfully. It added that nearly every file came across with some issues. The seller has an interest in the answer. Neither account says such tools are of no use, and we use them ourselves. Both say the result has to be checked against what the old code did.

Many products have little to check against. In one survey of more than 1,700 developers who work mainly in PHP, a widely used web language, about a third said they still write no tests at all. One developer, writing about old code, said nothing is more frightening than changing a critical old system that has no tests. Both are about developers in general, not about software firms alone.

Product firms count a full rewrite as the riskier route. One maker of insurance software, in an older case, said that rewriting its product by hand would have been harder and far riskier. That is one firm’s view, from a case study published by a firm that sells a conversion tool, and we use nothing about what it did next.

Our reading is that a rewrite is usually judged against the wrong thing. Its tests are written from its own new specification, so they share every gap in it. The old product, which customers will compare it with, is consulted at the very end, if at all. Until then nothing can be accepted, so nothing can ship.

What a Rewrite Without a Judge Cannot Do

A rewrite judged only at the end has one shape. Halfway through, the money is spent and there is nothing to ship.

The first cost is that progress is measured in the wrong unit. A share of tests passing says the new product does what was written down. It says nothing about what was left out, so a rewrite can be “nearly done” for a long time.

The second cost is rework found late. When the comparison with the old product comes at the end, a difference could have come from anywhere, and modules that were signed off months ago are opened again.

The third is that the firm cannot stop usefully. A half-built product that has never been compared with the old one cannot be put in front of a customer, so stopping means writing the work off.

This is our reading of the evidence. It is not a measured market figure.

Four Ways to Run a Rewrite, Weighed

There are four real options. Each one is right for somebody.

Option	When it fits	What it risks
One large rewrite, launched when it is complete	The product is small, and customers can wait for the whole of it	Halfway through, the money is spent and there is nothing to ship; the comparison with the old product comes last
Freeze the rewrite, and patch the old product instead	The product has few years left, or the firm cannot afford a rewrite now	The old product keeps ageing, and the rewrite question comes back larger
Rewrite module by module, from what people remember	The product divides cleanly and the team knows every corner of it	Each module can miss what nobody listed, and there is nothing to judge it against
Specify first from the old product, then rewrite module by module, with a traceability matrix for each	The product is large, old and much changed, sells every day, and nobody holds a full list of what it does	It costs time before any new code is written, old and new run side by side for a time, and the calendar may be longer

Where You Are Now, and Where You Should Be

A recommendation is only useful if you can tell later whether it worked. So before any work begins we set a benchmark: a few measures taken from your own product, each with a target.

For this issue, the benchmark would look like this.

Measure	Typical starting point	Where it should be	How it is checked
What each module is judged against	Its own new specification	A specification taken from the old product, confirmed by your own people	The specification
Old functions matched to new ones	Not recorded	Each function of a rebuilt module linked to its replacement, or recorded as dropped on purpose	The traceability matrix
Modules in use	None until the launch	Each accepted module in use, with the old product running the rest	Reported at every review
Where a difference from the old product is found	In a customer’s trial, at the end	In the module that caused it, before that module is accepted	The record of each module’s acceptance
What the money spent so far has bought	Nothing in use until the end	Each milestone tied to a module you accept	The staged plan and its milestones

The starting points above are what the public record suggests and what we expect to find. In an engagement they are replaced by your own figures, taken in the first review. The targets are what we would work towards with you. They are not results we have already achieved for a software firm.

How We Work With You

1. We listen: a free Reliability Review. A first conversation about your product, the rewrite under way or planned, and how its progress is judged. You leave with a short written note of what we found. You can start with a conversation about the system; we ask for read-only code access only when the assessment begins.
2. We research. We research your sector, the regulator’s position and what the public record says about firms in your situation. This article is an example of that work.
3. We read the system and propose: the Legacy System Specification Assessment. Here the system is your own product’s code, and the specification becomes the standard each rewritten module is judged against. It produces a map of the system as it stands, a written specification of what it does, a risk register, a cost comparison between keeping and replacing the system, and a staged plan with a fixed quote. AI does a first pass, our senior engineers review it and trace it to the code, and your own experts confirm it. Code access is read-only and logged, never used for training, and deleted within 30 days of the evaluation ending unless we engage. You get the options and our recommendation.
4. If you approve, we build. We replace a system one module at a time while the old one keeps running. Here that means the product keeps selling while each part is rebuilt on React, Node.js, Python or Java. We never do a single cutover. Each module has a traceability matrix. The work is billed by milestone, each milestone tied to a module you accept, and you can pause after any accepted module.
5. We review against the benchmark. Before work starts we set the benchmark. After each module we show you where each measure stands, and the filled-in benchmark is yours at the end.

The Review is free. Every paid step is fixed price, agreed at scoping. Stop after any step. The findings are yours. The assessment fee is credited in full against the first build stage if it starts within 90 days of the report.

This approach has a price. Old and new run side by side for a time, and the same customers use both, so how they work together is part of the engineering of each module. The comparison needs the old product to keep running; we do not keep it running, supported or secure, and your own team does. A match with the old product shows that a module behaves as the old one did; it does not show that the old one was right, and an old mistake stays until someone rules on it. What we rebuild, we rebuild as a web application on React, Node.js, Python or Java; we do not build mobile apps or desktop programs. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP, and no others. We have no conversion tool and do not convert code by machine. We do not move your customers, their installations or their data. We offer no design service. We do not say this way is quicker, cheaper or free of faults, and it may take longer on the calendar than one large rewrite. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	”Is the rewrite ready?” gets an answer made of results, and not of confidence.
CTO or head of engineering	Tests taken from the old product say when a rewritten part is finished, including the parts AI tools helped to write.
Head of product	What customers see behaves as it did, unless product chose to change it.
CFO	Rework is found in the stage that caused it, and is not carried forward into a later budget.
Head of operations	Customers’ real cases have been run through the new product before support has to answer for it.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
This article names no organisation. Its figures come from one large software firm’s engineering account, one seller’s experiment, a survey of developers, one developer’s account and one product firm’s remark in a vendor’s case study.	We take the specification from your old product, rebuild one module at a time beside it, and accept each module only when its traceability matrix links every old function to its replacement or records that you dropped it. We do not keep the old product running or move your customers.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We let the old product judge each rebuilt module, so a rewrite has something in use long before it ends.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →