The real trigger for modernisation is rarely the software

The end-of-support date is an excuse, not a cause

A version leaves support in eighteen months and the board asks for options. The date is useful — it turns drift into a deadline — but it shapes the wrong project: same screens on newer plumbing, inheriting every assumption the old system encoded.

The better question is what the system prevents. Usually it is one of four things.

Four pressures that actually decide it

Business rules nobody can review

Why do two identical jobs carry different labour rates? In long-lived systems the answer sits in a stored procedure, a macro, or a field a former employee configured. It works, but it cannot be inspected, tested or changed with confidence — and “it has always done that” is a poor answer to an auditor.

Questions it cannot answer

Cost per tonne by shift, margin by service line after travel, maintenance hours against failure history. The data is present, but retrieving it takes an export, a spreadsheet and someone who knows which columns to trust. That is evidence the data model no longer matches how the business thinks.

Integration fragility

Field capture feeds payroll, payroll feeds the ERP, and between them sits a nightly transfer nobody owns. It fails quietly and surfaces as a reconciliation difference at month end. We cover how to quantify that in integration debt.

Key-person risk

Acute in WA, where IT teams are small: one person understands the month-end sequence and holds no documentation, because nobody asked. The risk is not only that they leave. It is that no decision about the system can be made without them.

Most modernisation projects are sold as a technology upgrade and then discovered to be a knowledge recovery exercise.

A sequencing model that keeps the business running

Once the goal is recovering rules and restoring the ability to answer questions, the order of work changes: extract value early, retire the core last.

1. Stabilise. Put the system under support with response targets and fix what wakes people up.
2. Instrument. Add logging, reconciliation and alerting. This is where undocumented rules surface.
3. Extract reporting. Build a read path — a read replica or warehouse — and move reporting onto it.
4. Strangle the edges. Replace the portal, mobile capture and approvals; new parts talk to the core by contract.
5. Replace the core. With rules documented, the transaction engine is tractable and usually smaller than assumed.

That is a strangler fig rather than a cutover, and the benefit is political as much as technical: every stage produces something usable, so funding survives a change of priorities. It is the shape used in the legacy cloud migration case.

What it costs, and where the money goes

Being straight about it: the expensive part is rarely new code. It is discovering what the old system actually does, arguing about which behaviour was intentional, and running both in parallel until they agree. Failure has a recognisable shape too — the build stalls near 80 per cent equivalence, where the remaining fifth is fifteen years of edge cases, and you end up maintaining two platforms.

Why big-bang is where budgets die

A single cutover concentrates every unknown into one weekend: migration quality, untested edge cases, integration behaviour under real load, and the training gap that appears only when people use the thing. It also removes the option to stop — halting a staged programme after reporting extraction still leaves you better off, while 80 per cent of a big-bang is nothing usable.

The counter-argument is real: parallel running has a carrying cost, and if the old platform cannot be stabilised, a faster move may be the lesser risk. Big-bang is defensible when the system is failing, not when it is merely old.

When the right answer is to wait

Sometimes we recommend very little. If the system is stable, the reporting gap closes with a read path and the seams are monitored, then a maintenance and support arrangement with a rolling backlog returns more value than a multi-year programme. Where building is right, the sequencing above applies either way; hosting cost and availability are separate questions, covered in cloud cost governance and uptime definitions.