Replacing legacy software without downtime

When software becomes legacy

Software does not become legacy because it is old, but because it becomes a brake. The signs are usually recognisable:

• Only one person, inside or outside the business, still really understands the system.
• Every change takes a long time and breaks something else.
• The system runs on an operating system, database or server that no longer gets updates.
• Connecting to new systems, such as a webshop or a portal, is hard or impossible.
• Staff work around it with Excel lists, because the system no longer fits how the business works.

Why a big switch in one go is risky

The temptation is to replace everything at once: build or buy a new system, set a date and switch over on that day. It looks tidy, but the risk lies exactly in that one day. Everything has to work at the same time, all data has to come across correctly in one go, and if something goes wrong, the business stands still.

On top of that, an old system often contains rules that are written down nowhere. They were built in over the years, for a customer or an exception everyone has long forgotten. In a one-go switch those rules only surface when they are missing, and by then the old system is already off.

The alternative: replacing step by step

A safer approach is to replace the system part by part. The new system grows next to the old one and takes over one piece at a time: first, for example, order entry, then planning, then invoicing. The old system keeps running for everything not yet moved, and is only switched off when nothing runs on it any more.

The advantage is that each step is small enough to oversee. If something is not right, you notice it in one part and not in the whole business, and you can go back to the old system while it is fixed.

How it works in practice

What such a project looks like differs per system, but the steps are usually the same:

• Mapping. What does the old system do, who uses which part, and which rules does it contain that are written down nowhere else? This is the moment to bring the unwritten rules to the surface too.
• Ordering. Start with a part that delivers a lot and has few dependencies, so the first step shows value quickly.
• Connecting. The new and the old system exchange data, so both know the same orders, customers and articles during the transition.
• Running side by side. A new part first runs alongside the old one for a while, so the results can be compared before the old part is switched off.
• Switching over and off. Only when a part is proven to work do the users move over and is that part of the old system switched off.

The data deserves its own attention

In a migration most attention often goes to the new software, but the biggest risk usually lies in the data. An old system holds years of customers, orders and articles, with duplicate records, empty fields and inconsistent notation. That data has to be cleaned, converted and checked before it goes into the new system.

Test that conversion early and often, with real data. Let people who know the work check the result: they see straight away that a customer is missing or a price is wrong. And keep the old data, even after the old system is switched off, so you can still look things up later.

People are part of the migration

A new system changes how people work. Involve the users early: they know where the old system falls short, and also what it does well and must not be lost. Switching over part by part helps here too, because people only have to get used to one change at a time instead of everything at once.

How I approach it

I start by mapping what the current system does, including the rules that live only in the code or in someone's head. Then I propose an order in which parts are replaced, and how the old and the new system work together during the transition. You see the plan before any code is written.

I build each part in steps, test it with real data and let it run alongside the old system before the old part is switched off. That way your business keeps running while the software is renewed. After delivery I stay available for maintenance.

Frequently asked questions

Can the old system keep running during the replacement?

Yes, that is exactly the point of replacing it part by part. The old system stays in use for everything not yet moved, and is only switched off when nothing runs on it any more.

What if nobody knows exactly what the old system does any more?

That happens often. The system's behaviour is then worked out from the code, the database and conversations with the people who use it. It takes time, but it is better for those rules to surface beforehand than after the switch.

Do I have to replace everything at once?

No. It is often wise to start with the part that pinches most, and do the rest later. In a free 30-minute introductory call I look with you at your system and where a first step delivers the most.