Replace or Modernise? How to Decide What to Do With a Legacy System
Replace a legacy system when it no longer fits how the business works or cannot be supported securely. Modernise it when the core still fits but the technology underneath is holding you back.
Written and reviewed by The Technology Office · Independent technology advisory
Key takeaways
- A legacy system is defined by how hard it is to change, support, secure, and integrate, not by its age.
- Replace when business fit is poor or the platform cannot be supported securely; modernise when the core still fits.
- Count the hidden costs of keeping a system, especially workarounds and dependence on one or two people.
- Plan data, sequencing, go/no-go gates, and decommissioning from the start.
The short answer
Replace a legacy system when it no longer fits how the business works, the vendor no longer supports it, or keeping it secure has become impractical. Modernise it when the core business logic still fits but the platform, integrations, or user experience are holding you back. Retain it, with a clear review date, when it works, is supportable, and other priorities offer more value.
What counts as a legacy system?
A legacy system is not defined by age. It is a system that has become harder to change, support, secure, or integrate than the business can accept. Common signs include:
- the vendor has ended support, or the product is no longer actively developed
- only one or two people understand how it works
- simple changes take months or depend on a single contractor
- it cannot integrate cleanly with newer systems, so staff re-key data
- reporting depends on spreadsheets extracted from the system
- security updates are unavailable, or cannot be applied without breaking something
What are the options?
Most decisions fall into one of six options:
| Option | What it means | When it fits |
|---|---|---|
| Retain | Keep running as is, with a planned review date | It works, is supported, and other priorities are higher |
| Rehost | Move to new infrastructure, such as cloud, without changing the application | The infrastructure is the problem, not the application |
| Replatform | Move to a newer platform or version with limited changes | The product has a supported upgrade path |
| Refactor | Re-engineer parts of a custom system | Distinctive business logic is worth keeping but the code is hard to change |
| Replace | Move to a new product, often software-as-a-service | Processes are standard, fit is poor, or the platform is unsupported |
| Retire | Switch it off and move remaining functions elsewhere | The capability is duplicated or no longer needed |
How do you decide? Five questions
- Does it still fit how the business works? If core processes have moved on and workarounds are everywhere, modernising the technology will not fix the fit. That points to replacement.
- Is it supportable and secure? Unsupported software stops receiving security updates. ASD's Essential Eight maturity model includes removing or replacing applications and operating systems that vendors no longer support. If a system cannot be secured, the question becomes when to act, not whether.
- What does it really cost to keep? Include support contracts, specialist contractors, manual workarounds, duplicate data entry, and the business impact of an outage. Staff time spent working around a system is often the largest hidden cost.
- Is the business logic distinctive? If the system encodes genuinely unique processes that give you an advantage, preserving that logic through refactoring or replatforming may beat forcing a standard product. If the processes are standard, such as finance, payroll, or CRM, a modern product is usually better value.
- What depends on it? Map integrations, reports, and downstream processes. Heavy dependencies rarely prevent replacement, but they shape the sequence and the risk.
A simple way to show the decision
Score each system on business fit and technical health, then place it in the grid:
| Low technical health | High technical health | |
|---|---|---|
| High business fit | Modernise: replatform, refactor, or rehost | Retain and maintain |
| Low business fit | Replace | Replace or retire when convenient |
Then adjust for cost, risk, and dependencies. The grid will not make the decision for you, but it makes the reasoning visible to executives and the board.
How do you plan a legacy replacement?
- Build an inventory. Record functions, users, data, integrations, reports, and contracts.
- Assess data quality early. Poor data is one of the most common causes of delay. Decide what to migrate, archive, or leave behind.
- Choose the target through a structured selection. See how to choose a new business system.
- Sequence the change. Replacing one capability at a time while old and new run side by side reduces risk compared with a single cut-over, but needs careful integration and reconciliation.
- Set go/no-go gates. Define the evidence required before data migration, parallel running, and final cut-over.
- Plan decommissioning. Agree when the old system will be switched off, how historical data will be retained, and when contracts end. Many organisations pay for two systems far longer than planned.
What are the signs you have waited too long?
- A vendor end-of-support date falls inside your planning horizon and there is no plan.
- An auditor, insurer, or major customer has raised the system as a risk.
- A key person holds critical knowledge that is not documented.
- The business is turning down opportunities because the system cannot support them.
Who should own the decision?
Legacy decisions are business decisions with technical consequences. The executive team should own the choice, informed by an independent view of options, costs, and risks. A CIO-led transformation approach provides that view and then governs delivery. If a replacement is already under way and drifting, see how to govern a technology transformation project. For the security baseline behind question two, see what is the Essential Eight.
Frequently asked questions
What is a legacy system?
A system that has become harder to change, support, secure, or integrate than the business can accept. Age alone does not make a system legacy.
When should a legacy system be replaced rather than modernised?
When it no longer fits how the business works, the vendor no longer supports it, or it cannot be kept secure. If the core still fits but the platform is the problem, modernising is often better value.
Is it risky to keep running unsupported software?
Yes. Unsupported software stops receiving security updates, and ASD's Essential Eight maturity model includes removing or replacing applications and operating systems that vendors no longer support.
What is the biggest hidden cost of keeping a legacy system?
Usually staff time spent on workarounds, duplicate data entry, and manual reporting, along with dependence on the one or two people who understand the system.
Should a legacy system be replaced all at once or in phases?
Phased replacement usually lowers risk because problems surface earlier, but it needs careful integration and reconciliation while old and new systems run together.
Sources and further reading
- Essential Eight maturity model — Australian Signals Directorate (cyber.gov.au)
- Developing a Business Case — Australian Government Department of Finance
Mentioned services
These service and regional NSW pages expand on the topics covered in this article.
Need help applying this?
Bring in senior technology leadership without the full-time overhead.
The Technology Office works with Sydney and regional NSW businesses on embedded CIO support, Head of IT leadership, governance, vendor management, cost optimisation, crisis stabilisation, and no-cost technology reviews as a lighter first step.