“We need a rebuild” is often where the conversation starts.

That does not mean it is the right place to make the decision.

In many teams, rebuild is really a label for discomfort with the current system. Change feels slow. Releases feel risky. The CMS has become harder to manage. Integrations are fragile. The content model is inconsistent. Confidence in the current setup starts to drop.

Those are real problems. But they do not all point to the same solution.

Before deciding what to do next, it helps to define the options clearly:

• Rebuild: a broader change driven by business needs the current system can no longer support
• Refactor: improving the existing codebase without changing external behaviour
• Replatform: moving to a different platform because the current one has become a constraint

These are not interchangeable. They solve different problems.

A practical checklist

If your team is discussing a rebuild, ask:

• Are releases slow, difficult, or hard to predict?
• Are integrations fragile enough that small changes create knock-on issues?
• Is the content model messy, inconsistent, or difficult to extend?
• Do new features introduce regressions elsewhere?
• Are performance issues becoming harder to control?
• Is confidence in security or compliance starting to fall?

If several of these are true, you probably do need to act.

The next question is: what kind of problem are you dealing with?

What the symptoms may suggest

• Refactor may be enough if the foundation is still sound, but the code has become harder to work with.
• Replatform may be the better route if the platform itself is now limiting how the website needs to operate.
• Rebuild may be justified if business requirements have progressed to the point that the current system no longer meets the job.

That distinction matters, because the cost, risk and scope are very different.

A common mistake

One of the most expensive mistakes is approving a rebuild before defining the actual failure mode.

A team can be right that the current setup is no longer working, yet still unclear about why.

We see this especially with large, long-established websites. Routine updates become cumbersome. Content structures drift over time. Governance gets harder. Accessibility, maintenance and platform confidence all become more difficult to manage. At that point, “we need a rebuild” can feel obvious.

But what looks like a rebuild decision is often a diagnosis problem first.

When rebuild really is correct

Sometimes, a rebuild is the right call.

That is usually when business needs have changed materially, the current system was never designed around those needs, or legacy constraints make meaningful improvement difficult.

The point is not to avoid rebuilds.

It is to make sure the decision is solving the right problem.

A better starting question

Instead of asking:

“Do we need a rebuild?”

Start with:

“What exactly has stopped working in the codebase, the platform, the content model, or the business fit?”

That question usually leads to a better decision.

If your team is weighing up refactor vs replatform vs rebuild, book a discovery call with us.