What a T3 engine taught me about legacy systems

My VW T3 is a 1989 model. The engine — a normally aspirated diesel known politely as the „1Y" and, on bad days, as „the tractor" — produces 70 horsepower on a good morning. It has no computer, no lambda sensor, no OBD. It has an injection pump, swirl chambers, and what the workshop manual soberly calls „mechanical robustness". If it refuses to start, the cause is one of perhaps twelve things, and eleven of them can be sorted with a wrench of the right size and a little patience.

I'm not invoking this engine for nostalgia. I bring it up because every weekend I crawl under it, it whispers the same thing into my ear that every industrial client tells me on Monday: Old is not broken. Old is just old.

The temptation of the big bang

In industrial IT, I keep meeting one story on loop. It goes like this: „The system is from 2008. We need to replace it." The slide says „modernization", the roadmap says „greenfield approach", and the spreadsheet next to it shows a number that briefly drains the colour from the board's faces before they nod.

Six months later, you sit in a workshop and realize that the old system did things nobody knew it did. A plausibility check an intern wrote one night in 2014 because a supplier kept sending broken records. A mapping that lifts a historic special term for a component into today's classification. A script line without which the entire maintenance report would have been wrong since 2014.

The old system wasn't bad. It had just become invisible — because it worked.

What the engine does differently

When something is wrong with the T3 diesel, I don't first ask whether I need a new engine. I ask which part is wrong. Glow plugs? Injection timing? Clogged primary filter? Each of these parts is replaceable, individually, without touching the rest of the vehicle. Nobody would seriously suggest buying a new bus because injection timing is two degrees off.

In IT, we do exactly that routinely. An application has become slow — so we rebuild it. A module is hard to understand — so we rewrite the system. An interface is causing trouble — so we replace the entire backend. It's as if you'd scrap an entire car because of a bent tie rod.

The difference is not technical. It's a matter of posture. Someone working on a Bus assumes the vehicle is fundamentally fine and has a specific problem. Someone hearing „modernization" in IT assumes the system is fundamentally lost and can only be replaced. Both are usually wrong — but the second assumption is significantly more expensive.

Three symptoms I have learned to read

Over time you develop an ear for when a system is genuinely at its end and when it just lacks proper care. Three symptoms I usually rely on:

1. Nobody dares to touch it anymore.

That's the worst symptom — and it applies equally to diesel injection pumps and to SAP interfaces. When everyone on the team gives a module a wide berth because „last time everything broke", then the module isn't the problem — trust is. Repair here means: rewriting the documentation, setting up a test run, paying someone to walk through the thing calmly over a weekend. That costs less than any rewrite — but nobody gets an award for it.

2. The tools no longer fit.

If I need a special puller for my T3 that's no longer available anywhere, that's a genuine problem — but a solvable one. In software, the same goes: the build chain only runs on an old machine. The compiler is discontinued. The last person who understood the configuration has retired. None of that is, by itself, a reason to replace the system. It's a reason to invest in the toolchain once, instead of yearly in workarounds.

3. Requirements have overtaken the system.

This is the only one of the three that genuinely argues for a rebuild. If the system is supposed to deliver something conceptually different — real-time instead of batch, multi-tenant instead of mono, web instead of client — then repair won't help. But this case is significantly rarer than most modernization slides suggest. In nine out of ten cases, the honest answer is: „We want it prettier. We don't need it different."

What survives the analogy

I'm not a romantic. Sometimes a system genuinely is at its end. Sometimes only a new engine helps — or at least a thoroughly overhauled one with new piston rings, fresh pump, and an honest dyno run. But that step deserves its own decision. It should not be the reflex move the moment someone utters the word „legacy".

What the T3 has taught me is a particular order of questions. Before I throw something away, I want to know what it does. Before I replace it, I want to know what should take its place and why. And before I say „modernization", I want to understand what about the old thing actually hurts — not on the datasheet, but on Monday morning at half past eight, when the plant starts up.

That's not an anti-innovation stance. It's the stance of someone who has lain under a vehicle with oily hands and figured out: the expensive thing is usually not the part. The expensive thing is the unexamined assumption that it must be the part.