Legacy is not the enemy of transformation

Every transformation deck has the same villain: the legacy system. Old, slow, undocumented, held together by one engineer named Klaus who is retiring in March. The proposed hero is always the same too — a clean slate.

I've watched the clean-slate story play out enough times to say this plainly: the rip-and-replace is usually the most expensive mistake on the table.

Legacy is load-bearing

That ugly old system is ugly because it works. Two decades of edge cases, regulation changes and customer quirks are encoded in it — most of them documented nowhere else. When you throw it away, you're not deleting technical debt. You're deleting institutional memory.

Transform the work, not just the tools

The transformations I've seen succeed had a different shape:

• They started with how decisions get made, not which vendor to buy
• They strangled legacy systems gradually, moving one capability at a time
• They kept Klaus in the room — and paid him to explain, not just to maintain
• They measured adoption, not deployment

New software that nobody uses isn't transformation. It's redecoration.

The honest test

Before any replacement project, I ask one question: can you name the behaviour that will change? Not the system — the behaviour. If the answer is a feature list, the project isn't ready. If the answer is "the claims team will stop re-keying data between three screens", now we're transforming something.