"Is There a Web Version?" Has Been "On the Roadmap" for Years. What the Firm Lacks Is a List of Its Screens.

The demonstration goes well. The prospect likes the product, and says so. Then comes the question the sales lead has heard in every meeting this year. Is there a web version?

It is on the roadmap. The sales lead has said that for three years.

Afterwards the founder asks engineering, once more, how big the job would be. The answer has not changed either. It depends how many screens there are, and what each one does. Somebody guesses three hundred. Nobody has ever counted, and nobody has written down what a single one of them does.

What We Found

For this article we went through the public record on software products that began as programs installed on a desktop computer: one product firm’s own account in a case study published by a vendor, the support statement published by the maker of one old business language, one large survey of developers and one survey of IT professionals on why old systems stay.

Four findings stand out.

The requirement is on record, and the product behind it is not small. One maker of agronomy software, with hundreds of locations, had a desktop product of more than a hundred thousand lines of VB6 code, VB6 being an old business language. The account states the requirement plainly: the product had to work on the desktop and also away from the office, from the cloud. The desktop did not go away; the product had to work in both places. The account is undated, it was published by a firm that sells a conversion tool, and we use only the problem it describes. We do not name the firm, and the account does not say who set the requirement or why.

The ground under many desktop products has ended. The tool used to write programs in VB6 has been unsupported by its maker since 8 April 2008. The part that runs VB6 programs is still supported, but only for “serious regressions and critical security issues”, and the maker “strongly recommends that you replace your applications with modern technology”.

Few developers list the language at all. In one large survey of developers in 2025, Visual Basic (.NET), the later form of the language, was used by about 4% of respondents and wanted by about 2%. VB6 itself is not listed. “Not listed” does not mean unused.

The difficulty is named, and the old system stays. In one survey of about 500 IT professionals in the US, run by a firm that sells software services and not about software firms, about four in ten named incompatibility with modern systems and tools among the top challenges of their old systems. Half said that their current system still works was a reason for not modernising, and more than four in ten named budget limits.

Our reading is that software firms do not stay desktop-only because they have not heard the request. They stay because “a web version” has no size. A desktop product cannot be made into a web one by changing how it looks: the screens have to be built again, and to build a screen again someone has to know what it does.

What Waits While the Web Version Has No Size

A desktop-only product is usually discussed as a matter of appearance. Our reading is that it is first a planning matter.

The first cost is the answer that wears thin. “It is on the roadmap” works once with a prospect. The second time, they ask what it will cover and when, and nobody in the firm can say.

The second cost is the shortcut. When the real job cannot be sized, someone proposes a new appearance for the old screens. It looks newer, and it is still a program that has to be installed.

The third is that the estimate never improves. “About three hundred screens” cannot be priced, so the web version slips a year, and next year the guess is the same, a year older.

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

Four Ways Forward, Weighed

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

Option	When it fits	What it risks
Keep the desktop product as it is	Customers are content, and few prospects ask for a browser	The answer to the next prospect is the same, and the screens stay unlisted
Rebuild everything as a web application before releasing any of it	The product is small and the firm can wait for the launch	Nothing new to show until the end, a second product rebuilt from memory, and every customer moved on one day
Build web modules beside the desktop product, starting now	One part of the product is clearly needed in a browser and is easy to separate	Modules built without a record of what the old screens do, and two forms of one product sharing the same customer’s data without a plan for it
Write down what every screen does first, then rebuild module by module	The product is large, old and much changed, and nobody holds the list	It costs money before anything reaches the web, and the list may be longer than anyone hoped

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	A guess at the number, and no record of what any one does	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
Screens with a decision	None	Each screen marked: carry over, improve or drop, by someone from product	The specification and the staged plan
Rebuilt screens checked against the old screens’ totals	Not done	Every rebuilt screen run on the same cases as the old one, with every difference explained before release	The traceability matrix, shown against the specification
Modules available on the web	None	Rising at every stage, with the desktop product still doing the rest	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 your customers use and the web version you keep being asked for. 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 is set out screen by screen: what each screen shows, what each button and key does, and the rules behind it. 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 desktop product keeps selling while each module is rebuilt as part of a web application 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. We have no conversion tool, and we 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 publish no design or user-research service, so who designs the new screens is agreed between us at the start, and we do not judge whether a screen will please your customers. We do not move the copies of your product installed at your customers’ sites, or their data; you plan and carry out that move. We do not host the web version, and we do not keep the desktop product running in the meantime; 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 your customers will prefer a web version, 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	”A web version” stops being a promise with no size, and becomes a piece of work the firm can see whole.
CTO or CIO	A written account of every screen: what it shows, what each button does and which rules sit behind it, so the web version is planned from the product and not from memory.
Head of product	Product can decide, screen by screen, what to carry over, what to improve and what to drop, with the list in hand.
CFO	The web version has a scope that can be priced in stages, and is no longer an open figure in every plan.
Head of sales and marketing	Sales can tell a prospect what the web version will cover first, and stop saying only that it is on the roadmap.

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 product firm’s account in a vendor’s case study, which we do not name, a maker’s published support statement, a survey of developers and a vendor’s survey of IT professionals.	Our assessment writes down what every screen of your desktop product does. We then rebuild it as a web application one module at a time while the desktop product keeps selling. We do not convert screens by machine, design them, or build desktop programs or mobile apps.

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 by writing down what every screen does, because that is the list every estimate of a web version has been missing.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →