You Were Told a Web Version Means Rebuilding the Whole Product First. It Can Reach the Web One Module at a Time.
A web version of a desktop product is usually planned as one large rebuild with one launch. Here is what that costs a software firm while it waits, the four ways forward, weighed, and the one we would recommend.
The plan for the web version is on one page. Twenty-four months. All three hundred screens. One launch.
The head of sales reads it and asks what there will be to show a prospect next quarter. Nothing. And the quarter after? Nothing then either. The web version will be shown when it is finished.
The head of product asks a different question. On launch day, will every customer have to move at once? Yes. Nobody wants to support the old product and the new one together.
The paradox: The firm needs a web version to answer new buyers, and the plan for one puts its existing customers on a single date.
What We Found
For this article we went through the public record on software products that must reach the web while they go on selling: one product firm’s own account in a case study published by a vendor, the support positions published for one old business language and one old framework for web screens, one large survey of developers and one survey of IT professionals on why old systems stay.
Three findings stand out.
The requirement was both places at once, not one in place of the other. One maker of agronomy software had a desktop product of “137,000 lines of VB6 code”, VB6 being an old business language, in use at “over 450 locations across 27 states”. Its account says: “The VB6 app was required to work on desktop platforms as well as out in the field in a cloud-based environment.” The requirement did not retire the desktop; it added a second place. The account is undated, it was published by a firm that sells a conversion tool, and we use only the problem. We do not name the firm,.
The ground is ending under dated screens as well as desktop ones. The tool used to write programs in VB6 has been unsupported by its maker since 8 April 2008, and the maker “strongly recommends that you replace your applications with modern technology”. AngularJS, a framework for web screens (a ready-made base that screens are built on), reached its end of life on 31 December 2021. In one large survey of developers in 2025, only 21.9% of those who had used it wanted to go on with it, the lowest of any web framework the survey showed.
The reasons firms hold back are the ones a single launch makes worse. In one survey of 504 IT professionals in the US, run by a firm that sells software services and not about software firms, 44% named budget limitations among their reasons for not modernising, 38% “fear of disrupting operations” and 35% data migration concerns. Among the top challenges of their old systems, 41% named “incompatibility with modern systems or tools”.
Our reading is that the choice is usually framed as “rebuild everything, then launch” or “stay on the desktop”, and both are hard for a firm that sells its product every day. A single launch asks for the whole budget before anything is used, disrupts every customer on one day and moves everyone’s data at once: the three things the survey’s respondents fear most. The record suggests a narrower need: some of the product in a new place, soon, while the rest carries on.
What our review does not show: The product firm is known only from one vendor’s undated case study, and we use none of what it did next. The surveys are about developers and IT professionals in general, not about software firms. We found no figure for what a web version costs or how long one takes, no case of a software firm that lost customers or sales for want of one, and nothing on how customers take to a web version. Whether a web application can be used where there is no connection was not researched, and we say nothing about it.
What a Desktop-Only Product Cannot Do While It Waits
While the web version is a two-year plan, the firm has three things it cannot do.
It cannot show anything new. For the length of the rebuild, every demonstration uses the same desktop screens, and every answer to “does it run in a browser?” is the same.
It cannot learn. No customer uses a single new screen until all of them exist, so whatever the new screens get wrong is found on launch day, by everyone at once.
It cannot let customers choose. On launch day every customer moves, whether they asked for a browser or have used the same desktop screens for a decade.
The gap we see: a firm that can take one part of its product to the web while the desktop product keeps selling has something to show after the first stage, learns from real use before the rest is built, and does not put every customer on one date. The opportunity is to reach new buyers and keep the old ones at the same time, one module at a time. The hard part is two forms of one product on the same customer’s data, which has to be agreed before the first module is built.
This is our reading of the evidence. It is not a measured market figure.
Four Ways to Reach the Web, Weighed
There are four real options. Each one is right for somebody.
| Option | When it fits | What it risks |
|---|---|---|
| Keep the desktop product, and refresh how it looks | Customers work at a desk, and prospects are not asking for a browser | It looks newer and is still a program to install, so it answers a question nobody asked |
| 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, and every customer moved on one date |
| 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 from memory, without a record of what the old screens do, and a shared customer’s data with no plan for it |
| Write down what every screen does first, then rebuild module by module | The product is large, sells every day, and nobody holds a full list of what it does | Desktop and web run side by side for a time, and the calendar may be as long as a single rebuild, or longer |
Our recommendation: write down what every screen does first, from the product’s own code, and have your own people confirm it. Then rebuild it as a web application one module at a time, beside the desktop product, so that customers keep using it while each part moves. Agree at scoping how the desktop product and each web module work on the same customer’s data, and check each rebuilt screen against the old one, totals included, before it is released. We do not convert screens by machine, design them, or build desktop programs or mobile apps.
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 |
|---|---|---|---|
| Modules available on the web | None, until a launch | Rising at every stage, each in use once accepted, 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 |
| Screens written down | A guess at the number | Every screen listed with what it does, confirmed by your own people | The specification |
| New features for customers during the work | Frozen for the length of a rebuild | Continuing on the parts not being rebuilt | The staged plan |
| Old functions matched to new ones | Not recorded | Each function of a rebuilt module linked to its replacement, or marked as dropped by decision | The traceability matrix |
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
- We listen: a free Reliability Review. A first conversation about your product, the web version you have been asked for and the plan that keeps being proposed. 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.
- 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.
- 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, so that the product can be divided into modules that make sense on the web. 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.
- 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.
- 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 a price. The desktop product and the web modules run side by side for a time, and the same customers may use both, so how they work on the same data is agreed at scoping and is part of the engineering of each stage. The whole may take as long on the calendar as a single rebuild, or longer. 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 publish no design or user-research service, so who designs the new screens is agreed at the start. 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 customers will prefer the web version or that sales will follow. A browser needs a connection, and whether your customers have one where they work is for you to know. We have no published case of this work for a software firm.
What changes for the business:
| Role | What they gain |
|---|---|
| CEO | The firm can reach buyers who will not install software, without stopping sales of the product it has. |
| CTO or CIO | One module at a time moves to a web application on a current stack, each in use when accepted, with the desktop product still doing the rest. |
| Head of product | The part customers ask for most can come first, and existing customers are not made to change everything in one day. |
| CFO | Money is released module by module, each milestone tied to a module the firm accepts, while the desktop product goes on earning. |
| Head of sales and marketing | Sales has a web module to show after the first stage, and more to say than “it is on the roadmap” when a prospect asks whether the product runs in a browser. |
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, published support positions, a survey of developers and a vendor’s survey of IT professionals. | We write down what every screen of your desktop product does, then rebuild it as a web application one module at a time while the desktop product keeps selling. We do not convert by machine, design screens, host the result or move your customers’ installations or data. |
IOanyT is a consultancy with its own engineering team: we study the problem, recommend, and prove it by building only what you approve. We rebuild one module at a time, so a desktop product can reach the web without putting every customer on one date.