Software Firms Know Their Product Stands on Unsupported Technology. What They Lack Is a List.

A large prospect has sent its security questionnaire. One question stands out: is every component of your product supported by its maker?

The honest answer is no. The framework the product was built on reached its end of life some years ago.

So the founder asks the head of engineering the obvious question. How long would it take to move? The head of engineering thinks for a while. Six months, perhaps. Or two years. It depends on what the product needs from the old framework, and nobody has ever listed that.

What We Found

For this article we went through the public record on the technologies that software products of the last twenty years were built on: the support dates their makers publish, one large survey of developers, one public download counter and one survey of IT professionals on why old systems stay.

Four findings stand out.

The end dates are published, and many have passed. The tool used to write programs in VB6, an old business language, 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”. AngularJS, a framework for web screens (a ready-made base that a product is built on), reached its end of life on 31 December 2021. Among the versions of PHP, a web language, 7.4 reached its end on 28 November 2022 and 8.1 on 31 December 2025, and 8.2 gets security fixes only until 31 December 2026.

The use goes on after the date. The AngularJS package was still downloaded 2,403,742 times in the month to 1 October 2026, nearly five years after its end. In one large survey of developers in 2025, about 7% said they had used AngularJS, and only about one in five of them wanted to go on with it, the lowest of any web framework the survey showed. A download is not a product in use, and a survey of developers is not a survey of software firms. Both are signs that products still stand on it.

The difficulty is named, and left 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, about a third named a lack of support or updates from vendors among the top challenges of their old systems. Half said that their current system still works was a reason for not modernising.

The move is not one decision but many. Each newer version of a language or framework removes some old features and changes how others behave. Where no newer version exists, the only way off is to build again on something else. Inside one product, both can be true at once: most parts would move with little trouble, and a few lean on exactly what has gone. We found no public record that lists which is which for any product. That list has to be read from the product’s own code.

Our reading is that software firms do not stay on unsupported technology because they do not know. They stay because the question “how long would it take to move?” has no answer until someone reads what each part of the product needs, and nobody is given the time to read it.

What Waits While the Move Has No Size

An unsupported technology is usually discussed as a security matter. Our reading is that it is also a planning matter, and that is the side this article is about.

The first cost is the answer that wears thin. “A move is planned” works once with a customer or an investor. The second time, they ask for the date, and there is none.

The second cost is the roadmap. Features that need something newer are marked “not possible on the old platform”, and the rest of the product is treated as frozen too, because nobody can say which parts the old technology really blocks.

The third is that the estimate never improves. A range of “six months to two years” cannot be budgeted, so the move is deferred, and next year the range 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
Stay where you are for now	Support ended recently, and no customer is asking	No security fixes arrive while you wait, the answer to the next questionnaire is the same, and the list stays unwritten
Upgrade in place, with your own team, by trying	A newer supported version exists and the product is small	Each try ends in “it depends”, and a failed try teaches the team to stop
Stop and rewrite the whole product	The product is small and the firm can pause new work	Years with nothing new for customers, and a second product that must match the first
Read what each part needs first, then decide part by part	The product is large, old and much changed, and nobody holds the list	It costs money before anything moves, and the list may be longer than anyone expected

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
Parts of the product with a known support date for what they stand on	Known for the framework, not for each part	Every part listed with the language, framework and tools it needs, and their support dates	The map of the product as it stands
Parts with a verdict	None	Each part marked: moves as it is, needs a small change, or must be rebuilt	The specification and the risk register
The answer to “how long would it take to move?”	A range from memory	A staged plan with a fixed quote for each stage	The staged plan
Modules still on technology with no supported version	Not counted	Counted, and falling at every stage	Reported at every review
Old functions matched to new ones, where a module is rebuilt	Not recorded	Each function linked to its replacement	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

1. We listen: a free Reliability Review. A first conversation about your product, what it stands on and the questions you are being asked 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 article 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 assessment records what each part needs from the language, framework and tools beneath it, with a verdict for each part. 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. Where a part has no supported version to move to, 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. Each module has a traceability matrix. Where a newer supported version exists, we add tests that record what the product does today and hand them to your engineers, who carry out the upgrade. 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 do not upgrade a product from one version of its language, framework or runtime to the next, and we do not apply security fixes; your own engineers do. Until a part has moved, it is exactly as unsupported as before, and nothing we do makes it safe in the meantime. We have no conversion tool and do not convert code by machine; we rebuild. We do not build mobile apps or desktop programs, and we do not move the copies of a product installed at your customers’ sites, or their data. The older technologies we read include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP. We have no published case of this work for a software firm.

What changes for the business:

Role	What they gain
CEO	A question the firm could only answer with “we are looking into it” becomes a plan with a first step and a size, which can be shown to a customer or an investor.
CTO or CIO	A list of every place the product leans on the old technology, with a verdict for each part: moves as it is, needs a small change, or has to be rebuilt.
Head of product	Product can see which parts of the roadmap the old technology really blocks and which it does not, and stops treating the whole product as frozen.
CFO	The move has a size, so it can be budgeted against the cost of staying and is no longer an open-ended worry in every forecast.
CISO	The unsupported layers are named, with what stands on each, so the firm’s answer to a customer’s security question is exact and comes with a plan.

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 makers’ published support dates, two surveys of developers, a public download counter and a vendor’s survey of IT professionals.	Our assessment records what each part of your product needs from the technology beneath it, with a verdict for each part. Where no supported version exists, we rebuild one module at a time while the product keeps selling. We do not upgrade or patch the technology itself.

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 reading what each part of your product needs, because that is the list every estimate has been missing.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →