One is a paint job. The other is structural. Choosing wrong is expensive either way.
One is a paint job. The other is structural. Choosing wrong is expensive either way.
The content structure still matches the business, the CMS still fits how the team works, and the technical foundation is maintainable. If the complaints are about how it looks and reads, redesign.
Nobody will touch the code. Simple changes take days. The CMS fights the team so they avoid publishing. Performance problems are architectural rather than incidental. Those are structural, and no amount of visual work fixes them.
The costly outcome is redesigning a broken foundation. It looks like progress for a year, then you pay for the rebuild anyway, having spent the budget that would have funded it.
The clearest signal is not in your analytics. Ask whoever maintains the site how they feel about making a small change. Hesitation, caveats, or a request for a week to do something trivial is a structural diagnosis.
People who work in a codebase daily know whether it is sound. They are rarely asked.
It rarely has to happen all at once. Replacing the highest-traffic templates first spreads the cost and the risk, and you learn on the pages that matter most while the rest keeps working.
Staged rebuilds are less satisfying to plan and considerably easier to fund.
A rebuild is not permission to discard the content structure and URLs that already rank. Carrying those across carefully is usually the difference between a smooth launch and a painful one.
The temptation to redesign the information architecture at the same time is strong and worth resisting unless the architecture is the actual problem.
Ask how long a small, uncontroversial change takes. Adding a field to a form, or a new page type. If the answer is hours, the foundation is sound and you have a design problem. If it is weeks, or nobody is willing to estimate, you have a structural problem and a new coat of paint will not touch it.
Ask what happens when the platform updates. If updates are routine, the system is healthy. If they are deferred indefinitely because nobody knows what will break, that is technical debt with interest accruing.
Ask who understands it. If the answer is one contractor who is hard to reach, you do not have a system, you have a dependency.
The riskiest version of a rebuild is the one where everything changes on a single day after nine months of silence. Budgets get exhausted, the business changes underneath the project, and the launch carries every unknown at once.
Better to do it in slices. Put the new system in front of the old one, move a section at a time, and keep both running until each slice is proven. It is marginally more work and dramatically less risk, and it means value arrives during the project rather than only at the end.
It also produces honest evidence early. If the first slice does not perform better than what it replaced, you find out in week six rather than month nine.
Rebuilds have a habit of throwing away things that were quietly earning their keep, because nobody documented why they existed. The odd-looking page that ranks for a valuable query, the internal shortcut the sales team relies on, the form that feeds a spreadsheet somebody's job depends on.
Before anything is deleted, inventory it and check the analytics. The rule we use: nothing goes without a named person saying they know what it does and that it is not needed.
Rebuilding is an opportunity to fix the foundation, not a licence to discard institutional knowledge that happens to live in an ugly page.