When a site is slow, brittle, or cursed, two pitches compete: “better hosting will fix it” and “we should rebuild from scratch.” Both are sometimes right, and choosing wrong costs months. Here is the assessment that picks correctly — usually revealing that neither extreme is needed.
Assess before choosing: three numbers
- Uncached TTFB on a healthy page — the measurement method from the TTFB guide. Past ~600ms with a lean plugin set, hosting is a suspect.
- Theme structural weight — the audit in the theme diagnostic. Past the thresholds after asset diet, the theme is the bottleneck.
- Maintenance drag — hours per month fighting breakage. The sustainability metric from the switch framework.
When hosting migration is the right call
- Workers starve and RAM throttles under normal traffic (the plan-reading in the hosting guide).
- Cached TTFB stays past ~300ms with everything configured.
- Support cannot answer basic capacity questions.
- Cost: a day of migration work (per the checklist) plus the new plan. The site’s architecture carries over — including its problems, but those are cheaper to fix on adequate hardware.
When a rebuild is the right call
- Theme weight and maintenance drag are both structural — two-plus symptoms by the switch criteria.
- The stack depends on abandoned plugins holding the site together.
- Design goals require what the current architecture cannot express.
- Cost: weeks, not days — budgeted honestly at 20–40 hours minimum for content sites, more for stores. A rebuild that “just moves to new hosting” fixes nothing; the lock-in analysis explains what transfers and what does not.
The option both pitches skip: optimize in place
Most “cursed” sites we audit need neither move nor rebuild — they need the checklist sequence: page cache, image pipeline, script diet, object cache. Roughly a day of work moves LCP from failing to passing on the majority of sites, measured honestly before and after. The pitches for migration and rebuild exist partly because optimization work is unglamorous to sell.
The decision rule
Fix in place first (measure before/after). If hosting ceilings then bind — migrate. If architecture drag persists despite optimization — rebuild. Doing them in that order means each decision is made with evidence, and the expensive options get chosen rarely, for the right reasons. The free audit produces exactly this evidence.
Neither first: optimize in place (cache, images, scripts) and measure. Migrate only if hosting ceilings bind afterward; rebuild only if maintenance drag and theme weight are structural. 20–40 hours minimum for content sites, more for stores — design, content migration, QA, and SEO continuity. Rebuilds that only change hosting fix nothing. Worker starvation, RAM throttling, slow disk I/O, and missing server cache. It does not fix heavy themes or plugin bloat — those transfer with the site. Uncached TTFB past ~600ms on a lean plugin set, or cached TTFB past ~300ms with everything configured. Measure with the curl timing method before blaming or buying.Should I move hosting or rebuild my slow WordPress site?
How much does a WordPress rebuild cost?
What problems does better hosting actually fix?
How do I know if my hosting is the bottleneck?
