Website rebuild: refactor or start over?

Ask a vendor whether to refactor what exists or start over, and the answer will often lean towards rebuilding. That is not necessarily bad faith: picking up someone else's work is thankless, badly paid and risky. But it is not your problem.

Two questions are enough to place your site, and both are technical. Design, content and usability do not enter into that decision: they belong to an editorial rebuild, which runs just as well on an existing foundation as on a new one.

Question 1 — does the stack still receive security updates?

Every site rests on software components — a publishing engine, a language, libraries. Each has an announced lifespan, beyond which no fix is published, including for known vulnerabilities.

If your stack is past that date, the question is settled: this is no longer about comfort but about exposure, and time works against you. No serious vendor will build on it.

The check: ask in writing for the version of the engine and language in use, then compare with the end-of-support dates published by their maintainers. That information is public, free, and requires no expertise to read.

Question 2 — do you own the code and the credentials?

If the source code cannot be found, if nobody knows how the site is deployed, or if the credentials are held by an unreachable vendor, then “refactoring” means nothing: there is nothing to refactor. What runs can be reinstalled, not evolved.

Watch for a frequent case: the site works, it is online, so it appears to exist. But all you have is the installed version on the server. Without the source code or the setup procedure, the smallest change becomes a recovery operation.

When refactoring is enough

If both answers are good — maintained stack, owned code — refactoring is almost always the better choice, for three reasons.

• Earned ranking stays in place. It is the most fragile asset in a rebuild, and the longest to rebuild.
• Content is not re-migrated. Refactoring avoids the most tedious and error-prone operation.
• Risk is spread. You change a part, verify, continue — instead of switching everything over one night.

A dated design is not a reason to rebuild. Redoing the appearance, the page structure and the copy on a healthy stack is real work, but it does not touch the foundations. That is often what is meant when someone says “the site needs redoing”.

When to start over

Three situations, and they often overlap.

The stack is no longer maintained. Covered above: the case that is not up for discussion.

The code is lost or unusable. Including when it exists but nobody can run it locally, for lack of documentation.

The technology has no available maintainers. A site written in a language or framework nobody in your region practises any more leaves you at the mercy of a single supplier. The software works; the ecosystem around it has gone.

A fourth, rarer situation deserves naming: when the need itself has changed in nature. A marketing site turned ordering platform is not an evolution of the same product, and forcing it costs more than rebuilding.

Not losing your ranking — the part that gets neglected

This is the item most often missing from quotes, and the one whose omission is paid for longest. A rebuild changes addresses; every address that disappears without instruction takes with it the positions earned and the links that pointed to it.

1. Inventory the existing addresses

Before any development. Get the full list of current pages — from the sitemap, from your analytics, from the search engine's webmaster tools. Identify those receiving visits and those other sites link to: those are the ones to protect, not the five hundred pages nobody has ever opened.

2. Build the redirect table

One line per old address, the new one opposite. A permanent redirect — code 301 — tells the engine the move is final and asks it to carry over what was earned. A temporary redirect does not.

Two classic mistakes: sending every old address to the home page, which from the engine's point of view is the same as deleting them; and chaining redirects across successive rebuilds, each hop diluting the result a little further.

3. Publish the new sitemap

And declare it in the webmaster tools, so the new structure is crawled quickly rather than at the usual pace.

4. Monitor for six to eight weeks

404 errors appear first, position movements later. A dip during the first weeks is normal — the engine is re-evaluating. A dip persisting beyond two months signals a missing redirect, and there is still time to add it.

Nobody can promise that no traffic will be lost in a rebuild. What can be promised is that every address receiving visits will have a destination — and that is what belongs in the quote.

What comes along, and what stays behind

The sorting happens before migration, never after. Migrating first and cleaning later means never cleaning, and dragging pages nobody reads along for years.

Review the content by observed usefulness: pages that receive visits, pages that answer a real question, pages that are obsolete. Images deserve the same treatment — this is the moment to resize them once and for all. User accounts and order history almost always migrate; personal data you no longer have a use for does not: a rebuild is a good occasion to apply your own retention periods.

A realistic schedule

The underestimated part is not development, it is verification after the switch: walking the pages, testing the forms, checking redirects one by one on the addresses that matter, confirming that emails still go out. Allow one to two weeks of active vigilance after going live, with someone available to fix things.

Avoid switching on a Friday, and avoid the eve of a strong commercial period. These are obvious points, repeated because they are regularly ignored under schedule pressure.

Our Web & Mobile Development and DevOps & Cloud pages cover rebuilding and switching over. If your question is simply “should we start over?”, the two checks at the top answer it without us.