Past the End Date

1. At a Glance

Issue study · From the public record. No organisation is named here, and IOanyT had no part in anything described. The “case” is the public record: the dates on which makers stop fixing the software beneath a manufacturer’s business, and one survey of what manufacturers report.

Organisation type	Manufacturers with their own applications (labels, weighbridge records, costing tools, reports) built beside a packaged ERP, on servers and databases with published end dates
Size band	The record describes products in general, not firms of a size. Our reader: a mid-size manufacturer whose applications were built in-house or by a partner
Region	The dates are global. The survey of incidents is of UK manufacturers; the survey of reasons is of US IT professionals. Nothing from India
The decision at stake	Whether to keep renewing paid cover and risk exceptions for old servers, databases and an ERP version, or to find out what holds them in place and deal with that
The public outcome	For Windows Server 2012 and 2012 R2, paid security updates ended on 13 October 2026. For SQL Server 2012, even the paid updates ended on 8 July 2025. For one widely used older ERP product, mainstream maintenance ended on 31 December 2025 for some versions, with no extension
Why it matters to a mid-size manufacturer	An old machine is usually held in place by the firm’s own applications that stand on it, which nobody has listed. While they are unlisted, the machine cannot be retired and the ERP move cannot be priced

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

“Every year the same line comes back on the risk register: one old server, one old database, exception accepted. Every year we try to upgrade and something stops: last time it was the label program, and the time before that a report nobody could find the code for. Now the ERP has an end date too, and the quotation for the move has a provisional sum for our own programs, because nobody can say how many there are. I am not short of a reason to move. I am short of a list of what we would break.”

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

The firm is caught between dates it cannot change and machines it cannot touch. Each failed attempt makes the next one harder to approve, and each year of paid cover or accepted risk ends with the same question.

3. What We Found

Method. We went through the public record on the software beneath a manufacturer’s own applications: the makers’ published support dates for two server operating systems, two databases and one programming tool, one vendor’s article on the maintenance dates of one older ERP product, one news report of a survey of UK manufacturers, and one survey of US IT professionals on why firms do not replace old systems.

The dates beneath the business. These are published by the makers and describe the products in general. Which of them manufacturers run was not part of our research.

Product	Public record
Windows Server 2012 and 2012 R2	Paid security updates ended on 13 October 2026
SQL Server 2012	Extended support ended on 12 July 2022; paid updates ended on 8 July 2025
SQL Server 2016	Extended support ended on 14 July 2026; paid updates available to 17 July 2029
VB6, a tool some in-house applications were written in	The development tool has been unsupported since 8 April 2008; its maker “strongly recommends that you replace your applications with modern technology”. The runtime is still supported, in a limited way, on current Windows, so VB6 programs have not stopped working
One widely used older packaged ERP product	Mainstream maintenance ended on 31 December 2025 for some versions, with no extension, and ends on 31 December 2027 for others, with a paid extension to 31 December 2030. The dates are the maker’s; our source is a firm that sells support for the product

What manufacturers report. In one survey of UK manufacturers by an industry body, almost a third said they had a cyber incident over the past year. Of those affected, about three in ten reported reduced production capacity or operational delays, and a similar, separate share reported late deliveries to customers. Only about half have a formal incident response plan. The survey does not say how many of these incidents came through old or unsupported systems. This study suggests no number, and does not say that unsupported software caused any incident.

Why firms do not start. In one survey of about 500 IT professionals in the US, run by a firm that sells software services, half gave the fact that the current system still works as a reason for delaying the replacement of old systems, more than four in ten named budget limitations, more than a third fear of disrupting operations and about a third data migration concerns. The survey covers every sector, not manufacturing alone.

Our reading of what keeps an old machine there. These four are our reasoning from the record above. None is a finding of any source.

1. Nobody has a list of what stands on each old machine. Applications, scheduled jobs and shared folders were added over years, and the people who added them have left.
2. One or two applications will not run on anything newer. They were written for the versions of their day, sometimes with a tool its maker no longer supports, and the whole machine waits for them.
3. The choice is put as everything or nothing. A proposal to deal with one application grows into a replacement of every old system, is too large to approve, and the other option on the table is to change nothing.
4. For the ERP, the firm’s own additions are unknown to everyone. The specialist can price the product. The custom programs around it are priced as a provisional sum, and after the move nobody can check that everything came across.

4. The Options a Firm in This Position Had

