Legacy System Replacement in New Zealand

Why it keeps not happening

The old system works. Not well, and not in any way you would choose again, but it produces invoices and the trucks leave on time. That is exactly what makes it dangerous: there is never a quarter where replacing it beats the other things competing for the same money.

So it waits. Meanwhile the person who understood it retires, the platform stops receiving security updates, the hardware becomes something you cannot buy, and one day it stops being a project and becomes an incident.

If you are reading this before that happens, you are in the good position, whatever it feels like.

The software is not the hard part

Rebuilding the screens is routine. What makes this work expensive is that twenty years of decisions are encoded in the old system, and most were never written down.

Why does that customer type get different freight rules? Why does the month end job have to run before the stock adjustment? Why does one branch use a field for something it was clearly not designed for? Somebody had a good reason in 2011, that reason is still load-bearing, and the only record of it is the code and the memory of whoever has been there longest.

Discovery is not consultants padding an invoice. It is the part that decides whether the replacement works, and any fixed price offered without it is a guess wearing a suit.

Strangle it, do not replace it

The instinct is to build the new system, migrate everything, and switch over a long weekend. It is the approach with the worst record.

The alternative is to put the new system in front of the old one and move functions across one at a time. Invoicing this quarter. Stock next. Reporting after that. Both run together for a while, sharing or syncing data, and each piece is a small release you can undo instead of one enormous one you cannot.

It costs a little more in total and it takes longer. It also means that if the budget runs out, priorities change, or the world does something unexpected, you stop with several functions genuinely improved rather than with a half-built replacement and the old system still limping.

Ask every developer quoting whether an incremental path exists for your system, what the first piece would be, and what that first piece costs on its own. The quality of that answer tells you most of what you need to know.

Decide about the data early

Twenty years of history is rarely worth forcing into a new model. The usual answer is a split: migrate the last two or three years into the new system, and keep the rest in a read-only archive that people can search when they need to.

That decision saves a great deal of money and it has to be made consciously, because the default — migrate everything — is enormously expensive and often nobody questions it until the bill arrives. Ask who needs the old data, how often, and whether "we can look it up if audited" would do.

Consider not building it

Before committing, ask honestly whether your process is actually unusual.

A lot of legacy systems were custom-built in an era when there was no alternative, and the business has since become fairly standard. If a product now does 90% of what you do, buying it beats rebuilding — even allowing for the awkward 10%.

Custom is the right answer when the way you work is the advantage: the scheduling logic nobody else has, the pricing model that wins the contracts, the process your competitors cannot match. Then a product would force you to become ordinary, and building is worth every dollar.

A good consultant will tell you which of those you are, even though one answer is worth far more to them than the other. That willingness is worth testing for.

What to look for in the quotes

• A discovery phase. Paid, time-boxed, and producing something you own — a documented understanding of the current system — whether or not you continue with that developer.
• An incremental plan. With a first slice you could stop after and still be better off.
• A parallel-running answer. Both systems will be live at once for a while. How long, how are they kept consistent, and what does that cost?
• Honesty about the unknown. A range with reasons is more credible than a precise number, and precision this early is the warning sign, not the reassurance.
• Who owns the knowledge. If the same thing must not happen again in fifteen years, documentation and handover cannot be an optional line item.

Describe the system, not the solution

You do not need to know whether to modernise, replace or buy. Describe what the system does, how old it is, what it connects to, and what worries you most. Developers who have done this work will tell you which approach fits — and if they disagree with each other, those disagreements are the most valuable thing you will get out of the process.