Almost every inherited site raises the same question: is it worth fixing, or is it time to start over? There’s no universal answer, but there is an honest way to make the call. Patching is faster and cheaper right now. Rebuilding is sometimes the only path to a site that’s actually reliable. Getting this decision wrong in either direction costs more than getting it right would have.
Why this decision is hard to make objectively
The bias toward patching is almost always financial. A patch feels cheaper because you can see the invoice for it right away. A rebuild feels expensive because the number is bigger and the value is harder to point at. What that framing misses is the ongoing cost of a site that’s always being patched: the developer hours spent diagnosing the same recurring issues, the instability that slowly erodes customer trust, the things the business can’t do because the site won’t allow it.
The bias toward rebuilding runs the other way just as easily: a developer who’d rather build something clean than inherit someone else’s mess, or a business owner who’s lost confidence in the current site and wants a fresh start whether or not it’s actually necessary. A rebuild that isn’t justified by the technical reality is a real expense with a questionable return.
We try to make this call based on what we actually find in the site, not on what’s easiest to propose or most satisfying to build.
What we look at first
Four things tell us most of what we need to know: the foundation, the custom code, the plugin stack, and what the business actually needs the site to do next. Here’s how we read each one.
The foundation: WordPress core, theme, and PHP version
A site running significantly outdated versions of WordPress, PHP (the programming language WordPress itself runs on), or WooCommerce has been quietly building up technical debt. Updating these isn’t optional if you want a site that’s secure and works with current plugins. But updating them on a site with a lot of custom code or plugin dependencies isn’t always simple. If bringing the site current would require rebuilding most of the custom code anyway, the rebuild question is already halfway answered.
We’ve evaluated sites where updating to PHP 8.2 would have broken custom code deeply embedded in the theme, third-party plugins nobody was maintaining anymore, and a checkout flow built on WooCommerce functions that had since been retired. In that case, the honest answer was that patching would have meant updating everything that needed updating and rewriting most of the custom code anyway, which is a rebuild by another name, and a more expensive one.
The custom code layer
Custom code lives in themes, child themes, custom plugins, and sometimes places it shouldn’t, like directly inside a single file that’s grown to thousands of lines over the years. We audit what custom code exists, what it actually does, and how well it’s written.
Well-written custom code that does one specific thing is patchable. It has a clear purpose, it’s isolated from everything else, and it can be updated or replaced without breaking something unrelated. Poorly written custom code that’s tangled through the theme and makes assumptions about how WooCommerce works internally is a different problem. Patching one part of it tends to break another, and the developer doing the patching spends most of their time just figuring out what the original code was trying to do before they can touch it safely.
The test we actually apply: if we handed this code to a competent WooCommerce developer who’d never seen it, how long would it take them to understand it well enough to change it safely? If the answer is days rather than hours, the maintenance burden is real, and it’s ongoing.
The plugin stack
A plugin stack that’s grown organically over years often ends up with plugins that conflict with each other, plugins that duplicate what another one already does, plugins on expired licenses that stopped getting updates long ago, and plugins that were installed to solve a problem and never removed once the problem got solved a different way.
We’ve seen sites running two SEO plugins, three caching plugins, and half a dozen plugins doing things WordPress or WooCommerce now handles on its own. Every one of them adds load, potential conflicts, and something else to maintain. Cleaning up the plugin stack alone is sometimes enough to stabilize a site that looked like it needed a full rebuild. Other times, the plugin stack is just evidence that the site was never built with a coherent plan, and the same issues will keep coming back until there is one.
The business requirements
What the business actually needs the site to do over the next two to three years matters just as much as its current technical state. A site that’s still patchable today but is about to need a major new feature or integration might be better off rebuilt now, so that work has the right foundation to stand on. A site that does what the business needs, and will keep doing it for the foreseeable future, is worth patching even when it isn’t elegant.
Signals that point toward rebuilding
- The same kind of problem keeps coming back after every patch. This is the clearest signal there is. Fix the checkout three times in six months for different but related reasons, and the problem is architectural, not incidental.
- Updating WordPress core, PHP, or WooCommerce to current versions would break real functionality. If you can’t safely update your own infrastructure, you’re accumulating security exposure every month that passes.
- The site can’t do something the business genuinely needs, and adding that capability means touching code that’s fragile or undocumented. New features built on a bad foundation inherit all of its instability.
- A developer audit turns up custom code that nobody fully understands anymore. Code whose behavior is unknown is code you can’t safely change.
- Performance problems persist despite caching and hosting improvements, because the actual bottleneck is architectural: too many trips to the database, inefficient custom queries, or every page loading assets it doesn’t need, none of which gets fixed without restructuring the code itself.
Signals that point toward patching
- The site is on current versions of WordPress, PHP, and WooCommerce, or can get there without major changes to the custom code.
- The custom code is well-organized, documented, and does specific things a new developer could understand and modify in a reasonable amount of time.
- The problems are specific and isolated: one plugin causing a conflict, a particular page template performing poorly, a checkout field that needs adjusting. These are genuinely patchable.
- The business doesn’t expect significant new requirements over the next year or two. A site that does its job reliably, without needing to grow much, is worth maintaining rather than replacing.
The hybrid path
Most situations aren’t binary. The real answer is often a structured improvement plan: fix whatever’s causing immediate pain, clean up the plugin stack, update to current versions where that’s possible, and then take an honest look at whether what’s left justifies a full rebuild or whether the site is stable enough to run on for another two or three years.
That middle path is often exactly what a client needs to hear, even in cases where a full rebuild is eventually the right call. A rebuild done well takes real time, and rushing it just produces a new site with new problems. Sometimes the right plan is to stabilize what exists, run it reliably while the rebuild gets planned properly, and migrate only once the new site is genuinely ready.
| WORKING WITH BRIOFORGE Inherited something you’re not sure about? A lot of our work starts with a site someone else built, where the original decisions were never documented and the person who made them is long gone. Sometimes it’s sound and just needs regular maintenance. Sometimes the business logic is buried in a theme, one plugin update away from a genuinely bad afternoon. We audit what’s actually there, tell you honestly which one you’ve got, and give you a path that doesn’t require rebuilding everything at once. If you have a site you’re nervous about, get in touch; that’s a good conversation to have before it turns urgent. |
Frequently Asked Questions
How much does a WooCommerce rebuild typically cost compared to ongoing patching?
A proper rebuild is typically a larger upfront investment, ranging from 15,000 to 60,000 dollars or more depending on complexity. But the comparison should be made over two to three years, not as a single invoice. A site costing 1,500 to 3,000 dollars a month in ongoing developer time for recurring issues and emergency fixes will often exceed the cost of a rebuild within 18 months. The honest comparison looks at total cost of ownership, not just the upfront quote.
Can I get an objective assessment of whether my site needs a rebuild?
A technical audit from a developer with no financial stake in the answer is the most reliable way to get one. Be cautious of assessments from developers who primarily propose rebuilds, or who primarily propose patches, since both come with a business incentive that can skew the recommendation. Ask for the assessment as a document that explains the findings, not just a conclusion.
How long does a proper WooCommerce rebuild take?
A well-executed rebuild for a medium-complexity store typically takes three to five months from discovery through launch. Builds rushed to compress that timeline tend to produce new sites with different problems than the old ones. The discovery and architecture-planning phase is where most shortcuts get taken, and it’s the phase where shortcuts cause the most damage later.
What should I do with my current site while a rebuild is underway?
Keep it stable and don’t try to add new features to it. The goal during a rebuild is to keep the existing site operational without investing heavily in it. Apply security updates and keep plugins current. Avoid major structural changes that would complicate the eventual migration. The rebuild should proceed alongside the live site, not replace it, until it’s genuinely ready.
