Rewrites Lose What Nobody Listed. The Old Product Is the List.

The new version went live on Monday. It is quicker and cleaner, and the team is proud of it.

By Wednesday support has a pattern in its tickets. Where is bulk edit? Where did the export to a spreadsheet go? Why can I no longer copy last month’s order?

None of these was cut on purpose. They are simply not in the new product. Nobody listed them, because nobody thought of them as features. They were just things the old product did.

What We Found

For this article we went through the public record on rewriting a software product: one trade publication’s account of a large firm’s rewritten app, one product firm’s own remark in a case study published by a vendor, one large software firm’s engineering account and one seller’s own experiment in converting old code with AI tools.

Four findings stand out.

A rewrite can reach customers without what the old product did. One large consumer electronics firm also makes the mobile app that controls its products. By one published account, the old app was built on old code and infrastructure that had been left largely alone for about two decades. The rewritten app launched in 2024 without many of the basic features the old one had. This is a mobile app at a large firm, which is not our kind of work, and we use it for one narrow point only.

The list of what had to be right before launch was too short. By the same account, the firm reportedly had a list of essential faults to fix before the launch, and that list was not complete enough. We did not examine why the app was released as it was, and we draw no cause from it.

Firms with large old products judge a rewrite risky themselves. One maker of insurance software, in an older case, described a product of millions of lines of source code in an old business language. Its own view was that rewriting it by hand would have been harder and far riskier. That is one firm’s view of one route, from a case study published by a firm that sells a conversion tool. We use the remark and nothing about what the firm did next.

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 behaved differently when they ran. 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. The seller has an interest in the answer. Neither says such tools are of no use. Both say that what is produced has to be checked against what the old code did.

Our reading is that a rewrite loses features for a plain reason. The new product is built from a description of the old one, and that description is made from what people remember. The old product itself, the only complete record of what it does, is set aside as the thing being replaced. Whatever writes the new code, a person or a tool, it can only be as complete as the list it was given.

What a Rewrite Built From Memory Cannot Do

A rewrite is usually discussed as an engineering risk. Our reading is that it is first a matter of record: nobody holds a list of what the product does.

The first cost lands at launch. A firm that has no list learns what its own product did from its customers, in the week it most wants them pleased.

The second cost is that nobody can tell a decision from an accident. When a feature is missing, nobody knows whether it was dropped on purpose or simply forgotten, so nobody can tell customers in advance or offer them another way to do the same job.

The third is the scope. Each forgotten feature, found during the build, arrives as work nobody budgeted. The rewrite grows, the date moves, and each addition has the same honest explanation: it was not on the list.

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

Four Ways to Specify a Rewrite, Weighed

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

Option	When it fits	What it risks
Specify the new product in workshops, from what people remember	The product is small, young, and the people in the room built most of it	What nobody remembers is left out, and customers find it
Rebuild from the old documents and specifications	The documents have been kept up to date with every release	Documents describe what was planned, not what the product does today
Launch a first version, then add back what customers ask for	Customers are few, close and forgiving	Customers do the audit, and features are added back in a hurry
Read the old product into a specification, decide on each feature, then rebuild one module at a time with each old function linked to its replacement	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, and the list makes the rewrite look larger, because it is

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, named or not, with who uses it as far as your staff can say	The specification
Features with a decision	None	Each marked keep, change or drop by someone in product with the authority to decide	The specification, confirmed by your own people
Features dropped on purpose	Not recorded	Every dropped feature recorded, with who decided	The traceability matrix
Old functions matched to new ones	Not recorded	Each function of a rebuilt module linked to its replacement	The traceability matrix
Missing features first reported by customers	Not counted	Counted at each module, and each one traced back to the list	Your own support records

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 being planned and what worries you about it. 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 lists what the product does, feature by feature. 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. 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 keep the old product running, supported or secure during the rewrite; your own team does. We do not move your customers, their installations or their data from old to new. We offer no design service. Reading finds what the code does; a habit that lives outside the product, in how your staff or customers use it, can still be missed. We do not say a rewrite done 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	The firm does not learn what its own product did from customers’ complaints on launch day.
CTO or head of engineering	The team builds against a list taken from the old product, and not against what people remember.
Head of product	Every feature of the old product is on a list, and each is kept, changed or dropped by a decision product made.
CFO	The rewrite is priced from a written scope, and features found late do not arrive as work nobody budgeted.
Head of operations	Support knows before launch what will be different, and is not the first to hear of a missing feature from a customer.

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

The case

What IOanyT does

A large consumer electronics firm launched a rewritten app in 2024 without many of the basic features the old one had.

IOanyT does not build mobile apps, and its part in this kind of problem is narrower. We did not examine why that app launched as it did and draw no cause from it, and we do not say any approach of ours would have prevented it. For a web product in a technology we read, we take the specification from the old product and link each old function to its replacement, or record that you chose to drop it.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We start a rewrite by reading the old product, because it is the only complete list of what the new one must do.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →