There Is No Newer Version to Move To. A Software Firm Does Not Have to Stop Selling to Leave.

The planning meeting has two slides.

The first says: rewrite the product. Stop new features, put the whole team on it, and come back in two years with the same product on a new technology. The second says: carry on, and hope the old tools keep working for a few more years.

The head of product asks what customers will get during the two years. Nothing new, is the answer. The founder asks what happens if the rewrite runs late. Nobody answers that one.

What We Found

For this article we went through the public record on software products built on a technology that has no supported version left: two product firms’ accounts in case studies published by a vendor, one seller’s own 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.

Three findings stand out.

The products are large, and the teams are not. One maker of insurance software described a product in VB6, an old business language, of “about 9.5 million lines of source code”, running on “Windows 2003 with SQL Server 2000”, with “almost 50,000 users in over 50 countries”. One small maker of property software had a VB6 product of “over 600,000 lines of code” and “a limited development team”. Both are older cases, from about 2009 and 2006, and both accounts were published by a firm that sells a conversion tool. We use only the problem they describe.

A rewrite is seen as the riskiest way out. The maker of insurance software said: “A manual rewrite would have been harder and would have entailed a much higher risk.” That is the firm’s own view of one route, not a finding about rewrites in general.

Converting by machine still needs people to check it. One seller of paid support for AngularJS, a framework for web screens whose end of life was 31 December 2021, reported its own experiment in converting AngularJS code with AI tools: “Actual code migration varied between 50% and 75% success”, and “nearly 100% of files were migrated with some issues”. The seller has an interest in the answer. One large software firm, writing about its own move of old code, found that translating individual files without the code they depend on gave “partial rewrites that appeared syntactically correct but deviated from expected runtime behavior”.

Our reading is that the choice is usually framed as “rewrite or stay”, and both are bad for a firm that sells its product every day. What the record suggests is narrower: most of a product’s risk sits in the parts that lean on what has ended, and whatever produces the new code, people have to check it against what the old code did.

What a Firm on an Ended Technology Cannot Do

While the product stands on a technology with no supported version, some buyers find it harder to say yes.

In India, SEBI’s cybersecurity framework for the firms it regulates (brokers, mutual funds, depositories, exchanges and others), issued by circular on 20 August 2024, says that “Hardware and software of critical systems shall be replaced before they reach End-of-Life/End-of-Support”, and allows “virtual patching” of “legacy systems for a maximum period of 6 months”. The same firms “shall obtain SBOMs” (a list of the components a product is built from, with their versions) “for any new critical systems software products/ Software-as-a-Service applications (SaaS) at the time of procurement”. The framework is addressed to the firms SEBI regulates.

CERT-In, India’s computer emergency response team, issued guidelines in July 2025 that recommend that “all the Government, Public Sector and Essential Services Organizations should include requirements for SBOM in all their software and solutions purchase/procurement”, and the minimum fields of that list include each component’s “End-of-Life (EOL) Date”. The guidelines present this as a recommendation.

In the EU, the Cyber Resilience Act (Regulation (EU) 2024/2847 of 23 October 2024) says it “shall apply from 11 December 2027”, and that its Article 14, on the reporting obligations of manufacturers, “shall apply from 11 September 2026” (Article 71(2)); those reporting obligations have applied since that date. Its Articles 13 and 14 set out the obligations of the “manufacturer”, which it defines as a person who “develops or manufactures products with digital elements … and markets them under its name or trademark” (Article 3(13)); a “product with digital elements” is “a software or hardware product and its remote data processing solutions” (Article 3(1)). Its recitals say that “cloud services designed and developed outside the responsibility of a manufacturer of a product with digital elements do not fall within the scope of this Regulation”, and that another law, Directive (EU) 2022/2555, “applies to cloud computing services and cloud service models, such as Software as a Service (SaaS)” (recital 12). We do not say where any firm stands under the Act.

None of these rules names an old technology or refuses a vendor. Our reading is that a buyer who must list each component’s version and end of support will ask its vendor the same question, and a vendor on an ended technology has a hard answer to give.

This is our reading of the evidence. It is not a measured market figure, and it is not legal advice.

Four Ways Off an Ended Technology, Weighed

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

Option	When it fits	What it risks
Carry on, and keep the old tools working	The product has few years left, or its buyers do not ask	Each year the answer to a buyer is harder, and the tools themselves may stop working
Stop and rewrite the whole product	The product is small and customers will wait	Years with nothing new for customers, and a second product that must match the first on the day it replaces it
Convert the code by machine	A tool exists for the technology and the firm can check the result	Code that looks right and behaves differently, found by customers if nobody checks it
Write down what the product does, then rebuild it one module at a time	The product is large, sells every day, and nobody holds a full list of what it does	Old and new run side by side for a time, and the calendar is longer than one big rewrite

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
What the product does	Known to the engineers who wrote it	Every function written down in plain words, confirmed by your own people	The specification
New features for customers during the move	Stopped for the length of a rewrite	Continuing on the parts not being rebuilt	The staged plan, reviewed at each stage
Modules still on the ended technology	All of them	Falling at every stage, with a date for each	Reported at every review
Old functions matched to new ones	Not recorded	Each function of a rebuilt module linked to its replacement	The traceability matrix
The answer to a buyer who asks about components and support dates	”A move is planned”	A staged plan naming the parts and their order	The staged plan

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 technology it stands on and the rewrite 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.
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 marks which parts lean on what has ended. 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 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. 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 a price. Old and new run side by side for a time, and the same customers use both, so how they work together is part of the engineering of each stage. The work takes longer on the calendar than a rewrite promises. We do not keep the old product running or secure it in the meantime; your own team does. We do not convert code by machine. We do not build mobile apps or desktop programs: what we rebuild runs in a web browser. We do not move the copies of your product installed at your customers’ sites, or their data. We give no legal advice and do not say what any rule requires of your firm or makes it compliant. 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	The firm leaves a technology that has ended without stopping sales or staking the company on one rewrite.
CTO or CIO	One module at a time moves to a current stack, each checked against the old one, so the team is never years into a second product with nothing in use.
Head of product	The roadmap keeps moving, and no customer loses a feature unless someone chose to drop it.
CFO	Money is released module by module, each tied to a module the firm accepts, with no long spend before anything reaches a customer.
CISO	The share of the product that stands on software nobody fixes shrinks with each module, and can be reported as it shrinks.

The cases in this article, and what IOanyT does about that kind of problem:

The case	What IOanyT does
SEBI’s framework of 20 August 2024 says regulated firms’ critical software “shall be replaced before” it reaches end of support, and that they “shall obtain SBOMs” (lists of the components) for new critical software and SaaS they buy.	We give no compliance advice. For a software firm whose buyers ask, we write down what each part of its product stands on and rebuild the parts on ended technology one module at a time.
CERT-In’s guidelines of July 2025 recommend that government, public-sector and essential-services buyers ask for those lists, including each component’s end-of-life date.	The same limit applies. The assessment’s map records what your product stands on, which is what such a list asks for.
The EU’s Cyber Resilience Act (Regulation (EU) 2024/2847) sets obligations for manufacturers of “products with digital elements” (Articles 13 and 14). Article 14, on reporting, has applied since 11 September 2026; the Regulation as a whole applies from 11 December 2027 (Article 71(2)).	We do not say what the Act requires of your firm. We rebuild your own product’s code one module at a time; your advisers decide what the Act asks.

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 firm can leave an ended technology without stopping the product it sells.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →