Legacy modernisation: retire, retain, replace or evolve

Every legacy system reaches a day when keeping it costs more than changing it. The skill is spotting that day before it arrives, and then choosing the right kind of change.

Technical debt behaves like financial debt. A little, well managed, is a sensible trade-off. Left alone, the interest compounds: more patching, more workarounds, fewer people who understand the system, and less money left for anything new. Many Adelaide organisations are closer to that inflection point than they realise. The small local talent pool that supports their old systems is also being hired by everyone else, and in mid-sized businesses and not-for-profits there is often no IT executive whose job it is to notice.

Modernising does not mean replacing everything. This article covers four decisions – Retire, Retain, Replace and Evolve – and the questions I use to choose between them.

The situation I see most often is a system that nobody dares switch off. It runs quietly in the corner, nobody is sure who uses it, and nobody has the authority to find out. This article is for the people who inherit those systems: leaders of mid-sized businesses and not-for-profits, and anyone in an organisation where no executive owns IT.

I was engaged to consult at a large utility company, which had acquired multiple other smaller companies. There was a plethora of servers and systems that were unknown, but nobody wanted to volunteer to take the ownership and switch them off. My role was mostly taken up by trying to find a person – anyone – who would make the decision that they legacy system was ready to be shut off. After a few scream tests, and the decision to move the data from many systems to a Data Warehouse (just in case!), I managed to shut down nearly 150 servers, empty three racks, and save nearly $500K of annual overhead in maintenance, patching, support, personnel, and consumption of resources.

The signs the inflection point has arrived

Technical debt rarely announces itself. It shows up as a pattern, and two or three of these together usually mean the point has been reached:

• Run cost keeps climbing while capability stays flat. More of the budget goes on keeping the lights on, and less on anything new.
• Small changes become big projects. A simple request needs weeks of regression testing, and still breaks something.
• Key-person dependency. One or two people understand the system, and the local market has few replacements.
• The ecosystem moves on. The vendor ends support, patches stop, or newer systems can no longer connect.
• Compliance gaps you cannot close, such as unsupported software that cannot meet Essential Eight expectations.
• The business stops asking. People no longer request improvements because they already know “the system can’t do that”.

That last one is the most dangerous, because it looks like satisfaction. When you spot these signs, start with an options analysis that includes Option 0 (do nothing) as the baseline.

It does not normally start with a business request, but it always ends up with a business decision. In many organisations, the IT team simply do their job of maintaining the availability and security of a system, without really knowing how it is used. It is only through active audit that the old systems can be identified and then rooted out.

I have seen organisations where new systems are deployed – a full suite of dev/test/UAT/SIT/live systems, ready for a project, but the project then gets shelved or forgotten. Then that is five servers, plus all the supporting infrastructure, going un-used.

Retire: when the whole system should simply go

Retirement is the cheapest option and the one most often skipped. Many legacy systems are still running because nobody is brave enough to switch them off, not because anyone needs them.

In mid-sized businesses and not-for-profits, the blocker is usually ownership, not technology. The person who set the system up has moved on, there is no IT executive to ask, and nobody feels authorised to risk an outage. So the first job is to give the system an owner, even a temporary one, with the authority to make the call.

Consider retiring a system when:

• The business process it supports no longer exists, or has dropped to very low use.
• Another system already does the same job, so you are paying twice.
• The only reason to keep it is access to old data, which can be archived read-only.

AWS guidance on retirement notes that these decisions are often postponed, especially when the experts have left and the documentation is thin. That is a reason to act sooner, not later. Build evidence first: usage logs, a dependency map, and the retention rules for the data. Then switch off in stages, with a rollback plan and a clear announcement so that anyone who still depends on it speaks up. In some cases, the application is not needed, but the data “might” need to be accessed within the retention period – for this situation, a Data Warehouse may allow access to the data, without the need to maintain an application.

Retain: when keeping a legacy system is the right call

Not every old system is a problem. A system that is stable, supported, secure and rarely changed can be good value, and replacing it just because it is old is how organisations burn money. The Gartner TIME model captures this: it weighs business value against technical fit, and the answer for some systems is simply to tolerate them for now.

