Legacy System Modernisation in Australia: A CFO's Guide to Cost, Risk and Sequencing

Legacy modernisation proposals usually arrive on a CFO's desk with a large number, a technical justification, and a vague completion date. They are hard to evaluate because the downside of doing nothing is invisible until it is catastrophic, and the downside of doing it badly is a multi-year write-off.

This is a guide to evaluating that decision from the finance side.

First, be precise about what "legacy" means here

"Legacy" is not about age. A well-maintained fifteen-year-old system is not a problem. The actual risk indicators are:

• Change has become expensive. Work that should take days takes weeks, and estimates are consistently wrong.
• The knowledge is concentrated. One or two people understand it, and they are not junior.
• It blocks revenue. You cannot ship a product the market wants because the system will not support it.
• It carries compliance exposure. Unsupported dependencies, unpatched runtimes, no audit trail.
• Integration is the bottleneck. Every new system needs a bespoke adapter.

If none of those apply, the system is old, not legacy, and modernising it is discretionary.

Why rewrites fail, in financial terms

The default proposal is a rewrite: build the replacement, switch over, decommission the old one. It is intuitively appealing and it fails often.

The financial mechanics of the failure are consistent:

• You pay twice for years. The old system still needs maintenance and compliance work throughout the rebuild.
• The scope is unknowable at the start. The old system encodes two decades of undocumented business rules. You will discover them during the rebuild, not before.
• No value lands until the end. A rewrite that is 70 per cent complete has delivered nothing. If it is cancelled at that point, you have written off the entire spend.
• The target moves. A three-year rebuild is aiming at what the business needed three years ago.

The pattern to be sceptical of is any proposal where meaningful value only arrives at the end.

The sequencing that actually works

Modernisation that succeeds is almost always incremental, and it is funded incrementally.

1. Instrument before you touch anything. Logging, monitoring, and a clear picture of what the system actually does in production. Often reveals that 40 per cent of the feature set is unused — which is the cheapest scope reduction available.

2. Get it under test. Characterisation tests around current behaviour, whatever that behaviour is. This is what makes everything afterwards safe, and it is the step most often skipped under budget pressure.

3. Strangle the highest-pain edges first. Route specific functions to new services while the old system keeps running. Each increment delivers value independently and can be stopped without write-off.

4. Move the data last, and carefully. Data migration is usually the highest-risk single step. Do it when you understand the domain well, not at the start when you understand it least.

5. Decommission deliberately. Turning the old system off is a project, not an afterthought.

What it costs

Indicative Australian mid-market ranges:

Scope	Cost (AUD)	Timeline
Assessment and roadmap	25,000 – 60,000	3–6 weeks
Instrumentation and test harness	60,000 – 150,000	6–12 weeks
Strangle one major capability	100,000 – 300,000	3–6 months
Full platform modernisation	500,000 – 3,000,000+	18 months – 3 years

The number that matters most is the first one. A proper assessment is cheap relative to the programme and is the only thing that makes the later numbers credible. Be suspicious of any partner who will quote the full programme without doing it.

How to fund it without writing a blank cheque

• Fund the assessment separately. Small, fixed, and it produces a decision — not a commitment.
• Fund in capability-sized increments. Each tranche delivers something usable and is independently cancellable.
• Set a stop condition per tranche. Written down before the work starts.
• Require production value each tranche. Not a demo. Something real users touch.
• Track cost of change as the key metric. If modernisation is working, the cost of delivering a feature should be falling. If it is not falling after two tranches, something is wrong with the approach.

The AI-assisted difference

AI tooling has genuinely changed the economics of a few specific parts of this work:

• Comprehension. Reading and summarising unfamiliar code is dramatically faster, which compresses the assessment phase.
• Test generation. Characterisation tests around existing behaviour are exactly the kind of high-volume, pattern-following work AI does well.
• Mechanical translation. Language and framework migrations that follow consistent patterns.

It has changed the economics of architecture, data migration and stakeholder alignment approximately not at all. Treat proposals claiming AI will halve the total cost with caution — it meaningfully reduces some line items, not the programme.

In practice

Development Signs modernised a legacy operations platform with us incrementally rather than through a rewrite, and Cobber rebuilt a partner portal onto containerised AWS infrastructure in stages.

You can read more about how we approach modernisation, or start with an assessment conversation.

Related reading

• Outsource Software Development in Australia: 2026 Cost Comparison
• Why You Need a CTO for Startups and Scaleups
• How to Choose the Right Software Development Partner