The Rewrite That Shipped Without the Old Features

1. At a Glance

Issue study · From the public record. None of the organisations described here was an IOanyT client, and IOanyT had no part in the events described. Everything about them comes from the public record.

Organisation type	Software firms that must rewrite their own product: one large consumer electronics firm and the mobile app that controls its products, and two makers of business software (insurance, property) as the record describes them
Size band	The firms in the record: one large, and two others described by the research as mid-size to large and small. Our reader: a small or mid-size software firm whose product has sold for ten years or more
Region	Outside India for all three firms; the regions are not material to the point
The decision at stake	Whether, and how, to rewrite a product that customers use every day, without losing what it does or staking the firm on one launch
The public outcome	The rewritten app launched in 2024 without many of the basic features the old one had. One maker of insurance software judged that rewriting its product by hand would have been harder and far riskier
Why it matters to a small or mid-size software firm	A rewrite is usually the largest bet a product firm makes on its own product. If it is specified from memory and judged only at the end, it can leave out what customers used and have nothing to ship until it is finished

2. The Business Problem, in the Buyer’s Words

“Our product has sold for eleven years, and the code under it is hard to change. Everyone agrees it has to be rewritten. What worries me is the rewrite itself. Our specification came out of six workshops, and I know it is what people remembered. Our tests are written from that specification. And the plan is one launch, eighteen months out, with no new features until then. If it runs late, I will have spent the money and have nothing to sell. If it launches, I will find out from customers what we forgot.”

These words are imagined. They describe the decision as the research shows it, not a real conversation.

The firm is caught between old code it must leave and a rewrite that puts everything on one date. It cannot say what the old product does, cannot show the new one matches it, and cannot stop part way with anything in use.

3. What We Found

Method. We went through the public record on rewriting a software product: one trade publication’s account of a large firm’s rewritten app, two product firms’ own accounts in case studies published by a vendor, 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 account of old code, and one survey of IT professionals on why old systems stay.

A rewritten app, launched without basic features. This is a mobile app at a large firm, which is not IOanyT’s kind of work. We use it for one narrow point: a rewritten product can reach its customers without things the old one did.

What	Public record
Organisation	A large consumer electronics firm, and the mobile app that controls its products
The old app	Built on old code and infrastructure that had been left largely alone for about two decades
The rewrite	Launched in 2024 without many of the basic features the old app had
The list of faults to deal with before launch	The firm reportedly had a list of essential faults to fix before launch, and the list was not complete enough

We did not examine why the app was released as it was, or how its rewrite was specified, tested or managed, and we draw no cause from the record.

Two firms that judged a rewrite risky. These are older cases, from case studies published by a firm that sells a conversion tool. We use only what they say about the problem, not what the firms did next, and do not name them. Neither page is dated.

Product	What the account says
Insurance software (an older case, from the late 2000s by the versions named)	A product in an old business language of millions of lines of source code. The firm judged that rewriting it by hand would have been harder and far riskier
Property software (an older case, from the mid-2000s)	Hundreds of thousands of lines of code, with a limited development team

What is reported about rewriting with AI tools. 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, in its own experiment, reported that between half and three-quarters of the code converted successfully, and that nearly every file came across with some issues. The seller has an interest in the answer. Neither says such tools are of no use. Both say the result has to be checked against what the old code did.

How developers and firms regard the change. In one survey of more than 1,700 developers who work mainly in PHP, about a third said they still write no tests at all. One developer wrote that nothing is more frightening than changing a critical old system that has no tests. In one survey of about 500 IT professionals in the US, run by a vendor and covering every sector, more than four in ten named budget limits and nearly four in ten fear of disrupting operations among their reasons for not modernising.

Our reading of why rewrites go wrong. These four are our reasoning from the record above. None is a finding of any source, and none is said to explain the rewritten app.

1. The rewrite is specified from memory. Nobody holds a list of everything the old product does, so what people forget is left out, and nobody can tell a feature dropped on purpose from one lost.
2. It is judged against its own specification. The tests share the specification’s gaps, and the old product’s unwritten rules are checked by nobody.
3. New code can read correctly and behave differently. Whoever or whatever writes it, it has to be checked against what the old product does.
4. It delivers nothing until it is finished. So halfway through, the money is spent and there is nothing to ship, and the board can neither ship nor usefully stop.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
One large rewrite, specified in workshops and launched when complete	The product is small, and customers can wait for the whole of it	What nobody remembers is left out; halfway through, the money is spent and there is nothing to ship	We would advise against this for a large, old product that sells every day
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	Right only as a pause with an end date
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	Better than one launch; still built from memory
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; old and new run side by side for a time; the calendar may be longer	Our recommendation

5. Our Recommendation, and the Decision It Asks of the Board

Take the specification from the old product, and have the firm’s own people confirm it. Mark each feature keep, change or drop, by decision. Then rewrite one module at a time on a current stack, beside the old product, and accept each module only when its traceability matrix links every old function to its replacement, or records that the firm chose to drop it. Each module goes into use when accepted, and is paid for by milestone. The old product keeps running everything that has not yet moved.

6. Benchmark: Where You Are Now, and Where You Should Be

These are targets, not results. In an engagement the starting points are replaced by the firm’s own figures, taken in the first review.

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 the firm’s 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
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

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your product, the rewrite being planned or under way, 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 study 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.
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. A traceability matrix links every old function to its replacement. 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.

8. What the Client Would Own

• The map and the specification: what the old product does, feature by feature, with the firm’s decision on each, confirmed by its own people.
• The risk register: what the assessment found, listed before any price is set.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement, or recorded as dropped on purpose.
• The code: the rebuilt modules are the client’s. No runtime or platform fee.
• The filled-in benchmark: each measure, where it started and where it stands.

9. What This Approach Does Not Cover

• IOanyT does not build mobile apps or desktop programs. What it rebuilds, it rebuilds as a web application on React, Node.js, Python or Java. The rewritten app in this study is a mobile app, and IOanyT’s part in that kind of problem is narrower.
• IOanyT reads only the older technologies it names: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. It has no conversion tool and does not convert code by machine.
• IOanyT does not keep the old product running, supported or secure during the rewrite. The firm’s own team does, throughout.
• IOanyT does not move a firm’s customers, their installations or their data from old to new. The firm plans how its customers meet each module.
• IOanyT offers no design service.
• A specification and a matrix show what the old product does and that a new module matches it; they do not show that the old product was right. Reading the code can still miss a habit that lives outside the product.
• IOanyT does not say a staged rewrite is quicker, cheaper or free of faults. Old and new run side by side for a time, and the whole may take as long on the calendar as a single rewrite, or longer.
• This study does not say that IOanyT has done this work for a software firm. IOanyT has no published case of it, and does not say any approach would have prevented what happened to the rewritten app.

About this study: IOanyT did not work on this case. It is drawn from published findings, cited below.

10. Sources

Source	Used for
A technology news report, 2024	The old app, the rewritten app, the list of faults
A vendor’s case studies: insurance and property software	The two products, as their own accounts describe them
A software firm’s engineering article, December 2025	The stated limit of translating files without the code they depend on
A vendor’s article, December 2025	One seller’s conversion experiment
A tool maker’s developer survey, October 2025	Testing among developers who work in PHP
A developer’s post, November 2025	Changes without tests
A vendor’s survey of about 500 US IT professionals, 2025	Reasons for not modernising

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We take the specification from the old product and rebuild one module at a time, so a rewrite never rests on memory or on one launch.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →