Every SME that has been running long enough has at least one system nobody wants to touch: the order tool built by a developer who left years ago, the Access database three people in the office still understand, the CRM version so old the vendor stopped invoicing for it. It still works, mostly — which is exactly what lets it keep running past the point where replacing it would already have been cheaper. This guide covers how to tell when legacy software has crossed that line, what NCSC's own guidance says about the risk of running software past its support date, and how a replacement project runs in practice: modernizing in place versus rebuilding, and how to manage risk while old and new systems still run side by side.
Signs it's time to replace, not patch
Not every old system is a problem. Software that still does its job, still gets updated, and still connects to whatever it needs to isn't "legacy" in any sense that matters. The signals worth acting on are more specific:
- Nobody who understands why it works that way still works here — the person who configured its stranger business rules left years ago, and every change now happens by trial and error rather than confident understanding.
- There's no one left to call — the vendor end-of-lifed the product, or the freelancer who built it is unreachable, so a bug has no path to a fix beyond your own team guessing.
- Small changes take disproportionate time, because the system has been patched around its own limitations for so long that nothing is simple to touch anymore.
- It can't do what the rest of your business now expects — no usable export, no connection to your accounting package or CRM, no mobile access.
If two or more of these are true at once, another patch is no longer the cheaper answer.
The real risk of running past end-of-life
NCSC, the Dutch national cyber security centre, defines "end-of-life" as the point at which a manufacturer has stated a product no longer receives support or maintenance, and is explicit that this reaches far beyond an old operating system: it lists laptops, printers, access points, smartphones, Windows, Office, macOS and CRM or CMS packages as products that all carry an end-of-life date, whether or not anyone in the business is tracking it.
Past that date, NCSC names three concrete risks. Vulnerabilities: a new weakness discovered in end-of-life software will not be fixed with an update, a particular risk for anything internet-connected. Compatibility: a newer application may simply not work, or work unreliably, on top of an end-of-life product. Functionality: end-of-life products stop receiving the updates that let them keep pace elsewhere — a newer service you want to connect to may no longer recognize it at all. NCSC also flags a point easy to miss: an end-of-life product is a risk to your *other* systems too, since one unpatched, internet-facing weak point can become the way in to everything connected to it.
NCSC's own recommendation is to replace a product before it reaches end-of-life, so the decision isn't made under pressure. When that isn't realistic, its fallback advice is to restrict or disable the product's internet access rather than leave it fully exposed while a replacement is built. Worth knowing at purchase time: NCSC notes business-oriented products are typically priced higher than consumer equivalents specifically because they carry a longer support window, and some vendors offer a Long Term Support (LTS) version that trades the newest features for more runway before you're back here again.
Modernize in place, or replace entirely?
Modernizing in place makes sense when the underlying logic is still sound — the business rules the software encodes still reflect how you work — and the pain is specifically the technology around that logic: an outdated interface, a database engine no one supports anymore, no way to expose data to other tools. The goal is narrow: replace the layer that's actually failing, keep the logic that still works.
Replacing entirely is right when the business has moved past what the software was built to do, or new requirements (more locations, more integrations, mobile staff) don't fit the existing structure without extensive rework. It's also right when the technology itself is the constraint: a platform old enough that finding developers who still work in it gets harder, and costlier, every year.
The mistake to avoid either way is deciding based on how the software looks rather than on these two questions. A dated interface on a system whose logic and data model are still solid is a modernization project; a slick-looking system built on business rules that no longer match how you operate isn't fixed by a redesign.
Two ways to get there: big bang or phased
A single cutover — decommission the old system and switch everyone on one date — is the fastest way to finish on paper and the riskiest way to get there. Every problem the new system has shows up at once, for every user, with no fallback except reverting under pressure.
A phased approach — build the replacement one function or department at a time, run it alongside the old system, and retire the old piece only once the new one has proven itself under real use — costs more calendar time but fails safely. A problem in a newly built piece affects the group using it, not the whole company, and the old system remains a fallback while it's fixed. For a system carrying years of undocumented business logic, phasing is often the difference between a project that finishes and one that stalls half-migrated.
Whichever path you choose, decide upfront what "done" looks like for each piece and who signs off before the old version is switched off — not after something has already gone wrong on the new one.
Managing risk while old and new run side by side
A replacement project usually means the legacy system keeps running for months while its replacement is built around it, and NCSC's own vulnerability management guidance describes the discipline that period needs: a continuous cycle of assess (inventory what you have, scan for known weaknesses), prioritize (weigh exposure, criticality, threat landscape and impact), treat, evaluate and improve.
The treat stage matters most here. NCSC is explicit that updating is always the best option when available — but a legacy system nearing replacement often has none. For that case it names two other options: mitigate (isolate the system, restrict which networks reach it, adjust its configuration) and accept, only when that fits the organization's actual risk appetite. NCSC's own example of reasonable acceptance is a system nearly end-of-life with a replacement already being built — tolerating a known weakness for the short remaining time it's in use, provided the acceptance carries an expiry date rather than being extended quietly.
If this work is outsourced, NCSC's advice is to settle it explicitly in the contract: know exactly what the vendor is responsible for updating and what falls to you, so a vulnerability in the system being replaced doesn't sit unaddressed because each side assumed the other covered it. Our Cybersecurity & Identity team can run exactly this assessment on a legacy system mid-transition — what's actually exposed, what can be isolated, and what genuinely has to wait for the replacement.
Migrating the data: the part most timelines underestimate
The software is rarely the hardest part of a legacy replacement — the data it has accumulated is. Years of manual corrections, one-off exceptions, and fields repurposed for something other than their original use rarely map cleanly onto a new data model. Budget real time to map which fields actually mean what your team believes, decide what history needs to stay fully queryable versus archived read-only, and test the migration against a real copy of production data rather than a clean sample — the exceptions are exactly what a clean sample won't contain.
Reconcile before cutover, not after: run old and new systems on the same data for a defined period and compare outputs, so a mismatch surfaces as a test failure rather than a customer complaint. If the legacy system's data has never been properly modeled, treat that as its own piece of work before the replacement project starts — our Data & Databases team can assess what's actually in an old system before anyone commits to a timeline based on a guess.
What to prepare before you call a developer
- A real list of who still understands the current system's business rules — the person who knows why an edge case is handled the way it is, not the org chart.
- A full inventory of every integration touching the old system, including ones added informally and never written down.
- A decision on what data history genuinely needs to stay live, made before pricing is discussed, since it changes scope significantly.
- Realistic expectations about running in parallel for a defined period, rather than one cutover weekend that has to go perfectly.
FAQ
When should I replace legacy software instead of patching it? When at least two hold: no one left understands why it works the way it does, there's no vendor or developer to call, small changes take disproportionate time, or it can't connect to tools the rest of your business now treats as standard. One alone is a warning sign; two or more means patching is no longer the cheaper option.
What's the difference between modernizing and fully replacing legacy software? Modernizing keeps business logic that still reflects how you work and replaces the technology around it — an outdated interface or unsupported database engine, for instance. Full replacement is right when the process itself has changed, or the platform is old enough that finding developers gets harder every year.
Can we keep using software after it reaches end-of-life? Sometimes, but NCSC is clear it carries real risk: new vulnerabilities won't be fixed, compatibility with newer tools degrades, and an end-of-life product can expose everything connected to it. If a timely replacement isn't possible, NCSC's advice is to restrict or disable its internet access rather than leave it fully exposed.
How long does a legacy software replacement project take? It depends on how much undocumented business logic and data the old system has accumulated, and whether you choose a phased rollout or a single cutover. Phasing takes longer in calendar time but fails safely, piece by piece; a single cutover can finish faster on paper but puts the entire risk on one date.
What happens to our data during the transition? It should be mapped, tested against a real copy of production data, and reconciled by running old and new side by side before the old one is switched off — not migrated once and assumed correct. This is usually the most underestimated part of the project, not the software itself.
Getting the sequence right
Replacing legacy software goes wrong less often because of the new technology than because one of the decisions above got skipped: staying on end-of-life software too long, choosing a single cutover for a system nobody fully understands anymore, or migrating data without reconciling it first. Our Web & Software Development team runs the assessment, the phased build and the cutover as one connected process, so your team isn't discovering the old system's undocumented rules mid-migration.
---