Eighteen Months In, With Nothing to Ship. The Benchmark We Would Set Before a Rewrite Starts.

The rewrite was planned for twelve months. It is month eighteen.

The board asks two questions. Can we ship what we have? No. It does about two-thirds of what the old product does, and no customer could run their business on two-thirds. Can we stop, then, and go back to improving the old one? Not really. Eighteen months of the team’s work would be written off, and the old product has had no new features in that time.

So the board approves another six months. It is the third time.

What We Found

For this article we went through the public record on what makes a rewrite of a software product hard to govern: two product firms’ own accounts in case studies published by a vendor, and one survey of IT professionals on why old systems stay.

Three findings stand out.

The products are large, and the teams are not. One maker of insurance software, in an older case, described a product of millions of lines of source code in an old business language. One small maker of property software, also an older case, had a product of hundreds of thousands of lines of code and what its account calls a limited development team. A small team with a large product cannot easily look after the old one and write the new one at the same time. That last sentence is our reasoning, not the account’s.

The firms judged a full rewrite the riskier route. The insurance software maker said that rewriting its product by hand would have been harder and far riskier. That is one firm’s own view of one route, from a case study published by a firm that sells a conversion tool. We use nothing about what either firm did next.

Money and disruption hold firms back. In one survey of about 500 IT professionals in the US, run by a firm that sells software services and covering every sector, more than four in ten named budget limits among their reasons for not modernising an old system, and nearly four in ten named fear of disrupting operations. The survey is not about software firms.

Our reading is that a rewrite becomes hard to stop because of its shape, not because of any fault in the team. Run as one job with one finish, it delivers nothing until the end. Each month spent makes the next easier to approve, and a board that cannot ship and cannot stop can only say yes.

What a Rewrite With One Finish Cannot Do

A rewrite with one finish asks a board for one decision at the start, and then for nothing but patience.

The first cost is that every review becomes a formality. With nothing that can ship and too much spent to stop, the only answer available is “more time”.

The second cost is the old product. The team cannot build each new feature twice, so the product customers are using stands still for the length of the rewrite.

The third is that lateness adds up. Nothing is finished early, because nothing is finished until all of it is.

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

Four Ways to Govern a Rewrite, Weighed

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

Option	When it fits	What it risks
Approve the whole rewrite at the start, and review it at the launch	The product is small and the rewrite short	Nothing to judge until the end, and a launch that carries everything
Extend the rewrite each time its date moves	The end is genuinely close, and what remains is known	Each extension is easier to approve than the last, and the board can only say yes
Stop the rewrite and go back to patching the old product	The rewrite was the wrong call, and the old product has years left	The work so far is written off, and the old product is older still
Set the benchmark first, then rewrite one module at a time, with a pause possible after any accepted module	The product is large, sells every day, and the board wants a real decision at each review	The benchmark and the specification take effort before any new code, 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
Features of the old product listed	Those people remember	Every feature listed, with who uses each as far as your staff can say	The specification
Features matched, or dropped on purpose	Not recorded	Each function of a rebuilt module linked to its replacement, and each feature dropped on purpose recorded with who decided	The traceability matrix
Modules in use	None until the launch	Rising at every stage, each accepted module in use beside the old product	Reported at every review
Ability to pause	None without writing the work off	A pause possible after any accepted module, with what has been delivered and specified kept	The staged plan
What the board decides at each review	Whether to extend	Whether to go on to the next module, on the evidence of the last one	The filled-in benchmark

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 you are planning or are part way through, and what the board is being asked to decide. 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 staged plan divides the rewrite into modules, each with its place in the benchmark. 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 limits. Old and new run side by side for a time, and making them work together for the same customer is engineering that has to be right. The whole may take as long on the calendar as a single rewrite, or longer. We do not keep the old product running, supported or secure while we work; your own team looks after it until the last module has moved. We do not move your customers, their installations or their data from old to new, and how customers meet each new module is your plan. 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; if your product is in another, this is not ours to offer. We have no conversion tool. We offer no design service. We do not say a staged rewrite is quicker, cheaper or free of faults. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	The firm is never eighteen months into a rewrite with nothing it can ship and no way to stop.
CTO or head of engineering	Each rewritten module is in use when it is accepted, so the team learns from real use and is not building a whole second product unseen.
Head of product	The roadmap is not frozen for the whole rewrite, because each accepted module is already in customers’ hands.
CFO	Money is committed one module at a time, and a rewrite that is paused has still delivered what was paid for.
Head of operations	Customers and support meet one change at a time, and not a whole new product on one morning.

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 two product firms’ accounts in a vendor’s case studies and a vendor’s survey of IT professionals.	We set the benchmark before the rewrite starts, rebuild one module at a time beside the old product, and review each module against the benchmark. You can pause after any accepted module. 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 set the benchmark before a rewrite starts, so every review is a decision with something already in use.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →