Software Modernisation in New Zealand

Separate the real risks from the irritating ones

"The system is old" covers several different problems with very different urgencies, and sorting them is the first useful thing to do.

Genuinely urgent:

• A language runtime or framework no longer receiving security patches.
• An operating system or database version out of support.
• Dependencies with known published vulnerabilities.
• Hosting that is being retired, or hardware nobody will supply parts for.

Expensive but not dangerous:

• Every change takes three times as long as it should.
• No tests, so nobody is confident anything still works.
• Deployment is manual and only one person can do it.
• Nobody wants to work on it.

Neither:

• It is written in a language that is out of fashion.
• It does not use the architecture people talk about now.

The first list has dates attached and should be dealt with. The second costs you continuously and can be sequenced. The third is not a reason to spend anything.

Why rewrites go wrong

The rewrite is always tempting, because the new system is imaginary and therefore has no problems.

What actually happens is well documented and unpleasantly consistent:

• The old system contains years of edge cases nobody wrote down. They are rediscovered one production incident at a time.
• The business cannot stop, so the old system keeps changing and the new one is chasing a moving target.
• Nothing is delivered until the end, so support depends on patience holding for the whole duration.
• When it runs long — and it does — you are asked to fund a system that has not yet replaced anything.

Rewrites are occasionally right: when the platform is truly dead, when the business has changed so much the software no longer describes it, or when the system is small enough to rebuild in a few months. Otherwise, modernise.

Sequence so each step is worth having alone

The test of a good modernisation plan is that you could stop after any step and still be better off.

A sequence that usually works:

1. Get supported. Upgrade the runtime, framework and dependencies to versions that receive patches. Removes the dated risk and unblocks everything else.
2. Get it deployable. An automated pipeline, so releases stop being an event and stop depending on one person.
3. Get tests around what matters. Not everything — the parts where a failure costs money. This is what makes change safe.
4. Get visibility. Monitoring and logging, so you find out before a customer rings.
5. Then change the architecture, if it is still worth it.

Ask each firm what they would do first and what it buys on its own. A plan whose benefits all arrive at the end is a rewrite with a different name.

Characterisation tests before you touch anything

Old systems usually have no tests, which is exactly why they are frightening to change.

The technique that works is not to write the tests you wish existed, but to write tests that record what the system currently does — including the parts that look wrong. Then, when you change something, you know precisely what moved.

It feels odd to enshrine behaviour nobody likes. It is what lets you refactor without holding your breath, and it surfaces the accidental behaviour the business has quietly come to rely on.

Ask whether this is in the plan. Its absence is the clearest sign of someone who intends to rewrite.

Do not freeze the business

A proposal that requires no other changes for six months should be treated carefully. The business will need something, will be told no, and support for the programme will evaporate — this is how modernisation projects get cancelled two thirds of the way through, with the cost spent and the benefit not yet arrived.

Ask how ordinary work continues alongside. The answer should involve small increments merged frequently, not a long-lived branch that has to be reconciled at the end.

Replacing piece by piece

Where a system genuinely has to go, the safest route is to build around it and move work across gradually. New functionality is built alongside, traffic is routed to whichever system owns that function, and the old one shrinks until it can be switched off.

What to insist on:

• A clear seam — usually a routing layer or an API — deciding which system handles what.
• An order that takes the highest-value or highest-risk pieces first.
• A plan for data that both systems need during the overlap.
• A decommissioning date for each piece, so the old system actually goes.

That last point matters. The common failure is stopping halfway and running both systems indefinitely, which is more expensive than either.

Buy an assessment first

For a system nobody currently understands, the honest first purchase is two or three weeks of somebody reading it: what it is built on, what is unsupported, what the dependencies are, where the risk sits, and a sequenced plan with rough costs.

You keep that whether or not you use the same firm for the work, and it turns five wildly different quotes into five quotes for the same thing. Expect $10,000 to $25,000, and expect it to save more than that.

Comparing five quotes

Read for:

• Who separated the security-dated risks from the irritations?
• Who proposed a sequence where each step stands alone?
• Who mentioned characterisation tests before changing code?
• Who explained how the business keeps releasing throughout?
• Who was willing to say which parts are fine as they are?

Describe what the system does, what it is built on if you know, what is unsupported, and what change last took longer than it should have. Firms who do this work will ask to read the code before they price it — and that request is a good sign.