Legacy modernization services

There is a part of the system nobody wants to open. It works. It has worked for years. The people who built it have moved on, and what it does is now known only by the fact that nothing has fallen over yet.

Every change near it is quoted in weeks, and half of that is fear.

First it gets written down, then it gets changed. What the system does today is recorded before anyone forms an opinion about what it should do. You cannot safely remove what is not written down.

Then it moves in small steps, with production live the whole time. A target architecture is not by itself a reason to rewrite: each step has to pay for itself, and each step has to be reversible on its own.

What does not hurt enough is left alone. Two message buses side by side are cheaper than one bus and an adapter nobody owns. Modernization that unifies for the sake of the diagram makes the estate tidier and the team no faster.

A system that keeps serving customers while it changes, with near-zero downtime. Steps that can be stopped at any point: each has a backup plan, so the estate is never left half-converted.

Fifty-odd applications assembled between 2005 and 2010, and five people for all of them. More than sixty percent was rewritten, moved or rebuilt — in steps, with incidents staying quiet.

Then the environment changed its requirements and the whole estate had to move. The applications themselves barely shifted: one thin layer changed, the same way for everyone it touched. The first change was made by the most expensive person on the team; the rest repeated it by the cheapest.

Not a rewrite. Not a migration with a freeze. Not a promise that everything ends up looking the same — some of it deliberately will not.

Two things: which part is expensive to touch, and one number you can measure — hours, money, failure rate, missed SLA. That number is how we both see later whether it worked.