Strongly Recommends That You Replace

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 is built on a language or framework its maker no longer supports: three makers of business software (insurance, agronomy, property) as the record describes them, set beside published support dates and surveys of developers
Size band	The firms in the record: one small, one mid-size and one larger, by the research’s estimate. Our reader: a small or mid-size software firm whose product has sold for ten years or more
Region	The three firms: the UK, the US and South Africa. The rules: India and the EU
The decision at stake	Whether, and how, to move a product off a technology that has ended, while still selling and supporting it
The public outcome	The maker of the old business language “strongly recommends that you replace your applications with modern technology”. The three firms’ accounts describe products of 137,000 to about 9.5 million lines of code on that language, one of them with “a limited development team”
Why it matters to a small or mid-size software firm	Buyers in some regulated sectors are being asked to track which components the software they buy stands on, and when support ends. A firm that cannot size its move cannot answer them

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

“Our product has sold for twelve years. The framework under it reached its end years ago, and we all know it. A prospect’s questionnaire asked about it last month, and I wrote that a move is planned. I do not know what the move involves. My engineers say six months, or two years, depending on what the product leans on, and nobody has ever listed that. The one plan anybody has put in front of me is to stop selling new features and rewrite the whole thing. I cannot do that to my customers.”

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

The firm is caught between a technology it must leave and a plan to leave it that would stop the business. Staying looks cheaper every year, and each year adds more to what the eventual move must carry.

3. What We Found

Method. We went through the public record on software products built on technology with no supported version left: the support statements their makers publish, three product firms’ own accounts in case studies published by a vendor, two large surveys (one of developers, one of IT professionals), one seller’s experiment in converting old code with AI tools, one large software firm’s engineering account, and the rules some buyers in India, and some software makers in the EU, now work under.

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

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
PHP, a web language	7.4 ended on 28 November 2022 and 8.1 on 31 December 2025; 8.2 gets security fixes only until 31 December 2026

Three products, as their own accounts describe them. These are from case studies published by a firm that sells a conversion tool. We use only the problem each describes, not what the firms did next, and do not name them. None of the pages is dated.

Product	What the account says
Insurance software (UK; an older case, about 2009 by the versions named)	VB6, “about 9.5 million lines of source code”, on “Windows 2003 with SQL Server 2000”, with “almost 50,000 users in over 50 countries”. “A manual rewrite would have been harder and would have entailed a much higher risk.”
Agronomy software (US; “over 450 locations across 27 states”)	“137,000 lines of VB6 code”. “The VB6 app was required to work on desktop platforms as well as out in the field in a cloud-based environment.”
Property software (South Africa; an older case, about 2006)	“over 600,000 lines of code”, with “a limited development team”

The use goes on after the date. The AngularJS package was downloaded 2,403,742 times in the month to 1 October 2026. In one large survey of developers in 2025, 7.2% had used AngularJS, and only 21.9% of them wanted to go on with it, the lowest of any web framework shown. In one survey of 504 IT professionals in the US, run by a vendor and covering every sector, 32% named lack of vendor support or updates among the top challenges of their old systems, and half gave “the current system still works” as a reason for not modernising.

Converting by machine still needs checking. One seller of paid support for AngularJS reported that in its own experiment with AI tools “Actual code migration varied between 50% and 75% success”. One large software firm found that translating individual files without the code they depend on gave “partial rewrites that appeared syntactically correct but deviated from expected runtime behavior”.

What some buyers, and some software makers, now work under. In India, SEBI’s cybersecurity framework of 20 August 2024 says that the critical software of the firms it regulates “shall be replaced before” it reaches end of support, and that those firms “shall obtain SBOMs” (lists of the components in a product, with their versions) for new critical software and SaaS they buy. CERT-In’s guidelines of July 2025 recommend that government, public-sector and essential-services buyers ask for such lists, including each component’s “End-of-Life (EOL) Date”. In the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847 of 23 October 2024) sets obligations for the “manufacturer” of “a software or hardware product and its remote data processing solutions” (Articles 3(1), 3(13), 13 and 14). Its Article 14, on manufacturers’ reporting obligations, has applied since 11 September 2026; the Regulation as a whole applies from 11 December 2027 (Article 71(2)). SEBI’s framework is addressed to the firms SEBI regulates; the Act’s Articles 13 and 14 to manufacturers.

