From the Desktop to the Browser

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 whose product began as a program installed on a desktop computer, or whose screens look and work as they did years ago: one maker of agronomy software as its own account describes it, set beside published support positions and surveys
Size band	The firm in the record: mid-size by the research’s estimate, with hundreds of locations. Our reader: a small or mid-size software firm whose desktop product has sold for ten years or more
Region	The firm: North America. The surveys: the US and developers worldwide
The decision at stake	Whether, and how, to take a desktop product to the web while still selling and supporting it
The public outcome	The firm’s account states that its product had to work on the desktop and also away from the office, from the cloud: both places, not one in place of the other
Why it matters to a small or mid-size software firm	”Is there a web version?” stays a promise with no size until someone writes down what each screen does. Until then every plan looks like the largest one

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

“Our product has sold for fifteen years, as a program our customers install. Prospects ask for a web version in the first meeting, and for three years we have said it is on the roadmap. My engineers guess there are three hundred screens. Nobody has counted, and nobody has written down what any of them does. The one plan on my desk is to rebuild everything over two years and launch once. My oldest customers would be moved on one day, and they are the ones who check our figures.”

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

The firm is caught between a request it cannot size and a plan that would put every customer on a single date. Each year the web version stays a promise, the desktop screens gain more rules that nobody has written down.

3. What We Found

Method. We went through the public record on software products that began on the desktop: 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, the published end of life of one old framework for web screens, one large survey of developers, one survey of IT professionals, one survey of developers who work in PHP and one developer’s own account.

One product, as its own account describes it. This is from a case study published by a firm that sells a conversion tool. We use only the problem it describes, not what the firm did next, and we do not name it. The page is not dated.

What	What the account says
The firm	A maker of agronomy software with hundreds of locations
The product	A desktop product of more than a hundred thousand lines of VB6 code
The requirement	The product had to work on the desktop and also away from the office, from the cloud
What being desktop-only cost the firm, in customers or sales	Not in the account

What the makers have published. These are the makers’ own positions.

Technology	Published position
VB6, an old business language	The development tool has been unsupported since 8 April 2008. The part that runs VB6 programs is supported only for “serious regressions and critical security issues”, and the maker “strongly recommends that you replace your applications with modern technology”
AngularJS, a framework for web screens	End of life on 31 December 2021. In one large survey of developers in 2025, only about one in five of its users wanted to go on with it, the lowest of any web framework shown

In the same survey, 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, which does not mean it is unused.

How firms regard the change. In one survey of about 500 IT professionals in the US, run by a vendor and covering every sector, about four in ten named incompatibility with modern systems and tools among the top challenges of their old systems. Among reasons for not modernising, half said that their current system still works, more than four in ten named budget limits, nearly four in ten fear of disrupting operations and about a third concerns about moving data.

What there is to check a new screen against. In one survey of more than 1,700 developers who gave PHP 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.

Our reading of why a web version stays on the roadmap. These four are our reasoning from the record above. None is a finding of any source, and none is said of the firm above.

1. Nobody has written down what each screen does. So the job cannot be sized, and “a web version” stays a promise.
2. The only plan offered is to rebuild everything and launch once. It gives sales nothing for years and moves every customer, and every customer’s data, on one day.
3. New screens are drawn from how the old ones look. The rules, defaults and keys that lived in the old screen are lost.
4. Nobody compares new with old before customers do. So long-standing customers find the differences.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Keep the desktop product	Customers work at a desk, and few prospects ask for a browser	The answer to the next prospect is the same, and the screens stay unlisted	Right only as a pause with an end date
Rebuild everything as a web application before releasing any of it	The product is small and its customers will wait	Nothing to show until the end, everything learned on launch day, every customer moved on one date	We would advise against this for a large, old product that sells every day
Build web modules beside the desktop product, starting now	One part is clearly needed in a browser and is easy to separate	Modules built from memory, and a shared customer’s data with no plan for it	Right in direction, once the screens are written down and the data is planned
Write down every screen first, then rebuild module by module beside the desktop product	The product is large, old and much changed, and nobody holds the list	Costs money before anything reaches the web; desktop and web run side by side for a time	Our recommendation

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

Write down what every screen of the desktop product does: what it shows, what each button and key does and the rules behind it, confirmed by the firm’s own people. Decide, screen by screen, what is carried over, improved or dropped. Then rebuild the product as a web application one module at a time, beside the desktop product, which keeps selling. Agree at scoping how the desktop product and each web module work on the same customer’s data. Check each rebuilt screen against the old one, totals included, on real cases, and have someone from product rule on every difference before release.

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
Screens written down	A guess at the number	Every screen listed with what it does, confirmed by the firm’s own people	The specification
Screens with a decision	None	Each marked carry over, improve or drop, by someone from product	The specification and the staged plan
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, every difference ruled on 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
Functions dropped on purpose	Discovered by customers	Listed, and told to customers before they find out	The traceability matrix

7. How IOanyT Would Work

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 study 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.
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, each rebuilt screen checked against the old one, totals included. 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 every screen of the product does, set out screen by screen, confirmed by the firm’s 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 marked as dropped by the firm’s decision.
• The code: the rebuilt web 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 has no conversion tool and does not convert an interface by machine. It rebuilds.
• What IOanyT builds runs in a web browser. It does not build desktop programs or mobile apps.
• IOanyT publishes no design or user-research service. Who designs the new screens is agreed at the start, and nothing here says the new screens will be easier to use or preferred.
• IOanyT does not move the copies of a product installed at a firm’s customers’ sites, or their data. The firm plans and carries out that move.
• IOanyT does not host or run the web version, and does not keep the desktop product running or supported during the work. The firm’s own team does.
• IOanyT reads only the older technologies it names: VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.
• A web application needs a connection. Whether a firm’s customers have one where they work was not researched, and this study does not say a web application works without one.
• Desktop and web run side by side for a time, and the whole may take as long as a single rebuild, or longer.
• A check shows that a rebuilt screen gives what the old one gave. It does not show that the old one was right.
• This study does not say that customers will prefer a web version, that sales will follow, or that IOanyT has done this work for a software firm. IOanyT has no published case of it.

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

10. Sources

Source	Used for
A vendor’s case study: agronomy software	The product firm, as its own account describes it
Microsoft, VB6 support statement	VB6 support positions and the maker’s recommendation
endoflife.date: AngularJS	AngularJS end of life
A large developer survey, 2025	AngularJS users who want to go on; Visual Basic (.NET) use
A vendor’s survey of about 500 US IT professionals, 2025	Incompatibility; why systems stay
A tool maker’s developer survey, October 2025	Developers who do not write tests
A developer’s post, November 2025	Changing old code without tests

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, so a web version has a size before anyone is asked to approve it.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →