When a WordPress Site Is Worth Rebuilding (and When It Isn't)

WordPress has a reputation problem and an inertia problem at the same time. Half the pitches we hear start with "everything must be moved off WordPress," and half the support tickets come from sites that would have been better left alone. Rebuilding is real work with real cost, so it deserves the same honesty as any other technical decision. Here's how we actually frame it.

When WordPress is still the right answer

A content-driven site where a non-technical team edits pages weekly is a WordPress site, or something shaped like one. The editor is good, the ecosystem handles hosting and SEO plugins, and almost anyone the client hires next will be able to work in it. A marketing site, a blog, a restaurant menu, a portfolio: if the content model is "pages and posts," WordPress is fine, and a custom rebuild of it is mostly a way to spend money recreating wp-admin worse.

The honest version of that test: count the plugins. A site running a page builder plus two SEO plugins plus a form plugin is annoying but functional. If the feature list maps to things plugins do well, keep the ecosystem and budget for maintenance instead.

The signs it's time to move

Something shifts when the site stops being a content site and starts being an application wearing a CMS costume:

The security treadmill never ends. Plugins need updates every week, one of them breaks the page builder every third update, and the site has been defaced or injected once already. At that point you're paying for vigilance, and the vigilance never buys anything.
Performance keeps getting worse no matter what you cache. Page builders plus a dozen plugins load megabytes of CSS and JavaScript per page. You can throw CDN and caching at it, but the ceiling stays low.
The actual feature is fighting the CMS. Booking systems, calculators, client portals, anything with accounts and paid plans. WordPress can host these, but it hosts them through plugins that are really small applications duct-taped to a blog engine. That's where custom code starts to pay for itself.
Every change needs a developer anyway. The editor's main job is letting the owner make changes. If the owner emails you before every price update, the CMS has already lost its reason to exist.

What a rebuild actually involves

Skipping any of these steps is where rebuilds go wrong:

Inventory the content and the functionality. Every page, every form, every integration. Half of a rebuilding project's surprises are a newsletter signup and a booking widget nobody mentioned in the kickoff call.
Export the content properly. Posts, images, and metadata come out in a structured way. Hand-copying forty pages into markdown is exactly as miserable as it sounds, so script it once instead.
Map every URL and redirect it. This is the step that decides whether the rebuild costs you traffic. The old permalink structure, the tag pages, the paginated archives — each one gets a redirect to its new home before launch, not after the rankings dip.
Build for parity, not perfection. The rebuild has to include the boring things: email sending, error pages, print styles if anyone prints. New features come after the site is safely shipped, or the launch never arrives.

The middle path nobody mentions

Sometimes the right answer is neither. Keep WordPress as the editing surface for marketing content, and build the application part (portal, booking, checkout) as a proper app beside it. The two share a domain and a visual identity, and neither one has to do the other's job. It costs two deployments and a little routing work, and it's regularly cheaper than forcing either half to imitate the other.

The decision isn't "WordPress good, custom code good." It's "where does the editing happen, and where does the logic happen." When you can answer those two questions without a shrug, the stack picks itself.