Every company has a "legacy system". An 8-year-old internal portal. A 12-year-old integration service. An accounting bridge that someone wrote once and then forgot about. It works — but nobody wants to touch it.

Then one day something shifts: a new feature is needed, performance slows down, the original developer leaves, a security audit comes back mediocre. In a meeting someone asks: "Should we just rewrite it?"

This post isn't here to answer that question — it's here to help you ask the right one.

The seduction of "let's start from scratch"

Engineers love rewrites. The old code is messy, someone else made the decisions, there's no documentation. A rewrite would be clean, modern, finally make sense — and half the team would be happy about it.

This feeling is usually a mistake. Much of the complexity in old code reflects not bad coding, but the messiness of the real world:

• Checks added for edge cases that exploded over the years.
• Special-case rules added because "Customer X needs this calculation in that scenario".
• Integrations that were supposed to be one-off and became permanent.
• Audit logs added because regulators required them.

In a rewrite, all these rules need to be rediscovered. Typically the new system lags behind the old for a year or two.

We've seen many rewrite projects where:

• 12 months was promised, 30 months were spent.
• When the new version went live, a meaningful chunk of features were missing.
• Customers had to use both systems in parallel.
• The old system kept running for another year.

When does a rewrite actually make sense?

There are situations where starting from scratch is right, but they're rarer than you'd think:

• The technology stack is genuinely dead. Developers can't be found, libraries no longer receive updates, security holes can't be patched.
• The architecture is blocking the business. The system was built as a monolith, but now several teams need to change the same code. Refactoring alone won't fix it.
• The data model is fundamentally wrong. There's a single "Customer" table, but in reality there are three different concepts. Every query is contorted around this.
• The product vision has changed. The system was built for B2B, the company is now B2C-first. Adapting it is harder than starting over.

If two or more of these are true, a rewrite is worth discussing. If it's just "the code is ugly" — it isn't.

Incremental modernisation: usually the right path

In most situations the right answer is "neither" — you change the legacy system piece by piece. New features are written around the old system, and old parts are retired over time.

In practice it looks like this:

1. A gateway is placed in front of the legacy system. Every request goes through the new layer and is routed to the old one when needed.
2. New features are written in the new architecture. Development speed picks up in the new layer.
3. Old parts are replaced one at a time. One module is "payments", another is "reporting"... each is its own project.
4. Traffic is shifted gradually. A new module goes live in production and takes over from its old counterpart.
5. The old part is retired. Only deleted once you're sure nothing depends on it.

The advantage: at every stage you have a working system. Risk is spread out and manageable. The business side never experiences a minute of downtime.

The disadvantage: it requires more discipline. "Run both systems at once" is its own kind of complexity. You carry the cost of two systems in the short term.

"Should we do this at all?" comes first

Before the modernisation conversation, there's an earlier question: should you be doing this yourself?

Many modules that were custom-built years ago can today be replaced with off-the-shelf SaaS. If you've been maintaining something for years, either it's a real competitive advantage or it's just a burden. If it's the latter, the conversation isn't modernisation — it's outsourcing.

Two questions to ask:

• Is this software a strategic differentiator for us?
• If we were starting today, would we still build it ourselves?

If both answers are "no", the discussion should be about replacing it with a packaged solution, not modernising it.

Three common traps

1. A "rewrite" plan secretly wrapped around a big new feature. When rewrite talks start, new feature requests usually get bundled in. This multiplies the project's risk. Pick one: modernisation OR new features — both at once rarely succeeds.

2. Killing the old system before the new one is ready. The old system is psychologically uncomfortable, but it's still producing. Don't rush retirement until the new system is fully stable.

3. Starting without documenting the legacy first. If the original developer is gone, the first step is to capture what the system actually does, then modernise. Rewriting an unknown system is twice as risky.

A practical decision framework

Answer these in order:

• Is the legacy system currently producing value?
• Is it possible to add new features but slow? (If it isn't possible at all, that's a different conversation.)
• Can developers be found?
• Is the architecture really blocking the business, or just aesthetically uncomfortable?
• If you were starting from zero today, would you choose the same architecture?

The answers usually clarify whether incremental modernisation or full rewrite is right. In most cases, incremental wins.

Closing

The urge to escape an old system is natural. But "escaping" and "changing" are different things. You usually don't need to escape — you just need to change the right piece at the right time.

If you'd like to talk this through, our discovery phase is free. We help decide what should change and what should stay in your current system. Reach us via the contact page.