Skip to content
Send a brief
← All insights[Websites and delivery]

When to repair a website and when to rebuild it

Adrian Ștefănescu8 min readLocal draft

“We need a new website” is sometimes a conclusion and sometimes merely the name given to a collection of frustrations. Before rebuilding, separate what is failing: the message, design, content, administration, performance or technology.

Define the problem before the solution

An unclear homepage may need better content and hierarchy, not another framework. Poor conversion may come from the offer, traffic or sales process. Images and scripts can damage performance even when the platform is healthy. Diagnosis should connect symptoms to evidence: analytics, feedback, testing, a technical audit and editorial difficulties.

Repair when the foundation is healthy

  • The technical structure is maintained and extensible.
  • Problems are concentrated in a few pages or journeys.
  • Content and identity still represent the business.
  • Accessibility and performance can be corrected incrementally.
  • The team can publish and its blockers are well defined.
  • Repair costs less and migration risk is not justified.

Repair may include rewriting the homepage, simplifying navigation, optimising images, removing extensions, rebuilding a form or consolidating components. The interventions should form a plan rather than an endless succession of patches.

Rebuild when the limits are structural

Rebuilding becomes reasonable when the platform is no longer supported, updates constantly produce regressions, the content model cannot represent the offer or every page depends on duplicated code. A major positioning change may also require an architecture incompatible with the current structure.

Include migration cost and risk

Rebuilding is more than new pages. It includes content inventory and migration, redirects, SEO, integrations, analytics, consent, domain work, training and a verification period. URLs, data or quiet functions not visible in the design can be lost. A good plan states what remains, what retires and how continuity will be validated.

Make the decision in stages

  • Inventory pages, functions, integrations and owners.
  • Measure problems and their effect on users and the team.
  • Estimate the repair scenario over 12–24 months.
  • Estimate rebuilding, including migration and risk.
  • Test the direction on one representative page or journey.
  • Choose the best total cost, not the most spectacular launch.
Rebuilding is right when it replaces a structural limit, not when it avoids understanding the problem.

Keep what works and rebuild only what obstructs future goals. A short audit and an honest comparison of scenarios can save months of work or confirm that a new foundation is genuinely necessary.