Legacy system modernization

Replacing an ageing system a part at a time while it keeps running, so the work you depend on is never switched off all at once.

Write a brief Book a meeting

What the work touches

A modernization reaches past the code into what the system does for the business and who relies on it. These are the parts it usually involves.

Reading what it does: Finding out what the system really does today, including behaviour nobody wrote down and rules no document explains.
Picking the first piece: Choosing a part small enough to replace safely and important enough to be worth replacing first.
Running both at once: Keeping the old system live beside the new part, so one feeds the other until the new one is trusted.
Checking the two agree: Comparing what the new part produces against the old one on the same inputs, before anyone relies on it.
Data that moves across: Moving the records a replaced part needs, and checking they arrive matching what the old system held.
A way back: Keeping a tested route back to the old part, so a problem found after a switch does not strand you.
Handover: Your own people are left able to run the new parts and to take on the next piece.

Why a full rewrite is the risky path

The common plan is to build a replacement alongside the old system and switch everything over on one date. That date tends to slip, because the old system turns out to do more than anyone remembered, and the parts that were never documented are often the ones the business quietly depends on. While the rewrite runs, the old system still needs changes, so the target keeps moving and two teams end up maintaining two versions of the same thing.

The approach that holds up replaces one part at a time while the old system keeps running. A piece is built and then run beside the original on the same inputs, so its output can be measured against what the old system already produces. Once the two agree, traffic moves to the new part, and a tested route back to the old one is kept ready in case a problem shows up after the switch. Each step is proven, or reversed, before the next one starts.

Most of the effort goes into reading the old system closely, because the behaviour that is hardest to see is often what the business depends on most. The comparison checks between old and new are written as part of each step, by the same person who planned it, so the evidence that a part is ready exists before anyone is asked to trust it.

How to start

The brief

Say what the system does and which parts you cannot afford to break. Mention any date by which the old system has to stop.

Starting small

Work usually opens with one part replaced and run beside the old system on your real inputs, so you can weigh the approach before committing to the rest.

Who does the work

Amos Weiskopf has written software for more than twenty years, and he can build each replacement part himself.

Questions buyers ask

What is legacy system modernization?

It is replacing an ageing software system in stages while it keeps running. Each replaced part is run beside the old system and checked against it before anyone relies on the new one.

How much does legacy system modernization cost?

It turns mainly on how much the system does and how many parts have to be replaced. The price is agreed once the written brief is in.

Why replace the system in stages?

A single switch-over tends to slip once the old system turns out to do more than anyone recorded, and the old system still needs changes while a rewrite runs. Replacing one part at a time keeps the business running and lets each step prove itself before the next.

Who runs the new parts once they are in?

Your own people. Each replaced part is built to be run by your team, and the handover leaves them ready to take on the next piece.

What happens if a replaced part fails after the switch?

A tested route back to the old part is prepared before each switch, so a fault that appears later does not strand you. The old system stays live until the new part has earned the traffic.

How do you know the new part matches the old one?

The new part is run beside the old one on the same inputs and the two outputs are compared. Only when they agree does the new part take over.

Engagements by written brief.

Work begins from a documented problem statement, not a sales call.

Write a brief Or book a meeting