Rebuild vs refactor: deciding the fate of a legacy website

Legacy sites are not inherently bad—many quietly earn revenue for years. The question is whether continued investment in the current stack compounds value or compounds frustration. Refactoring preserves URLs, integrations, and team knowledge; rebuilding trades disruption for a cleaner foundation.

Signs a refactor may be enough

• The CMS and hosting are still supported and secure with patches.
• Performance issues are localized (templates, images, one bad plugin).
• Design updates can roll out incrementally without fighting the theme system.

Signals a rebuild is worth serious consideration

• Security or compliance requirements outstrip what the platform can offer.
• Editor experience blocks marketing from shipping pages without developers.
• Technical debt makes every small change unexpectedly expensive.

Risk management

Rebuilds fail when scope balloons or SEO is treated as an afterthought. Inventory integrations (forms, CRM, payments, SSO), document redirect requirements early, and run content audits so you migrate only what still serves a purpose. Parallel running or soft launches reduce the blast radius.

Making the call

Frame the decision in total cost of ownership over eighteen to thirty-six months—not just quote A vs quote B. Include hosting, licenses, agency time, internal hours, and opportunity cost of slow experimentation. The “right” answer is often the one your team can realistically maintain.