The conversation usually starts the same way: “We need to rebuild our store.” Sometimes it’s the right call. Often, it isn’t. After years of working with BigCommerce stores at various stages of complexity, we’ve learned to recognize the patterns that actually warrant a rebuild—and the ones that just feel like they do.
The Rebuild Trap
There’s a certain appeal to starting fresh. All those years of accumulated technical debt, the workarounds that became permanent fixtures, the integrations that nobody fully understands anymore—a rebuild promises to sweep all of it away.
But here’s what that thinking often overlooks: rebuilds are expensive. Not just in development costs, but in opportunity cost, in the institutional knowledge that gets lost, and in the inevitable period of reduced velocity while everyone learns the new system.
We’ve seen stores spend six months and significant budget on a rebuild, only to discover that their core problems followed them. The slow checkout? Still slow, because the bottleneck was a third-party integration they kept. The confusing admin workflow? Recreated because nobody documented why it existed in the first place.
A rebuild doesn’t automatically fix anything. It just gives you a blank canvas to potentially make better decisions—or to repeat the same ones.
When Rebuilding Makes Sense
That said, there are situations where a rebuild genuinely is the right move. Here’s what we look for:
Platform limitations have become blockers. If your growth is genuinely constrained by what BigCommerce can do—not what your current implementation can do—that’s a signal worth paying attention to. This is rare, but it happens. Maybe you need multi-storefront capabilities that didn’t exist when you built your store, or your catalog structure has outgrown what your current setup can handle efficiently.
The key word is “genuinely.” Most perceived platform limitations are actually implementation limitations. Before concluding BigCommerce can’t do something, it’s worth having someone experienced take a hard look.
The core architecture is fundamentally broken. Sometimes stores are built on assumptions that no longer hold true. If your entire data model or integration architecture needs to change, incremental fixes become more expensive than starting over.
We worked with a store that had built their entire fulfillment logic around a single warehouse. When they expanded to three warehouses, every order touched custom code that assumed one location. The cost of retrofitting exceeded the cost of rebuilding that portion of the system correctly.
Technical debt has compounded beyond recovery. There’s a point where every change requires touching so many interconnected pieces that even small updates become risky multi-week projects. If you’re past that point, a rebuild might actually be faster.
Signs you might be there: deployments require a full regression test. Nobody wants to touch certain parts of the codebase. You’re maintaining compatibility layers for systems you replaced years ago. Simple feature requests get estimated in weeks, not days.
You’re changing business models. If you’re pivoting from B2C to B2B, or from single-brand to multi-brand, or from domestic to international—sometimes the cleanest path is starting fresh with the new model in mind rather than retrofitting the old one.
When Rebuilding Doesn’t Make Sense
More often, the problems that feel like they need a rebuild are actually symptoms of something more addressable:
Performance issues. Almost always fixable with targeted optimization work. A slow store is frustrating, but it rarely means the underlying architecture is broken. We’ve seen 3-5 second improvements from focused work on image optimization, script management, and third-party app cleanup—no rebuild required.
“Messy” code. Ugliness isn’t a reason to rebuild. Code that works and can be incrementally improved is almost always better than code that doesn’t exist yet. The new code will eventually get messy too. That’s just what happens to production systems that evolve with business needs.
New feature requirements. BigCommerce is more extensible than most people realize. Before assuming a feature can’t be built, it’s worth exploring what’s actually possible with the APIs, webhooks, and script injection points available. We regularly implement features that clients assumed would require a different platform.
Team frustration. Sometimes the push for a rebuild comes from a team that’s tired of working with the current system. That’s understandable, but it’s not a technical justification. Address the frustration directly—better documentation, cleaner processes, targeted refactoring—rather than assuming a rebuild will fix morale.
A new agency’s recommendation. Be skeptical when a new partner’s first recommendation is to rebuild. It’s easier to sell a rebuild than to learn an existing system. The best partners will invest time understanding what you have before proposing to replace it.
The Middle Path: Progressive Renovation
What we often recommend instead of a full rebuild is what we call progressive renovation. The concept is simple: identify the parts of your store that are genuinely broken, fix those specifically, and leave everything else alone.
This might look like:
- Replacing a problematic integration while keeping the rest of your stack stable
- Rebuilding your checkout flow without touching your catalog or admin customizations
- Migrating to a headless frontend for specific pages while keeping others on Stencil
- Refactoring a specific piece of custom functionality that’s become unmaintainable
The advantages are significant. You preserve what’s working. You maintain institutional knowledge. You spread risk and investment over time. And you can course-correct as you learn, rather than making one massive bet.
Progressive renovation requires discipline. It’s tempting to expand scope once you start. But the goal is surgical improvement, not comprehensive overhaul.
How to Decide
If you’re genuinely unsure whether to rebuild, here’s the assessment process we use:
Document what’s actually broken. Not what’s annoying or suboptimal—what’s genuinely preventing you from operating or growing. Be specific. “The store is slow” isn’t specific enough. “Product pages take 4+ seconds to load on mobile, and we’ve traced it to three specific apps” is.
Estimate the cost of fixing each item incrementally. Some things are cheap to fix. Others are expensive. Get realistic estimates from people who’ve actually looked at the code.
Estimate the cost of a rebuild. Include the hidden costs: the learning curve, the things you’ll discover mid-project, the opportunity cost of frozen feature development, the risk of the project running long.
Compare honestly. Usually, incremental fixes win unless the list of broken things is very long or the individual fixes are very expensive.
Consider your team’s capacity. A rebuild requires sustained focus. If your team is already stretched thin, incremental work might be more realistic even if a rebuild would theoretically be more efficient.
The Goal
The goal isn’t a perfect store. Perfect stores don’t exist. The goal is a store that works well enough that technology stops being the constraint on your business.
Sometimes that requires a rebuild. More often, it requires targeted work on specific problems, combined with the discipline to leave working things alone.
If you’re weighing this decision, we’re happy to look at your situation and give you an honest assessment. No agenda—just clarity about what makes sense for your store.