When legacy slows the business down, not just the team

Legacy becomes a business problem when it slows decisions

Almost every company has a system people call legacy internally. Age alone is not a catastrophe. The real problem starts when every change takes weeks to agree on, releases scare the team, and the business no longer understands what the next step will cost. At that point legacy hits revenue, deadlines and control — not code aesthetics.

Signals that the system is already holding growth back

• Every new feature drags a cascade of unpredictable edits through neighbouring modules.
• The same bugs come back after releases, although the team "already fixed that".
• Nobody can estimate timelines without a large buffer for surprises.
• Critical knowledge lives in one or two heads instead of documentation and process.
• The business keeps hearing that technical debt must be cleared first, but the result never becomes visible.

Why companies tolerate legacy for too long

Because the system still "kind of works", while a full rewrite looks dangerous and expensive. The business spends years between two extremes: touching the working system feels risky, and every new change makes the situation worse. The answer is rarely the slogan "rewrite everything" — it is a controlled intermediate route: what to stabilise now, what to isolate, and what is ready to move into a new contour.

When one-off fixes are no longer enough

If the product affects sales, documents, customer service, inventory, logistics or internal operations, one-off fixes stop being neutral. They create an illusion of motion while raising the cost of the next change. That is the moment to stop looking at the system as a set of separate bugs and start treating it as an asset with architectural limits, failure points and a hidden cost of ownership.

What to do instead of arguing "rewrite or not"

• Fix where legacy already hits the business: releases, speed of change, incidents, integrations, performance.
• Decide which modules can stay and which should be isolated before the problems grow further.
• Split the first phase into stabilisation and architecture work instead of one giant project.
• Only then choose the format: an SLA, a technical audit, phased modernisation or new development next to the old system.

What the business needs as an outcome

Not a perfect architecture on paper, but a clear route: where risk drops now, where money stops leaking on chaotic changes, and which next step actually pays off. That is what separates real modernisation from an endless fight with symptoms.