You can replace a legacy system without a risky rewrite by moving it one capability at a time while the old platform keeps running. Putti, an Auckland software company, puts a new interface in front of the old system, then retires it piece by piece until nothing depends on it.
Why does a big-bang rewrite go wrong?
A rewrite has to match everything the old system does before anyone can switch over, and nobody knows everything it does. A system that's run for ten years has picked up business rules nobody wrote down: a discount that only applies on the first of the month, a report one accountant relies on, a nightly job that quietly fixes a data problem upstream.
The team finds those rules on cutover day, when the old system is frozen and most of the budget is spent. The first real test of the new system is also the moment you depend on it.
What does replacing it in stages look like?
Stabilise first, then replace behind a new front door. Engineers call the approach the strangler pattern: a new layer grows around the old system and takes over its jobs one at a time, until the old one has nothing left to do.
In practice it runs in four steps.
- Review and document. An independent code review ranks the risks, from unpatched dependencies to modules nobody can explain. We write down how the system really behaves, not how the original spec said it would.
- Stabilise. Close the security gaps and fix whatever is likely to fall over, so the business isn't gambling while the work happens.
- Put the new interface in front. Requests go through a layer you control. At first it passes everything straight to the old system, so nothing changes for your staff or customers.
- Move one capability at a time. Invoicing, reporting or customer accounts goes first, depending on where the pain or the risk is highest. Each one goes live, gets used for real, and is signed off before the next begins.
Which capability should move first?
The one that hurts most and is easiest to separate. Often that's reporting, because it only reads data and can't break a transaction, or a customer-facing portal the old system handles badly. Something that touches payments or stock levels usually waits until the team has proved the approach on lower-risk work.
It's also worth looking at what the old system connects to. A systems integration layer lets the new pieces and the old platform share data in the meantime, so staff never have to key the same thing into two places.
How long does it take, and what does it disrupt?
Several months to a year is common for a business-critical system, but you're not waiting for the end of it. Each stage ships as it's finished, so the business has something usable long before the last one.
The disruption stays small because the old platform keeps carrying the load until a stage has proved itself. Nobody's asked to trust a cutover weekend.
What if the original developer has gone?
Often it's still workable. The question is what you can reach: the code, the servers, the hosting and domain accounts, even an old handover email. If you're in that spot, our guide to taking over a project when the developer disappears covers the first two weeks.
Writing down how the system really behaves is worth doing even if you never replace a line of it.
When is it better to leave the old system alone?
Not every old system needs replacing. If it's patched, somebody understands it and it isn't blocking anything, keep it and maintain it properly. The case for moving gets strong when the platform stops receiving security fixes, when the knowledge sits in one person's head, or when you want to connect something it can't talk to, such as AI that works with your existing software.
Talk to Putti about moving off a legacy system
Putti has delivered 100+ projects since 2010 with zero failures for clients including Spark, Hilton and Fletcher Building, and we've rescued 20+ projects that other teams couldn't finish. Hirepool's customer service platform cut contract creation time by up to 80%, and BarberShop Co's queueing platform now runs across 20+ NZ locations.
Our work is led by senior engineers in Auckland and built by our own employed team, never outsourced or subcontracted. If you've got a system the business depends on and nobody wants to touch, talk to us about a review. You can also read how we approach legacy system support and re-platforming.