When is a rebuild the better choice?

A rebuild becomes the better choice when the site has deep structural problems, an outdated technology stack, scalability limitations, or security vulnerabilities that a redesign cannot address. If the current codebase, CMS, or architecture fundamentally prevents the site from meeting business requirements, incremental improvements will not close the gap.

Specific technical red flags that point toward a rebuild include: slow page speed caused by unscalable code rather than unoptimized images, outdated PHP versions or plugins that cannot be updated without breaking functionality, poor security practices baked into the architecture, and a backend so difficult to manage that the content team avoids making updates. Business triggers include a major expansion requiring new capabilities (such as adding e-commerce to an informational site), a fundamental shift in target audience requiring restructured user journeys, or a need for modern integrations (CRM, marketing automation, payment systems) that the current platform cannot support. The cost-benefit calculus favors a rebuild when the team is spending excessive time on maintenance and bug fixes, when workarounds outnumber features, or when the cumulative cost of patching the existing site over the next two to three years would exceed the cost of building correctly once. When the site performs well technically but simply looks dated, a redesign remains the more efficient path.