Rescue or rebuild? How to decide whether a stalled B2B storefront is worth fixing

A B2B storefront that is not working is usually described in one sentence, "the site does not work", and that sentence hides four completely different problems with four completely different costs. Before anyone gets to argue about platforms, name which one you have. In our experience of the questions that arrive at this site, the structural platform failure is the least common of the four and the one most often assumed.

The diagnostic question that separates them is this: if the integration produced perfect data tomorrow morning, would the storefront do the job? If the answer is yes, you have an integration or data failure and you are looking at a rescue. If the answer is no, because the platform cannot represent something your customers require, you may have a genuine structural failure.

Be careful with the third row. A scope failure looks exactly like a platform failure from the sales floor, because in both cases the buyers are still phoning. The difference is that a scope failure is fixed by building the thing that was cut, on the platform you already own.

Rescue is the right answer more often than the market discusses, for a reason that is structural rather than technical: the people who write about replatforming are usually the people who sell replatforming. A rescue is a smaller engagement, it produces less impressive marketing, and it is frequently what the business needs.

The strongest argument for rescue is that most of what you paid for is still there. The catalogue is loaded, the customers are provisioned, the theme is built, the payment gateway is live, and your team has learned the admin. A rebuild throws all of that away and buys it again, and the second purchase is rarely cheaper than the first because the requirements have grown in the meantime.

The signals below are cumulative. If most of them are true for you, a rescue will very likely cost less and land sooner than a replatform, and you can always rebuild later from a working position, which is a much better place to make a platform decision from than a stalled one.

There are real cases where continuing to fix the current storefront is throwing money at something that cannot get there, and pretending otherwise to win a smaller engagement would be its own kind of dishonesty. The test is whether a named, documented limit blocks a requirement the business genuinely has, and whether the workaround is worse than the rebuild.

The cleanest example is a catalogue cap. Shopify B2B carries pricing and product entitlement in the same object, the catalogue, and on Basic, Grow and Advanced you can assign only three active catalogues across all your B2B markets. If you have eleven distinct price groups, that is not a bug and not an integration problem, and the honest options are moving to Shopify Plus, which lifts the cap and starts at $2,500 USD a month on a one-year term, or moving to a platform whose pricing model fits. Both are real answers; neither is a fix to the existing configuration.

The second clean case is end of life. When the vendor retires the product you are running, the decision is made for you and the only question is timing. Cin7 has published end-of-life information for modules and integrations including its legacy B2B capability, which is the kind of notice that converts a rescue conversation into a migration plan.

The third case is maintainability, and it is the one to be most careful with, because "the previous developer’s code is bad" is the easiest thing in the world for a new agency to say and the hardest thing for you to verify. Ask for specifics: which parts have no tests, which parts have no documentation, which dependencies are past end of support, and what specifically breaks if you change a price rule. If the new agency cannot answer in that form, they are describing a preference rather than a finding.

Everyone advising you on this decision has an interest in the outcome, including us. Acro Commerce builds B2B commerce, so a rebuild is a larger engagement for us than a rescue. You should read the previous two sections knowing that, and you should apply the same reading to whoever else is in the room.

This is not a reason to distrust advice. It is a reason to ask each adviser to state the case against their own recommendation, because someone who can argue the other side convincingly has actually considered it. An adviser who cannot tell you when their recommendation would be wrong has not done the analysis.

The table below is uncomfortable to publish and useful to have. Use it to calibrate, not to dismiss. The agency that built the current site often does know exactly what is wrong with it, and is often the cheapest route to fixing it, even though they have an obvious reason to say the platform is fine.

You do not have to decide this from opinion. The rescue-or-rebuild question can be settled with a bounded piece of work that produces evidence either way, and it is worth doing before you sign anything larger.

The test is a pricing and availability reproduction against your own worst cases. Pick your five most awkward accounts, the ones with negotiated prices, dated contracts, several ship-to locations and a unit of measure that differs from how you stock. For each, take three items they buy regularly. Then answer two questions with evidence: can the current platform hold and display the correct price for each of those fifteen combinations, and can the current integration deliver it reliably? Fifteen cases is enough to expose almost every structural limit that matters, and small enough to be done quickly.

If the platform can hold the data and the integration is what is failing, you have a rescue and you have just built the test suite for it. If the platform cannot represent the data, you have found a structural limit with a specific, quotable name, which is exactly what you need to justify a replatform to a CFO. Either way you finish the exercise holding evidence rather than opinions.

Two things to insist on while you run it. Use real customers and real contract prices rather than sample data, because the defects live in the awkward accounts. And write down every business rule you discover along the way, including the ones people have been carrying in their heads, because that document is the most valuable output of the exercise regardless of which way the decision goes.

A rescue is not vague remedial work. It has a shape, and knowing the shape lets you scope it and hold someone to it. The order below matters, because fixing mappings before fixing the source records in Acumatica or Cin7 means doing the work twice.

The step people want to skip is the first one. Reproducing the failures against real accounts feels like delay when everyone already knows the site is broken, and it is the step that prevents you spending the budget on the wrong thing. "Prices are wrong" is not actionable. "Prices are wrong for the eleven accounts whose contracts carry expiry dates, because the nightly push does not remove expired rows" is a fix with a cost.

The last step is the one that decides whether the rescue holds. A storefront that is repaired and handed back to nobody drifts straight back into the state it was in. Name the person who works the failed-order queue, name the person who owns the integration when an ERP release lands, and put the regression test suite you built in step one somewhere it will actually be run.