The New Screens Look Better, and Your Oldest Customer Says the Totals Are Wrong. A Benchmark for Every Rebuilt Screen.

The new quotation screen is shown to a customer who has used the product for fourteen years. It is cleaner, and quicker to read. The customer is polite about it.

Then the customer enters a real quotation, the same one they made last week on the old screen. The total is different. Not by much. Enough.

It takes most of a week to find out why. The old screen rounded each line before adding them up. The new one adds first and rounds at the end. Nobody chose that. Nobody knew the old screen did it. The customer now wonders what else has changed.

What We Found

For this article we went through the public record on how old software is checked when it is rebuilt or changed: one survey of developers who work in PHP, one developer’s own account of old code, one survey of IT professionals on why old systems stay, and one product firm’s own account in a case study published by a vendor.

Three findings stand out.

Many products have nothing to check a new screen against. In one survey of more than 1,700 developers who gave PHP, a widely used web language, as their main 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. Where there are no tests, the only record of what a screen does is the screen.

Fear of disruption is a reason to leave old systems alone. In one survey of about 500 IT professionals in the US, run by a firm that sells software services and not about software firms, nearly four in ten named fear of disrupting operations among their reasons for not modernising, and half said that their current system still works.

For a time, old and new answer the same customers. One maker of agronomy software, in a vendor’s undated case study, described a requirement that its VB6 product work on the desktop and also away from the office, from the cloud. VB6 is an old business language. We do not name the firm, and we use only the problem. Our reading is that while a product works in two places, a customer can see the same figure in both, and will notice if they differ.

Our reading is that most new screens do not change a product’s answers because the people building them are careless. They change them silently, in a rounding rule or a default that lived in the old screen and nowhere else, because there was nothing to check the new screen against. “It should be the same” is the best anyone can say.

What Waits While New Screens Are Checked by Eye

A firm that cannot check a rebuilt screen against the old one does not stop rebuilding. It rebuilds with more held breath, and its customers do the checking.

The first cost is trust. Each difference a long-standing customer finds costs a little of their confidence in every figure, not only the one that changed.

The second cost is the support desk. What changed is found one ticket at a time, and each ticket needs someone who knows how the old screen behaved.

The third is that nobody can tell an improvement from an accident. With no record of what the old screen did, every difference has to be argued about.

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

Four Ways to Check a Rebuilt Screen, Weighed

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

Option	When it fits	What it risks
Review each new screen for how it looks	The screen shows information and works nothing out	The look was never the risk; a rule in the old screen is lost without anyone seeing it
Release, and fix what customers report	Customers are few, close and forgiving	Differences reach customers first, and support pays for the testing
Ask long-standing customers to try every screen before release	A few customers are willing and have the time	Their goodwill is spent on finding faults, and what they do not try is not checked
Write down what each old screen does, then run the same real cases through old and new before release	The product is large and old, and its customers rely on its figures	It takes time before a screen can be shown, and someone must rule on every difference

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
Screens written down	Known to the people who use them most	Every screen listed with what it shows, what each button and key does and the rules behind it, confirmed by your own people	The specification
Rebuilt screens checked against the old screens’ totals	”It should be the same”	Every rebuilt screen run on the same real cases as the old one, totals included, before release	The traceability matrix, shown against the specification
Differences between old and new	Found by customers	Each one ruled on before release: an improvement someone chose, or a fault to fix	The record of each module’s acceptance
Functions dropped on purpose	Discovered by customers	Listed, and told to customers before they find out	The traceability matrix
Modules available on the web	None	Rising at every stage, each one checked before release	Reported at every review
Desktop and web on the same customer’s data	Not planned	Handled as agreed at scoping, for every module before it is released	The staged plan, reviewed at every stage

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 screens being rebuilt and what your customers have found so far. 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 desktop product’s own code, and the specification records the rules behind each screen as well as its fields. 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 each module is rebuilt as part of a web application on React, Node.js, Python or Java, and each rebuilt screen is checked against the old one, totals included, before you accept it. 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. A check shows that a rebuilt screen gives what the old one gave. It does not show that the old one was right, and it will carry an old mistake across unless someone rules on it. It covers the cases that were gathered, and a habit such as a keystroke has to be noticed by a person before it can be checked at all. We publish no design or user-research service: who designs the new screens is agreed at the start, and we do not say whether they are easier to use or whether customers will prefer them. We have no conversion tool and do not convert an interface by machine; we rebuild. We do not build desktop programs or mobile apps: what we build runs in a web browser. We do not move the copies of your product installed at your customers’ sites, or their data. We do not host the web version, and we do not keep the desktop product running; your own team does. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We do not say that sales will follow or that a web application works where there is no connection. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	Long-standing customers can move to the web version without losing trust in its figures.
CTO or CIO	Each new screen is matched against the old one, function by function, and a difference is found before a customer finds it.
Head of product	What changed on a screen changed because product chose it, and what was dropped was dropped on purpose.
CFO	Differences nobody intended are found before release, and not paid for afterwards in support time and corrections.
Head of sales and marketing	Sales can tell an existing customer that the web version gives the same answers as the one they trust, and say how that was checked.

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 a survey of developers, one developer’s account, a vendor’s survey of IT professionals and one product firm’s account in a vendor’s case study, which we do not name.	We write down what each old screen does and check each rebuilt screen against it, totals included, before you accept the module. We do not design the screens, judge whether they will be preferred, or keep the desktop product running.

IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We check every rebuilt screen against the old one, so “it should be the same” can become “it gave the same answers”.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →