A full rewrite is tempting. But when is it actually justified?

Few sentences promise as much relief inside a difficult system as this one:

"Let's just rewrite it."

It is entirely understandable that the thought comes up after a while.

The old system is hard to change. The code is hard to understand. Every modification brings new defects with it. Developers touch it carefully, and management sees more and more time and money going into the same problem.

A rewrite looks like a clean slate.

Over the past years, though, I have seen that a full rewrite is often not the solution to the problem, but the wish to escape it.

Sometimes it really is the best route. But that cannot be decided on the grounds that the current code is unpleasant or old.

The old system usually knows more than is written down

A working business system accumulates a great many rules, exceptions and adaptations over the years.

Some of it is in the documentation. Much of the rest exists only in the code, the database, the integrations, or in the heads of a few experienced people.

A rewrite means rebuilding more than the visible features. You also have to understand which implicit expectations the system serves.

Who uses each piece of data? Which partner expects which format? Which rare but important exceptions exist? What happens after a failed processing run? In which process does the business accept manual intervention?

These questions rarely surface at the start of the project. They surface when the new system looks finished, and it turns out something important is still missing.

When the old system lives on beside the new one

A full rewrite almost never means switching the old system off one day and the new one on the next.

In reality the two systems often run in parallel for months or years.

Meanwhile data has to be moved, integrations kept alive, differing behaviours reconciled, and users have to cope with two systems at once.

That is not an argument against rewriting in itself. But it is important to recognise that building the new system is only one part of the work.

The other part is the transition: how does the business keep running while the system changes underneath it?

When can a full rewrite be justified?

A full rewrite can be a sensible decision when the current system's fundamental limits can no longer be handled with targeted changes.

For example:

• the system's core data model can no longer support how the business works;
• security or compliance requirements cannot reasonably be met;
• the system is built on a technology environment that can no longer be operated safely;
• critical parts of it depend on a single person's knowledge;
• performance or availability limits cannot be removed incrementally;
• the structure of the system makes every further change disproportionately risky;
• the product's business direction has fundamentally changed and the current system no longer fits it.

Even in these cases the next step is not to start rebuilding immediately.

First you have to understand whether the whole system genuinely needs replacing, or only one critical part of it.

Three dangerous myths about rewriting

"The new system will be faster"

It might be — but new technology on its own does not fix poorly understood business rules, uncertain priorities or inadequate testing.

A new system is perfectly capable of recreating the same bad decisions with more modern tools.

"Now we know what to build"

Often it is during the rewrite that you discover you do not know precisely.

The old system's flaws and limits are visible, but that does not mean it is clear what the business will need five years from now.

If the requirements keep changing, a large, long project becomes especially risky.

"Everything will be better in the new system"

That is a wish rather than a plan.

The new system will be better if we define in advance what better means: faster releases, fewer defects, easier operations, better scalability or simpler integrations.

If those are not stated and made measurable, the new system ends up being evaluated on impressions.

Incremental modernisation is often the lower risk

In many cases you do not have to replace everything at once.

It may be worth:

• separating out a critical module;
• replacing an old integration gradually;
• covering the most important business process with new tests;
• building a new interface on top of the existing system;
• reshaping part of the database step by step;
• fixing the release and observability process first.

These changes are not as spectacular as announcing an entire new platform.

In exchange they give feedback sooner, carry less business risk, and help you understand which direction is worth taking.

I have been in several situations where the first targeted change made it clear that a full rewrite was not needed at all. In others, it was precisely a gradual modernisation that showed one part of the system genuinely could not be saved for a reasonable cost.

The order matters.

Four questions before a rewrite

Before management commits to a full rewrite, four questions are worth answering.

What is the specific business problem the new system has to solve?

If the only answer is "the old system is bad", the starting point is not there yet.

Which limit cannot be removed with a targeted change?

The whole system does not have to be bad. It may be that a single structural problem is blocking the work.

How does the business keep running during the transition?

Migration, data handling, integrations and rollback options are not later details. They are part of the decision.

How will we know the new system actually turned out better?

"More modern" is not an outcome in itself. You have to define which business and technical measures you expect to improve.

This is not about defending the old system

Rejecting a full rewrite does not mean every old system should be defended.

Some systems no longer serve the business properly, and patching them only increases cost and risk further.

The question is not whether the system is old or new.

The question is:

• what is blocking the work now;
• which limits can be dealt with;
• what risk the change carries;
• and which route gives the best result within the available time and resources.

That is why I prefer not to decide on a full rewrite on either technical or emotional grounds.

First you have to understand the current system, how the business works, and the real constraints. Only then can you decide whether targeted modernisation, gradual replacement or genuinely a new system is needed.

A full rewrite is sometimes the best decision.

But only when it is chosen not because the current system is unpleasant to work with, but because it is demonstrably the lowest-risk route with the best return.