Legacy System Modernisation and Integration

The system nobody wants to touch

Nearly every institution of any age has one. A core the bank has run since before it was the size it is now. A member system a SACCO's staff wrote when it had three branches. A billing platform a telco has added to for a decade. It works. It has never lost anyone's money. And it is why the answer to most new proposals is that it would be difficult.

Two things sharpen this here. Institutions across Tanzania and the region have added members, districts, products and channels faster than the systems bought to run them were meant to carry. And the people who built those systems have moved on, often to larger institutions or abroad, so the pool who understand a platform of that age keeps thinning. The vendor, if there was one, may have been acquired or left the market.

The constraint rarely announces itself as a failure. It appears as a product that cannot be changed before a competitor launches something similar. A partner turned away because connecting them is not worth the risk. It bites hardest where growth now needs something the system was never asked to do: banks adding channels to a platform built for branches, SACCOs and microfinance institutions whose members now do everything from a phone, telcos and fintechs launching faster than what sits behind them allows.

Replace it, work around it, or change it while it runs

Outright replacement is proposed first, because it sounds decisive and a board can picture it. It is also where institutions get hurt. Money is committed before much is genuinely known. The business sees nothing for a long stretch in the middle. The risk of the whole programme lands on one date, and everything the old system quietly did that nobody wrote down is discovered on that date. Sponsors, strategy and suppliers all change over a programme that long. These fail late, after most of the budget has gone.

The second option is to leave it alone and work around it, which is what most institutions do without ever deciding to. Every new initiative goes beside the old system rather than through it. Each decision is cheap and defensible on its own. The constraint never goes, and removing it gets dearer every year as more of the business comes to depend on the shape of the thing you were avoiding.

The third is to change it progressively while it keeps running, in pieces that can each be judged, funded and stopped on their own. It puts benefit into the business early and does not stake the programme on one weekend. What it asks of you is patience with a period where old and new both exist, and the discipline to carry on once the worst constraint has been lifted and the urgency has left the room. Replacement is occasionally right, and sometimes the right answer is not to start yet.

What changes, and who feels it

Your own staff notice first, because they absorb the constraint today. Work done twice because two systems hold the same thing differently. A month end that takes a weekend. A question from the board that takes days to answer and never the same way twice. Customers meet it indirectly, as the wait for a product they asked about or a fee quoted in one place that does not match what they were charged in another. Old systems reach customers as inconsistency more often than as outage.

Most institutions come to this because one thing was blocked: a channel, a partner, a product, a report somebody was obliged to produce. That is a good reason to start and a poor reason to stop once it is unblocked, because the work sits under the products you run today and the ones you have not committed to yet. One outcome is worth naming. By the end, what the system does, and why, is written down and belongs to you.

The people who know the old system

The scarcest asset here is not money. It is the two or three people who can say why a rule exists, what depends on it, and what broke the last time somebody changed it. They are not always senior and often not in the technology team. What they hold is rarely written down. If one of them leaves mid-programme the cost lands at once, and if any are near retirement that clock is already running.

The same people can be the strongest resistance, and not unreasonably. A programme that reads as replacing the system they are the acknowledged expert in carries a personal cost. It seldom appears as objection. It appears as the session that cannot be scheduled and the detail that surfaces late. Being straight with them early about their role afterwards is worth more than any amount of communication planning. They are also the people keeping the old system running, and that job does not pause, so their time has to be protected and their day work covered.

What has to be settled on your side

Start with appetite. How much disruption will the institution actually accept, and who can hold that position when it is tested rather than when it is agreed. Alongside it, the things that may not be interrupted: salary dates, month end, statutory reporting, the collection days a lending book depends on. Finding those late is an expensive way to learn them.

Then your existing agreements. What you own and what you licence, what support you are entitled to and what you would be asking for as a favour, notice periods, and what happens to your data if a relationship ends. There is an awkwardness worth planning for: you may be asking a supplier to help you depend on them less. This is a legal and procurement matter, and often the longest lead time.

Then the in-between period, where optimistic plans come apart. For a stretch old and new both exist, and that costs money, attention and staff hours already spoken for. Somebody in operations and finance owns the position while both are live. You also need a view on how much history comes with you, which turns on your retention obligations and what the business needs to see.

Finally the money. The case here is defensive. It removes a constraint rather than adding a product, so the return arrives as costs that stop and options that open rather than as a revenue line a committee can point at. The version that succeeds names what is blocked today and what each of those is worth, and is honest about the exposure if the people who understand the system leave.

How an engagement runs

Discovery here is substantial rather than a formality, because it usually produces the first honest account anyone has had of what the system does today. Out of it come a recommendation on which route fits, a scope and a plan. The plan is yours whether or not we build it.

Through delivery you see working software in an environment you control rather than status reports. Source code and documentation are yours from the first commit. Afterwards we support what we built and train your people to take on as much of it as they want. There is no lock-in, by design and by contract, which matters more here than anywhere: the point is to stop depending on somebody who has already left.