Retaining makes sense when:

• The system does one job well and changes rarely.
• Replacement cost outweighs the benefit within a realistic five-year horizon.
• It carries specialised functions or certifications that are expensive to recreate, as is common with industrial, laboratory and defence-related systems.
• The process it supports is itself due to end soon.
• The full retention and support budget is approved, for the projected retention lifetime, and the skills are retained too.

But retain with conditions, not by default. Keep the documentation current, make sure at least two people can support it, isolate it with compensating security controls, and set a review date and an exit plan. Retain without a review date is just Option 0 with better manners.

Replace: when the technology has to change completely

Replacement is the right call when the business still needs what the system does, but the technology underneath cannot keep doing it safely or affordably. In TIME terms: high business value, low technical fit.

The usual triggers are:

• The platform is out of support and cannot be secured to the standard you need.
• The vendor has gone, or the product has no future roadmap.
• The cost of changing it now exceeds the cost of a replacement over the same period.
• The skills to run it cannot be found, hired or trained locally.

Two cautions. First, replacing like for like carries the old process into a new platform, so you pay for change and get little improvement. Decide whether the replacement is an Improve, an Optimise or an Innovate before you pick the product. Second, the software is rarely the hardest part. Data migration, integration and the change for the people who use it are routinely underestimated, so budget for them separately.

Evolve: moving to SaaS, PaaS or microservices

Evolving means keeping the capability but changing how it is delivered. The choice of paradigm should follow the nature of the capability, not the fashion of the year.

• SaaS is my default, every time, for commodity capabilities such as finance, HR, email and CRM, where the market already sells a good product. Building or hosting your own needs a reason strong enough to survive scrutiny. You trade control for speed and lower run effort, so configure rather than customise, and check data location, security and exit terms.
• PaaS suits systems with unique logic worth keeping but a platform you no longer want to run. Managed services take over patching and infrastructure, though you accept some vendor lock-in.
• Microservices suit systems with separate parts that change at different speeds or need to scale independently, and only where the team has the engineering maturity to run them. Otherwise a well-structured, modular system can be simpler and cheaper. In 2023 the Prime Video team reported that moving one monitoring service from a distributed design back to a single application cut its infrastructure cost by over 90%. It was one service, not a verdict on microservices, but it is a useful reminder to match the design to the problem.

Whichever you choose, avoid the big bang. Martin Fowler’s strangler fig pattern, named in 2004, moves one function at a time to the new platform while the old one keeps running, until the old system can be switched off. It reduces risk and gives you regular chances to stop or change course.

Adelaide angle: the best paradigm is one you can staff. SaaS and PaaS move work from scarce specialists to vendors, which helps a small talent pool and suits mid-sized businesses and not-for-profits that cannot carry a large IT team. But SaaS without an owner is just a new legacy system: the subscription nobody dares cancel. Name a business owner for every product, keep a register of what you subscribe to and who has access, and put each renewal date in the diary.

A quick decision guide

Work down the list for each system. The first row where your answer matches the “Answer” column points to your starting direction.

Ask this	Answer	Direction
Does the business still need what it does?	No	Retire and archive the data
Is it stable, supported, low-change and cheap to keep?	Yes	Retain, with a review date and an exit plan
Is the capability a commodity the market sells well?	Yes	Replace with SaaS first; build or host only with a strong reason
Does it hold unique logic worth keeping, but the platform is the problem?	Yes	Evolve to PaaS or replatform
Does it have separable parts that change at different speeds, and do you have the engineering maturity?	Yes	Evolve gradually, using the strangler fig approach
Can it no longer be secured, supported or staffed, and nothing above fits?	Yes	Replace by buying or building, and plan the exit now

Whatever the direction, test it against Option 0. If a modernisation option cannot beat doing nothing on risk, cost and people, it is not ready to go to the board.

If nobody at executive level owns IT in your organisation, ask the CEO or the board to name an owner before you start. Every option above fails without one.

How close is your organisation to its inflection point? I would like to hear which of these decisions you are facing.