Should you replace your system, or put AI on top of it?

The short answer

Separate two complaints that sound identical when people describe them. The first is that the system does not hold what the organisation needs, which is a data problem and usually does mean building something new. The second is that the system holds it perfectly well but getting an answer requires somebody to log in, run an export, and spend an afternoon in a spreadsheet, which is an access problem and almost never justifies a replacement. The second complaint is far more common, and it is routinely answered with a proposal to rebuild, because rebuilding is what software firms sell. If the records are right and the problem is that nobody can reach them, replacing the system throws away years of accumulated data and process to solve something a layer on top solves in weeks.

What putting AI on top actually means

Stripped of the marketing, it means a layer that reads your existing databases, understands the questions your people ask in the words they use, and answers from the real records rather than from a model's general knowledge. The system underneath does not change. Staff keep entering data where they always did, the existing reports keep working, and nothing in the daily routine moves. What changes is that a director can ask which districts have not submitted this quarter and get an answer in seconds, rather than asking an analyst who asks four system owners. The important architectural point is that the layer is a reader. It does not own the data, it does not become the place records live, and if you switch it off next year everything underneath carries on exactly as before. That property is what makes it a low-risk thing to try.

When replacing is genuinely the right call

There are real cases for a rebuild, and pretending otherwise would be dishonest. If the data you need was never captured, no layer can invent it, and the honest answer is that you need a system that collects it. If the platform is on a runtime that no longer receives security updates, you are running an unpatched service holding your records and the clock is against you regardless of how well it works today. If the vendor is gone, the source code is unavailable and nobody can change anything, you do not have a system you own, you have one you are borrowing from the past. And if the process the system encodes has fundamentally changed, a layer that faithfully reports the old process is worse than useless because it produces confident answers about a reality that no longer exists.

• The data you need was never captured in the first place
• The platform is unsupported and cannot be patched
• Nobody can modify it, because the source or the skills are gone
• The underlying process has changed so much that the records describe a different organisation

When a layer on top is the right call

The layer wins in the situation most organisations are actually in, which is that they own several systems that each work, that none of them talk to each other, and that answering a cross-cutting question means logging into four places and reconciling by hand. In that position a rebuild is not only expensive, it is risky in a way that is easy to underestimate: you are migrating live records, retraining every user, and running two versions of the truth during the cutover, all to reach a state where you can answer questions you could have answered without touching the systems at all. The layer also has a property a rebuild does not, which is that it can be abandoned cheaply. If it does not deliver, you stop paying for it and nothing else is affected.

• Several systems that work individually but do not talk to each other
• The records are correct, but reaching them takes an export and an afternoon
• Leadership asks questions nobody can answer quickly, so decisions wait
• A rebuild would mean migrating live data you cannot afford to disturb

The question nobody asks early enough: where does the data go

This is the question that should be asked in the first meeting and is usually asked in the last one, when changing the answer is expensive. Some of this work can run entirely on infrastructure you control, so no record ever leaves your building. Some of it sends data to a model hosted elsewhere, which may be perfectly acceptable for an internal helpdesk and completely unacceptable for citizen records or clinical data. The two options cost different amounts and perform differently, so the decision has to be made before the architecture, not bolted on afterwards. For any government or health deployment in Uganda, assume the answer has to be that the data stays put, and make any vendor tell you precisely which components would send anything outward and what those components would send. A vendor who cannot answer that at the level of the individual request has not thought about it.

What it costs, and how to start without committing

Connecting or upgrading systems you already own starts around UGX 15 million and runs to roughly 60 million depending on how many systems are involved, whether they expose interfaces or only a database, and whether permissions have to be inherited from the systems underneath so that people only ever see what they were already allowed to see. A full replacement of a working operational system generally starts several times higher and carries migration risk on top. The sensible way in is to pick one question that currently takes a person a day to answer, build the layer for that question only, and run it for a month against the real data. If it saves the day, extend it. If it does not, you have spent a fraction of a rebuild to find out, and every system you own is exactly where you left it.

• Pick the single question that currently costs someone the most time
• Build the layer for that question against real data, not a demo set
• Run it for a month with the people who ask the question
• Extend only what proved itself, and only then