Option	When it fits	What it risks	Our view
Accept the risk, or buy paid extended cover, and wait	The machine is isolated, cover exists for that version, and a retirement date is already firm	Cover has its own end date, some versions have none, and nothing about what holds the machine changes	Right only as a pause with an end date
Upgrade in place, by the firm’s own team	The applications on the machine are known to run on the newer version	The first application that fails stops the upgrade, and whatever else would have failed stays unknown	Right once the list exists and shows nothing pins the machine
Rebuild the application that pins the machine	The one or two applications that cannot move are already known by name	Without a full list, the wrong one is rebuilt, or a second is found after the first	Right, once the list exists
Write down first what stands on each old machine and the custom programs beside the ERP, then rebuild only what pins a machine, one module at a time	Nobody holds a full list, the tools are unsupported, earlier attempts stopped, and an ERP move is ahead	Costs money before anything changes; old and new run side by side; every old machine is exactly as exposed until the firm’s own team retires it	Our recommendation

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

For the applications a manufacturer built or had built beside its ERP: write down first what each one does and what it stands on, the operating system, the database and their published support dates, and name the applications that pin each old machine. Rebuild only those, one module at a time on current technology, with the old application still running until the firm’s own people accept each new module. The firm’s own team then moves what remains and retires the machine. The same specification describes the custom programs beside the ERP, so the firm’s own ERP specialist can price the move against a written scope. IOanyT upgrades nothing in place: the upgrade, the retirement and the ERP move are the firm’s own team’s and its specialist’s work.

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 manufacturer’s own figures, taken in the first review.

Measure	Typical starting point	Where it should be	How it is checked
Your own applications and what each stands on	A label on a machine, and one person’s memory	Every application listed with the operating system, the database and the support date it stands on	The map of the system and the specification
Applications pinning each old machine	Found one at a time, in failed moves	Named for each machine	The risk register
Custom programs beside the ERP	Priced as a provisional sum	Each specified: what it does, what it reads and writes, and who uses it	The specification
How the ERP move is priced	Each specialist against a different guess	The firm’s own ERP specialist, against the written specification	The specification, handed over
Applications that pinned a machine	Kept, untouched	Rebuilt one module at a time, each accepted by your own people	The traceability matrix and the record of each accepted module
Machines past their end date	Not counted	Counted, and falling at each stage	Reported at every review

7. How IOanyT Would Work

1. We listen: a free Reliability Review. A first conversation about your applications, the old servers and databases beneath them, and the ERP move ahead. 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 the applications you built or had built beside your ERP, and what each of them stands on. 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 applications that pin an old machine, rebuilt on current technology so that your own team can retire the machine. 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 the firm’s own applications do and what each stands on, in writing, confirmed by the firm’s own people, including the custom programs beside the ERP.
• The risk register: what the assessment found, listed before any price is set, including the applications that pin each old machine.
• 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, including how many machines past their end date remain.

9. What This Approach Does Not Cover

• IOanyT does not upgrade, patch, replace or retire an operating system, a database or a server, and does not sell or arrange extended cover. The manufacturer’s own team does the upgrade and the retirement.
• Nothing in this approach makes an old machine safe while it is still in use. Until the manufacturer’s own team retires it, it is exactly as exposed as before. IOanyT does not secure or monitor it, and promises no protection from attack.
• IOanyT does not install, configure, upgrade, convert or move a packaged ERP product, does not change customisations written inside one, and is not a partner of any ERP maker. The manufacturer’s ERP specialist does the move. A program written inside the ERP, in the product’s own language, may be outside what IOanyT reads.
• IOanyT does not read RPG or COBOL, and does not work on the business computers they run on.
• IOanyT does not work on plant control systems, machine software or shop-floor control systems.
• IOanyT does not host applications, and does not move data between databases as a stated service.
• Reading code may not find every need an application has; some show only when it runs, so the firm’s own upgrade still needs its own testing.
• This study does not say IOanyT has done this work for a manufacturer. IOanyT has no published case of this work for a manufacturer. The older technologies it reads include VB6, Delphi, AngularJS, PHP 4 to 8, Java 8, .NET Framework and classic ASP.

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

10. Sources

Source	Used for
endoflife.date/windows-server	Windows Server 2012 and 2012 R2 dates
Microsoft lifecycle, SQL Server 2012; SQL Server 2016	Database dates
Microsoft, VB6 support statement	VB6 support
A vendor’s article, 2025	One ERP product’s maintenance dates
News report of an industry body’s survey, 2026	UK manufacturers and cyber incidents
A vendor’s survey of about 500 US IT professionals, 2025	Why firms delay replacing old systems

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 with the list of what stands on each old machine, so the end date becomes a plan your own team can finish.

Book a free Reliability Review →

Get a fixed quote →

See the Legacy System Specification Assessment →