Our reading of why a product stays on an ended technology. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has listed what the product needs from the old technology. So the move can only be given as a wide range, and a wide range cannot be budgeted.
2. Where no newer version exists, the only plan offered is a full rewrite. It freezes the roadmap and puts everything on one date.
3. A rewrite is specified from memory. Nobody holds a record of everything the old product does, so features are lost and customers find them.
4. After an upgrade, nobody can show the product still behaves as it did. There are few tests, so each upgrade is a risk, and the next is put off.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Stay where you are for now	Support ended recently, and no buyer is asking	The answer to the next questionnaire is the same, and the list stays unwritten	Right only as a pause with an end date
Upgrade in place, by trying	A newer supported version exists and the product is small	Each try ends in “it depends”, and nothing tells the team what the upgrade changed	Right for the parts that can move, once there is a way to check them
Stop and rewrite the whole product	The product is small and customers will wait	Years with nothing new for customers, and a second product built from memory	We would advise against this for a large, old product that sells every day
Read what each part needs first; rebuild only the parts with no supported version, one module at a time; give the team a way to check upgrades of the rest	The product is large, old and much changed, and nobody holds the list	Costs money before anything moves; old and new run side by side for a time	Our recommendation

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

Read what each part of the product needs from the language, framework and tools beneath it, and give each part a verdict: moves as it is, needs a small change, or must be rebuilt. Where a newer supported version exists, the firm’s own engineers carry out the upgrade, with a written record and tests that show whether the product still behaves as it did. Where none exists, rebuild those parts one module at a time on a current stack, beside the old product, each checked function by function against the record, and paid for by milestone once accepted. The product keeps selling throughout.

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
Parts with a known support date for what they stand on	Known for the framework, not for each part	Every part listed with what it needs and its support dates	The map of the product as it stands
Parts with a verdict	None	Each part marked: moves as it is, small change, or rebuild	The specification and the risk register
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 rebuilt	Not recorded	Each function linked to its replacement	The traceability matrix
How an upgrade is judged ready	”It seems fine”	The tests pass, and any difference is explained before release	The record of each upgrade
New features for customers during the move	Stopped for a rewrite	Continuing on the parts not being rebuilt	The staged plan

7. How IOanyT Would Work

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 study 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 technology 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.
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, rebuilding it on React, Node.js, Python or Java. We never do a single cutover. A traceability matrix links every old function to its replacement. Where a part can be upgraded, we add tests that record what it 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.

8. What the Client Would Own

• The map and the specification: what each part of the product does and what it needs from the technology beneath it, with a verdict for each part, confirmed by the firm’s own people.
• The risk register: what the assessment found, listed before any price is set.
• The tests: for the parts an upgrade touches, a record of what the product does today, handed to the firm’s engineers.
• The traceability matrix: for every module IOanyT rebuilds, every old function linked to its replacement.
• The code: the rebuilt 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 does not upgrade a product from one version of its language, framework or runtime to the next, and does not apply security fixes. The firm’s own engineers do.
• Until a part has moved, it is exactly as unsupported as before. Nothing in this approach makes a product secure, or safe from attack, in the meantime.
• IOanyT has no conversion tool and does not convert code by machine. It rebuilds, on React, Node.js, Python or Java. It does not build mobile apps or desktop programs.
• IOanyT does not run, host or support the product, keep the old product running during a rebuild, or support the firm’s customers.
• IOanyT does not move the copies of a product installed at customers’ sites, or their data. The firm plans and carries out that move.
• IOanyT gives no legal or compliance advice. What SEBI’s framework, CERT-In’s guidelines or the EU Cyber Resilience Act ask of a particular firm is for its own advisers; this study does not say, and does not say that any work makes a firm or its buyer compliant.
• A record of what the product does shows what it does, not whether it is right. Tests show that a product behaves as it did; they do not prove it correct.
• This study does not say 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
Microsoft, VB6 support statement	VB6 support dates and the maker’s recommendation
endoflife.date: AngularJS and PHP	Published end dates
A vendor’s case studies: insurance, agronomy and property software	The three products, as their own accounts describe them
Public download counts	AngularJS downloads in the month to 1 October 2026
A large developer survey, 2025	AngularJS use and wish to continue
A vendor’s survey of 504 US IT professionals, August 2025	Lack of vendor support; why systems stay
A vendor’s article, December 2025	One seller’s conversion experiment
A software firm’s engineering article, December 2025	The stated limit of translating files one by one
SEBI cybersecurity framework, 20 August 2024	Replacing critical software before end of support; component lists
CERT-In guidelines, version 2.0, 9 July 2025	The recommendation to buyers; the end-of-life field
Regulation (EU) 2024/2847 (Cyber Resilience Act), OJ L, 20.11.2024	Dates (Article 71(2)); definitions (Article 3); obligations of manufacturers (Articles 13 and 14)

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 the product needs, so the move 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 →