Rewriting is not modernizing

There comes a point in almost every old system when someone proposes the inevitable: «let’s just rewrite it from scratch». The idea is seductive. The current code is scary, nobody remembers why it does what it does, and a blank slate promises to get it right this time. It’s almost always the wrong call.

What the old code knows and you don’t

A system in production, however ugly, has spent years accumulating something written down nowhere: every odd case the real business ever demanded of it. Every strange branch, every validation that looks arbitrary, is usually the scar of a concrete problem someone solved.

When you rewrite from scratch, you throw that knowledge away and commit to rediscovering it —bug by bug, complaint by complaint— while the old system keeps running and shifting under your feet.

Rewriting is a bet that you’ll reach the starting line before the world moves. You rarely win that race.

Modernizing is replacing in pieces

Real modernization is rarely an event; it’s a process. You isolate a piece, wrap it in a clear boundary, replace it, and only then move to the next — with the system delivering value the entire time. It’s less heroic than the grand relaunch and far less risky.

It isn’t always the answer. Some systems are so small or so dead that rewriting is the sensible move. But that should be a conclusion you reach by measuring, not the first impulse in front of a file you’re afraid to open.