Rebuilds are the default recommendation and often the wrong one
Ask an agency about an old site and the answer is usually “rebuild”. Sometimes that is right. Often it is because a rebuild is a bigger, cleaner project than untangling someone else's work, and unpicking a mess is harder to quote confidently.
The honest test is whether the problems are structural or accumulated. Accumulated problems are cheap to fix. Structural ones are not.
Four symptoms that genuinely justify a rebuild
- The platform is unsupported. A version no longer receiving security updates is a deadline, not an opinion.
- Nobody can safely change it. If every change risks breaking something unrelated, the cost of ownership is already higher than a rebuild.
- The data model cannot express the business. When new requirements need increasingly grotesque workarounds, the foundation is wrong.
- The cost of maintenance exceeds the cost of replacement over a two-year horizon. Add up last year's fixes honestly before assuming.
Symptoms that do not justify a rebuild
“It looks dated” is a design problem, and restyling costs a fraction of rebuilding. “It is slow” is usually images, scripts and caching. “We cannot edit it easily” is often a content model fix. “The developer left” is a documentation problem, not an architecture one.
A useful sanity check: if the site were brand new and built exactly as it is today, would you be happy? If yes, your problems are cosmetic and a rebuild is an expensive way to solve them.
How to decide with evidence rather than instinct
- Total the last twelve months of maintenance, fixes and workarounds
- Count the changes you wanted and did not make because they were too risky
- Get a technical audit — two or three days of someone reading it and reporting honestly
- Price both options against the same list of desired outcomes
- Weigh the risk: a rebuild is months of disruption and a launch day; a refactor is incremental and reversible
The middle path: strangle it
You do not have to choose between living with it and replacing it all at once. Build new functionality alongside the old system and route traffic gradually, retiring old parts as they are replaced.
It takes longer in total and it is far less risky. There is no launch day where everything changes and something unexpected breaks. For a site that generates revenue continuously, that is usually the right trade.
If you do rebuild, protect what works
Do not throw away the parts that earn. Keep the URLs, keep the content that ranks, keep the conversion paths that convert, and keep any feature customers use daily even if nobody on the project team likes it.
The most expensive rebuild is the one that produces something prettier that converts worse — and it happens often enough to be worth planning against.