Your business software is no longer supported: how to replace it without stopping work

Many companies run part of their operations on software nobody looks after any more. Sometimes the vendor sent a polite end-of-life notice. Sometimes the small agency that built it closed, or the one developer who understood it left. The software still works, so nobody touches it, and every month the gap between it and everything around it grows a little wider.

This article is about that specific situation: the software is not just old, it is orphaned. It covers the real risks, the four options you actually have, how to choose between them, and how to replace the software without stopping the business. If your system is still supported but has become hard to evolve, the broader method is in our guide to legacy application modernization.

Two ways software becomes unsupported

The situation looks the same from your desk, but the cause changes your options.

The vendor ended support. You bought an off-the-shelf or industry-specific package, and the publisher has announced end of life, been acquired, moved everyone to a new cloud product, or simply stopped releasing updates. You usually have a licence, some documentation, and no access to the source code. The vendor may offer a migration path to its new product, at its price.

The developer is gone. The software was built for you, by a freelancer, an agency or an in-house developer. That person or company is no longer available. You may or may not have the source code, the hosting credentials and the domain names. Nobody knows how to build, deploy or fix it.

In both cases, the practical definition is the same: no one is obliged, or able, to fix it when it breaks.

Why "it still works" is not a plan

Software does not age on its own. Everything around it moves: the operating system, the browser, the database engine, the libraries it depends on, the accounting package or the bank it exchanges files with. Unsupported software does not stay stable. It falls behind its environment, month after month, until an update elsewhere breaks it.

Four risks follow, and they compound.

1. Security. Without patches, known vulnerabilities in the software and its components stay open, and those are precisely the ones automated attacks scan for. The UK National Cyber Security Centre is blunt about it in its device security guidance: "You should replace unsupported software and devices as soon as you are able."
2. Breakdown with no one to call. When it stops, there is no support line, no developer and no documentation. Every fix becomes an investigation.
3. Frozen processes. New needs get handled in spreadsheets next to the software, because changing it feels too risky. Data is typed twice and drifts apart.
4. Hardware hostage. The software only runs on one old server in a cupboard, or one PC nobody dares to reboot, or a browser that must never be updated. When that machine fails, the business stops with it.

There is also a compliance angle. If the software holds personal data, the EU GDPR (and its UK equivalent) requires "appropriate technical and organisational measures" to secure it. Knowingly running unpatched software is hard to defend after a breach.

Warning signs that it is time to act

• The vendor has published an end-of-support date, or stopped answering.
• Nobody can rebuild or redeploy the application from its source code.
• The language, framework or database no longer receives security fixes.
• Users are afraid to install any update in case the tool breaks.
• New requirements are worked around rather than built in.
• You do not know where the hosting, the domain or the code repository is registered, or in whose name.

None of these requires action this week. But the best moment to replace software is while the old system still runs: you can study it, compare outputs and switch over calmly. After a failure, you rebuild in a hurry, without the original to check against, while the business waits.

Step 1: secure what you have, this month

Before choosing a long-term option, reduce the immediate risk. These steps are cheap and buy time.

• Get control of the assets. Source code if it exists, hosting and domain accounts, database credentials, licence keys. Put them in the company's name.
• Back up the data and test that the backup actually restores.
• Isolate the system. Restrict who and what can reach it, remove internet exposure where you can, and keep it off shared networks.
• Write down what it does. Screens, reports, scheduled jobs, files it imports and exports, and who uses each part.
• Set a deadline. Containment is a bridge, not a destination.

Step 2: choose between four options

Take over maintenance is often the cheapest option, but only if the software is fundamentally sound. A new team needs to recover the code, rebuild it, deploy it and understand its business rules. An audit before takeover tells you in a few days whether that is realistic, or whether you would be paying to keep a dead technology alive. If the takeover makes sense, the next question is what ongoing maintenance covers.

Move to off-the-shelf is right when your process is genuinely standard: accounting, payroll, general CRM. Be honest about it. The old software was usually built or chosen because something was not standard. If the off-the-shelf product needs heavy customisation to fit, you are trading one dependency for another. Our build vs buy guide goes through the trade-off.

Rebuild when the software is how your business actually works: quoting rules, scheduling logic, industry-specific workflows. A rebuild keeps that knowledge and puts it on a base that can be maintained.

What the old software is worth

An orphaned application is not just a liability. It holds years of business rules, exceptions and edge cases that the company refined over time, often without ever writing them down anywhere else. It also holds your data, which is frequently the most valuable thing in it.

A good replacement starts by recognising that. The goal is not to reinvent the business but to carry it over to a healthy base, keeping what works and dropping what nobody uses.

You do not need the source code to do this. The running application, its screens and exports, its database and, above all, the people who use it every day are enough to describe what it must keep doing. Code helps, but code also contains features nobody has touched for years.

Step 3: replace it in stages, not in one weekend

Two strategies compete.

The big bang rewrite rebuilds everything, then switches over on one day. It looks simpler to plan. It is the riskiest: nothing new is used for months, gaps with the old tool appear only at the end, and every problem lands on the same day. It suits only small applications.

Step-by-step replacement rebuilds one module at a time. The new system takes over one task, then another, while the old one keeps handling the rest. Each module goes into production and is used for real before the next one starts. This approach, often called the strangler fig pattern, is explained in detail in our legacy modernization guide.

For unsupported software, step-by-step has one extra benefit: it reduces your exposure fastest. Start with the most fragile or most exposed part, the one that worries you most if the old server dies tomorrow.

Step 4: treat data migration as its own project

Whatever the strategy, the data has to move. It is rarely a simple copy: formats have changed, duplicates have built up, and some fields have been used for something other than their original purpose for years.

Work through it with someone from the business who knows which data is authoritative and which can be dropped. Rehearse the migration on copies before go-live, and price it from the start, because it is one of the items that moves the budget most. Our guide to legacy data migration covers the method.

Avoiding a project that never ends

Most replacement projects that fail do not lack skills. They drag on. They discover forgotten features along the way, accumulate wish-list items, and the old software keeps running because no cut-over date is credible.

Three habits help.

1. Validate the scope before development, on a visual prototype that shows the screens and workflows of the future tool. Missing pieces show up immediately, not during acceptance testing.
2. Deliver in short stages, each one usable in production. A project that delivers nothing for months is a project in trouble.
3. Improve, but do not reinvent. Remove dead features and fix known irritations, yes. Add ten years of accumulated wishes, no: they come later, on a healthy base.

Do not end up here again

The software became orphaned because its future depended on one vendor or one person. When you choose the replacement, check three things.

• Who can maintain it if the supplier disappears. Mainstream technology, documentation, and code that another team can read.
• What you get access to. Code, data exports, hosting and accounts. For custom software, rights are defined case by case in the contract; make sure the contract says how you get your data and the means to continue. Our article on avoiding vendor lock-in lists what to ask for.
• How maintenance is funded. Software without a maintenance budget becomes unsupported again, just more slowly.

Where to start

Write down what you know: what the software does, who uses it, which machine it runs on, where the data lives, and what worries you most. A few screenshots and a data export are enough for a first conversation.

At LPR Studio, that conversation leads to a free visual prototype of the replacement, presented on a video call within 5 working days. It becomes the basis for splitting the replacement into stages and choosing the right formula: a fixed price, or a subscription that includes maintenance and updates so the new tool does not become the next orphan.