Rebuild the Website From Scratch or Improve It
The question “should we rebuild the site from scratch or improve what we have” comes up sooner or later for every project older than three years. And it is nearly always answered emotionally: developers dislike the old code, the owner dislikes the old design, and marketing dislikes that nothing can be changed quickly.
The emotional answer is almost always the same one – rebuild. It is the most expensive and riskiest option, and it gets chosen more often than it deserves.
What “rebuild” actually means
A rebuild is not only new code. It is:
- Migrating all existing content, including the parts everyone forgot about.
- Preserving every URL, or producing a complete redirect map.
- Reconfiguring analytics, forms, integrations and email.
- A period where the new site exists but the team’s familiar tools do not yet.
- The risk of a traffic dip lasting several months.
The code itself is usually the smaller part of the work. That is precisely why rebuilds overrun: the plan budgets for development and the time goes on migration.
When improvement genuinely will not save it
| Situation | Decision |
|---|---|
| The platform no longer receives updates | Rebuild, it is a security matter |
| Every fix breaks something else | Rebuild in pieces |
| The site does not work on phones | Rebuild the front end, not the site |
| Slow, cause not identified | Find the cause first |
| The design looks dated | Improve, this is not a reason |
| Hard to publish content | Improve the admin side |
| A new vendor recommends it | Ask which numbers it improves |
The first two rows are real reasons. The rest are more often solved by improvement, for less money and without the risk.
The middle path nobody offers
Between “touch nothing” and “rebuild everything” there is a third route: replacement in pieces. The site stays live while sections, templates and functionality are replaced one at a time.
It looks like this:
- An audit of what exists. Which pages produce traffic and enquiries, which produce nothing. It often turns out that ten pages out of two hundred need rebuilding.
- Templates replaced one by one. Homepage first, then service pages, then the blog. Each change verified separately.
- Functionality migrated as modules. Forms, catalogue, filters – each on its own date.
- Design arrives with the templates. Not as a separate stage waiting on development to finish.
The main advantage of this approach is not cost. It is that when a metric dips you know exactly which step caused it. In a full rebuild everything changes at once and the cause becomes undiscoverable.
How to decide
Four questions that answer this more honestly than any pitch deck:
- What does maintaining the current site cost per year? If it is half the price of a new one, a rebuild pays for itself. If it is a tenth, it does not.
- How many tasks are on hold because “this site can’t do that”? If the list is long and contains things that make money, that is an argument.
- Do you know why the site performs badly? If not, a new site will reproduce the same problem in new code. This happens more often than anyone wants.
- Can you absorb a two to three month dip? If the site is your main source of enquiries, that is a real risk and belongs in the budget.
The most common mistake
Rebuilding the site while preserving every problem the old one had. This happens when the new site is built “like the old one but prettier,” without establishing why the old one underperformed.
The tell is that the brief for the new site is a list of pages rather than a list of jobs the site is supposed to do. If the document contains no number the new site is meant to improve, the rebuild will change nothing except the appearance.
What to do next
The practical order: measure the current state first – speed, conversion, traffic, maintenance cost. Then write down what is getting in the way, with a monetary estimate against each item. Only then calculate which is cheaper: closing those items through improvement, or starting over.
In most cases we have seen, that calculation revealed three or four critical problems, all solvable within a few weeks. A full rebuild is justified less often than it is chosen, and almost always when the platform has stopped receiving updates or when every fix breaks adjacent functionality. Otherwise, replacement in pieces gets the same result with less risk.
