For a small business, the resulting delay can affect sales, service, and staff time. The age of the software is not the deciding factor. The more useful question is whether the business can still maintain it, secure it, and adapt it without unacceptable disruption.
Why business software can become a business risk
Older systems often carry important business rules that staff rely on every day. That value can make a replacement seem unnecessary, particularly when the application still performs its main task. Yet a working system can become difficult to support if its components are no longer maintained or its connections to other software are fragile.
The GOV.UK legacy IT risk assessment framework looks beyond a system’s age. Its indicators include support status, available expertise, security weaknesses, recent failures, and whether the technology can meet business needs. An SME does not need to copy a government assessment in full to use the underlying idea: judge the likelihood of a problem alongside its effect on operations.
For example, an ageing reporting tool used once a month may present a different priority from an unsupported application that handles orders throughout the day. Mapping which processes depend on each system helps owners decide where an investigation should begin.
Warning signs to check before a failure forces the decision
The first warning may be a routine change that takes far longer than expected. A developer might be reluctant to alter one feature because no one can predict what else will break. Staff may compensate by moving information between systems manually, making the underlying limitation less visible to management.
A practical review should look for these signs:
Changes are hard to make: Even modest business requests require extensive work or create repeated defects.
Knowledge is concentrated: Only one employee or supplier understands how the application works, and its documentation is incomplete.
Security maintenance has stalled: Required components no longer receive updates, or available patches cannot be applied safely.
Operational problems are recurring: Failures, workarounds, or integration difficulties are disrupting the people who depend on the system.
Any one sign merits attention, but their combination is more revealing. If the only person who understands an application is also the only person able to restore it after a failure, the business has a continuity risk as well as a technical one. Record the evidence, the affected process, and who currently resolves problems. This gives decision-makers a clearer starting point than a general instruction to ‘replace the old system’.
Old is not the same as unsupported
Before treating an application as a security exposure, check exactly what it runs on. An older application may use supported components, while a newer-looking interface may depend on software that has reached the end of support. The version installed matters more than the year the application first went live.
Microsoft’s .NET Framework lifecycle information shows why that distinction matters: different releases have different support positions. For businesses assessing older Framework-based systems, modernising legacy .NET applications is a more useful discussion than assuming every application needs immediate replacement.
Ask the person responsible for the system to identify its installed versions, operating environment, and update history. Check whether security updates are still supplied and whether they are actually being applied. If patching has stopped, establish why and assess the business process exposed while a longer-term plan is developed.
Incremental modernisation or a rebuild?
Modernisation need not mean replacing the entire application at once. If the core business logic remains useful and parts of the system can be separated, a team may be able to improve one component while keeping the rest in service. That might allow users to test changes against real work before the next part is addressed.
A rebuild deserves consideration when the existing architecture makes necessary changes impractical or the system no longer fits how the business operates. It can also make sense if maintaining old dependencies would leave the main risks in place. Rebuilding, however, requires a clear understanding of what the current application does, including rules that may never have been formally documented.
The decision should start with a map of the system’s dependencies and a list of outcomes the business needs. Which functions are essential, and which exist only because of an old process? Can a component be changed without interrupting other systems? How would each option affect security maintenance and future changes?
A small, bounded piece of discovery can help answer those questions before committing to a delivery approach. The resulting recommendation should explain what can be retained, what needs replacing, and which assumptions still require testing. That is more useful than choosing a rebuild because the software feels old.
Plan for cost and operational disruption, not just development
A software estimate is only part of the investment. Employees may need time to explain existing workflows, check whether the proposed system handles unusual cases, and learn a different process. Data may need cleaning before migration, especially if staff have used workarounds for years. Connections to other applications also need to be identified and tested.
Businesses should ask for a plan covering these workstreams:
Identifying the systems, suppliers, and processes that depend on the application.
Preparing and checking data before and after migration.
Testing everyday tasks, exceptions, access controls, and connected systems.
Allowing staff time for decisions, training, and acceptance testing.
Planning the changeover, any period of parallel running, and a response if it fails.
The right approach depends on how much interruption the business can tolerate. An application used continuously by customer-facing staff may need a different changeover plan from an internal tool used occasionally. An estimate should therefore identify its assumptions, exclusions, and responsibilities, rather than presenting development work as the entire project.
It is also worth budgeting for the period after launch. Someone will need to monitor the new or updated system, resolve defects, apply updates, and maintain documentation. Without that ownership, today’s modernisation can become tomorrow’s support problem.
Questions to put to a software supplier
Supplier discussions are most productive when they focus on how the work will be assessed and delivered. A proposal should show that the supplier understands the business process, not simply the technology used to run it. These questions can expose important differences between approaches:
How will you identify the application’s components, dependencies, and undocumented business rules?
Which parts would you retain, modernise, or replace, and what evidence supports that choice?
How will you test data migration and integrations without relying solely on a successful technical transfer?
What interruption should staff prepare for, and what happens if the changeover cannot proceed as planned?
Who will own the code, documentation, accounts, and access needed to maintain the system?
How will security updates and ongoing support be handled after the project ends?
What assumptions, risks, and exclusions sit behind the estimate?
The answers should produce a staged plan with named responsibilities and points where the business can review progress. Owners can then compare options on the basis of operational risk as well as price. The immediate next step is to inventory the systems that support essential work, confirm their support status, and investigate the ones where a failure or change would hurt most.
