Legacy software is a debt that grows with your volumes

Summary

Software that worked at launch often struggles as transactions grow: payments time out, reports slow everything else, and each change risks breaking something. Replacing everything at once is rarely the answer. We recommend separating the parts, connecting them through documented interfaces, and replacing the costliest first.

The problem

Many organisations run on an application written for the volumes of several years ago, or on an off-the-shelf package bent to fit with plug-ins and workarounds. It works, until volumes rise.

Then the symptoms appear together. Month-end reports slow the system down for everyone else. Payment confirmations from a gateway time out and have to be matched by hand. A change in one place breaks something in another, so changes stop being made. The people who understood the code have moved on, and each workaround makes the next one harder.

This is a debt, and it charges interest: in staff time, in failed or duplicated transactions, and in what the organisation cannot do, such as adding a payment channel, a branch or a second currency without a long and risky project.

What was done

A full rewrite is tempting, and it is usually the riskiest option. We replace the system in parts, while it keeps running.

1. Measure before changing anything. We find which parts fail under load, which are changed most often, and which hold the data that matters most. That tells us where to start.

2. Put a documented interface in front of the old system. Other parts of the business talk to it through one agreed API instead of reaching into its database. From then on, a part behind the interface can be replaced without the others noticing.

3. Replace the costliest part first. Often that is payments or reporting. Each payment notification from a gateway is recorded as it arrives and processed again if a step fails, instead of being lost. Reports read from a copy of the database, so they no longer slow down the daily work.

4. Build with tools that others can maintain. We use widely supported frameworks, such as Laravel behind the scenes and React or Vue on screen, with automated tests and monitoring, so that your own team, or another firm, can look after what was built.

5. Hand over the keys. We document each part, train your team and stay until they can run and change the system without us.

The result

Each part can change without breaking the others, payment notifications are recorded and processed instead of lost, and your own team can maintain what was built.