# Replace or modernise? What to do with old business software

*Web page: https://kweepa.com/insights/modernise-legacy-software-kenya · Published 2026-11-01 · Updated 2026-11-01 · 7 min read*

> A system that still works is not the same as a system you can keep. How to tell, and how to change it in stages while the business carries on.

**Who it is for:** any business

## Signs you have a legacy system

Old is not the problem. A system is legacy when the cost and risk of keeping it rise faster than the value you get from it. For a business in Kenya the first signs are often that it cannot take M-Pesa, cannot connect to online services and lives on one computer that nobody dares to touch.

- It runs on an operating system, language or database that is no longer supported.
- It began as an Excel spreadsheet or an Access database and grew into the main system, with macros that one person wrote. Moving it to a web app is one way out.
- One person, or nobody, really understands how it works.
- It cannot connect to what the business now needs, such as M-Pesa, online orders or another system.
- Reports are made by exporting to a spreadsheet and fixing it by hand.
- Security updates cannot be applied, or are put off for fear of breaking it.
- The vendor has gone, or will not change it.
- It runs on one old computer, and that computer is the single point of failure.

## Four options

A business often ends up using more than one, for different parts of the system. A replacement is only one of the four.

**Four options**

| Option | What it means | Works when | Watch out for |
|---|---|---|---|
| Keep and look after it | Fix, secure and back it up, and change nothing else. | It does the job, nothing in the business is about to change, and someone understands it. | Costs and risk that rise quietly, and the day the one person leaves. |
| Wrap it | Leave the core as it is and put a modern front, such as a web page or an API, around it. | The core works but cannot reach new channels, devices or other systems. | It keeps the old core's limits, and the wrapper depends on it. |
| Modernise in stages | Replace it piece by piece, beside the old system, moving one function at a time. | The system is large, the business cannot stop and the risk must be spread. | It takes planning, and for a while two systems run side by side. |
| Replace it | Move to another product or a new build, all at once. | The old system is small, or a product fits well and the data is clean. | The rules nobody wrote down, and a cutover day that cannot be undone. |

## Why a full rewrite is risky

A rewrite looks clean. The trouble is that the old system holds years of rules that were added when someone found a case, and nobody wrote them down. A new system built from a specification will miss some of them, and customers will find them first.

1. **Build a new piece beside the old**: One function at a time, starting with one that is useful and low risk.
2. **Keep the data in step**: The old and new parts read and write the same records, or are kept in step.
3. **Move users across**: A few people first, then everyone, with the old part still there to go back to.
4. **Switch off the old part**: Only when the new one has proved itself on real work.

> **The business keeps running** The point of doing it in stages is that there is never a day when everything changes at once, and a mistake is small and can be reversed.

## Before anything: find out what it does

You cannot move what you cannot describe.

### Step 1: List what it does and who depends on it

Every function, every report, every other system that reads from it or writes to it, and every person who uses it.

### Step 2: Capture the rules

Read the reports, the code if you have it, and ask the people who use it what they do when something unusual happens.

### Step 3: Back it up and test the restore

Before you change anything, prove that you can bring the system back from a backup.

### Step 4: Record how it behaves now

Keep reports and totals from today, so that you can compare the new system with the old one afterwards.

### Step 5: Decide what must not change

Some behaviour is a legal or contractual duty. Write it down and protect it.

## Moving the data

Use this data migration checklist. The data is usually worth more than the program, and harder to move than it looks.

- **Clean before you move.** Duplicates, missing fields and wrong dates do not improve by being copied.
- **Map every field.** What is each old field called in the new system, and what does it mean? Some will have meant different things over the years.
- **Move a copy first.** Try the move on a copy and look at the result before the real one.
- **Reconcile the totals.** Counts and sums in the new system should equal the old system's, field by field, before anyone uses it.
- **Run both for a while.** Compare results on real work until they agree.
- **Keep the old data readable.** Keep it, read-only, for as long as you may need to answer a question about the past.

> **The day of the cutover** Choose a quiet day, have a plan to go back, and decide beforehand what would make you use it.

## Questions to ask a company

These tell you whether they have done it before.

- How will you find out what the old system does, and who will you ask?
- Can you do it in stages, and what would the first stage be?
- How will old and new be kept in step while both are running?
- How will you prove the data has moved correctly?
- What is the plan if something goes wrong on the day?
- Who owns the new code and the accounts it runs in?
- Will you leave documentation for the next team?

## Keep reading

- [Legacy system modernisation](https://kweepa.com/services/modernisation): Old systems rebuilt or moved to new ones while the business keeps running on them.
- [Custom software or off-the-shelf: how to decide](https://kweepa.com/insights/custom-software-or-off-the-shelf): Should you build custom software or buy a ready-made product? How to decide, the signs that each has stopped working, and how to cut the risk of building.
- [How much does custom software or an app cost in Kenya?](https://kweepa.com/insights/software-development-cost-kenya): What decides the price of custom software and apps in Kenya, three ways projects are priced, and how to get quotes you can compare. No made-up figures.
- [Talk to us about your project](https://kweepa.com/contact?service=modernisation)

## Questions people ask

### What is legacy system modernisation?

It is changing an old system so that it can be supported, secured and connected to what the business now needs, without stopping the business. It can mean wrapping the old system, replacing it piece by piece, or moving to a new one.

### Should I rewrite my old software from scratch?

Usually not all at once. A full rewrite tends to miss rules that the old system learned over years, and has a cutover day that cannot easily be undone. Doing it in stages spreads the risk.

### How do I modernise software without stopping the business?

Build the new piece beside the old one, keep the data in step, move a few users first, then everyone, and switch off the old part only when the new one has proved itself.

### How do I migrate data from an old system?

Clean it, map every old field to a new one, try the move on a copy, reconcile counts and totals against the old system, run both for a while, and keep the old data readable afterwards.

### Can an old desktop system be moved to the web?

Often, yes. The usual way is to put an API around the old core, build web screens on it, and move functions across a piece at a time.

### How do I know when a system needs replacing?

When it cannot be supported or secured, nobody understands it, it cannot connect to what the business needs, or the cost of keeping it rises faster than its value.

## Next step

Talk to us: https://kweepa.com/contact?service=modernisation · Email: ops@kweepa.com
Publisher: Kweepa Technologies, Nakuru, Kenya (https://kweepa.com/)