Start Killing Legacy

Old systems survive because nobody knows what they do. That was always the whole trap, and it just opened.

1 min read

Nobody chooses to keep a legacy system. It stays the way water stays in a cellar: not because someone decided, but because nobody decided otherwise.

Its cost was never the license or the server. The cost is the ring of things that exist only to keep it breathing. A scheduler nobody else uses. A file that moves at 04:00 for no living reason. A database frozen four releases back, and the support contract that freeze demands. And then the newer sin: every application built since has had to bend toward it. Adapters, translation layers, an export in a format from 2004, because the old thing cannot meet anything halfway. You do not maintain a legacy system. You keep bolting new ones onto it, and it spreads into everything that comes after, through the interfaces.

It survives because nobody knows what it does. Its purpose is known. Its behavior is not: which of the forty branches still fire, what the exception written in 2011 was protecting. The documentation described the system we intended. The code describes the one we got. The people who could tell the difference retired.

So the estimate carries a band of uncertainty no committee will sign, and every year we pay the ring instead, because a large known price is easier to defend than an unknown one. That was the whole trap. It just opened.

The hard part was never writing the replacement. It was reading the original. Reading is now cheap. A model will not hand you a new system, but it will hand you, in days, what the old one actually does, and that was the number the entire decision hung on.

Nothing about the system has changed. Only the price of understanding it.

Start killing it.