ZestIQ TeamEvery merchant with a struggling store reaches the same fork. The agency quoted another round of fixes, a different agency quoted a rebuild, and both sound sure of themselves. One of them is selling you the work it prefers to do. This article is the decision rule we use when a store lands on our desk, written so you can run it yourself before anyone quotes you anything.
The rule is short. Rescue the store while rescuing it clearly costs less than rebuilding it, in money, in time and in risk. Below a salvage point, rebuild, and be able to say exactly why. The hard part is not the rule. It is knowing which side of the line your store is on, because the evidence is buried in code, contracts and accounts that a struggling team rarely has time to read.
So the rest of this piece is a scorecard. Eight questions, each one about the store you actually have rather than the store you were promised. Answer them honestly and the decision usually makes itself.
Why the rescue or rebuild decision usually goes wrong
Most stores are rebuilt for the wrong reason or rescued for too long. Both mistakes come from the same place: the decision is made on feelings about the store rather than on facts about it.
Rebuilding to escape a bad relationship
When a project has gone badly, a rebuild feels like a clean break. New platform, new agency, no history. But the problems that sank the old build are usually still in the room: an unclear scope, integrations nobody mapped, a catalog with years of inconsistent data. A rebuild carries all of them across and adds a migration on top.
Rescuing because the money is already spent
The opposite mistake is the sunk cost. The store cost a great deal, so it must be worth saving. It might be. But the money already spent tells you nothing about what the next year of fixes will cost, and a store that needs a full rewrite of its custom code has already been rebuilt in everything but name.
The question that cuts through both: forget what the store cost. Ask what it will take to make it safe, current and able to carry the next two years of the business, and compare that with what a rebuild would take to do the same.
The rescue or rebuild scorecard
Score each question as a point for rescue, a point for rebuild, or neutral. A store with mostly rescue points should be rescued. A store with mostly rebuild points should be rebuilt. A store in the middle needs someone who did not write the code to read it, which is the one step we would never skip.
1. Is the platform version still supported?
Start with the calendar, because it is the one fact nobody can argue with. On Magento and Adobe Commerce, Adobe publishes its lifecycle dates: 2.4.6 left standard support on 11 August 2026 and its extended support ends on 31 August 2027, while 2.4.7 leaves standard support on 31 May 2027. Adobe's lifecycle policy for Adobe Commerce also says Cloud environments running unsupported versions will no longer be maintained, up to suspending traffic. A store one or two minor versions behind is a rescue with an upgrade in it. A store several major versions behind, or still on Magento 1, is already a migration.
2. How much of the core has been edited?
Changes made inside the platform's own files rather than in modules are the single best predictor of rescue cost. A handful of edits can be moved into modules, documented and left behind. Hundreds of them, spread across checkout, catalog and customer code, mean every upgrade path runs through a rewrite. Ask for a diff of the store against a clean copy of the same version. If nobody can produce one, that is a finding in itself.
3. What state is the extension stack in?
Count the third-party extensions and check each against its vendor's current release. Abandoned modules, modules overriding the same class, and licences bought in a previous agency's name all add to the rescue bill. A stack where most modules are maintained and only a few need replacing is a rescue point. A stack where the business depends on several abandoned modules nobody can replace without rework leans toward rebuild.
4. Is the data clean enough to keep?
The catalog, the customer records and the order history are usually the most valuable thing in the store, and they move with you whichever way you go. The question is quality. Duplicate attributes, products nobody can explain and customer records split across several accounts are cheaper to fix in place than to carry through a migration. Clean data favours neither path; dirty data makes a rebuild much harder than its quote suggests.
5. Are there tests and a real deployment pipeline?
A store with version control, a staging environment and a repeatable deploy can be changed safely, which is most of what a rescue needs. A store deployed from one developer's laptop, with no staging copy and no tests, can still be rescued, but the first weeks go on building the safety net before any fix is attempted. Count those weeks honestly.
6. Has the business outgrown the platform?
This is the question that justifies most good rebuilds. If the store now sells to companies with negotiated prices and approval chains, runs a dozen brands from one catalog, or sells in markets the platform handles badly, no amount of fixing will close the gap. That is a rebuild point, and an honest one. If the business still fits the platform and the problem is the build, it is a rescue point.
7. Does anyone still understand the code?
Knowledge is part of the asset. If an in-house developer or a documented module map explains why things were built the way they were, a new team can pick up the store in weeks. If the only person who understood the integrations has gone, the first job of any rescue is reading, and a long read is still usually cheaper than a rebuild that has to rediscover the same business rules.
8. What does a rebuild really cost you?
Rebuild quotes count the build. They rarely count what the business loses while it runs: a roadmap frozen for months, staff retrained on a new admin, integrations rebuilt and tested again, and the search traffic at risk during the move. Google's own guidance on moving a site with URL changes tells site owners to expect temporary ranking fluctuation and says it can take a few weeks or more for a medium-sized site to settle. Put those costs beside the quote before you compare it with a rescue.
Reading the score
Add up the points, but weigh them. Question one and question six carry the most weight, because they are about things no amount of engineering changes: the vendor's calendar and the shape of your business. Questions two and three set the size of a rescue. Questions four, five and seven set how fast either path can move. Question eight is the one most often left out.
When the answer is rescue
A supported or nearly supported version, a business that still fits the platform, and a codebase whose problems are local: that is a rescue, and it should start with stabilisation rather than features. Our ecommerce project rescue work begins with a free read of the store and a fixed-scope first week: access recovered, known vulnerabilities patched, monitoring on, and a written plan with an estimate per item.
When the answer is rebuild
An unsupported platform several versions behind, a business that has outgrown it, or a core so heavily edited that every fix is a rewrite: that is a rebuild, and it should be planned as a migration with the rankings protected from the first day. The redirect map, structured data and a ranking watch after cutover are not extras. Stores that skip them end up on our failed migration recovery work, with traffic down and nobody sure which URLs went missing.
When the score is in the middle
Then do not decide yet. Get the code read by someone with nothing to sell you on either side. An independent Magento code review answers questions two, three, five and seven in writing, with a file and a line for every finding, and turns a matter of opinion into one of evidence.
Questions to put to both quotes
Whichever way you lean, ask the agency quoting a rescue and the agency quoting a rebuild the same questions. Their answers tell you as much as their numbers.
- What did you read before you quoted, and can we see it?
- Which of our current problems does your plan carry over, and which does it remove?
- How are our search rankings protected, and how will we know if they drop?
- What happens to the roadmap while the work runs?
- What would make you change your recommendation?
An agency that cannot answer the last question has made its recommendation before looking at your store.
The short version: rescue while it clearly costs less than a rebuild, rebuild when the platform or the business says so, and when the score is close, pay for a read of the code before you pay for either.
Frequently asked questions
Should I rescue or rebuild my ecommerce store?
Rescue it while rescuing clearly costs less than rebuilding, in money, time and risk. Rebuild when the platform is unsupported and far behind, when the business has outgrown it, or when the core is so heavily edited that every fix is a rewrite. When the evidence is mixed, have the code read independently before you decide.
How do I know if my Magento store can be saved?
Check four things: the version against Adobe's lifecycle dates, how much of the core has been edited, the state of the extension stack, and whether a staging environment and deploy pipeline exist. A supported or nearly supported version with local problems is almost always a rescue. Several major versions behind with heavy core edits leans toward a rebuild.
Is it cheaper to fix a website or rebuild it?
It depends on the store, which is why the answer has to come from reading it rather than from a rule of thumb. We price both individually after a review of the code and the accounts, and the review compares them like for like, including the costs a rebuild quote usually leaves out: the frozen roadmap, retraining, reintegration and the risk to search traffic.
Will a rebuild hurt our Google rankings?
It can, which is why a rebuild has to be planned as a migration. Google tells site owners to expect temporary ranking fluctuation during a move with URL changes. A complete redirect map, preserved structured data and a ranking watch after cutover keep that fluctuation temporary.
How long does an ecommerce rescue take compared with a rebuild?
A rescue starts paying back in the first week, because stabilisation comes first: access, patches, monitoring and the leaks that lose orders. A rebuild delivers nothing to customers until it launches. The timeline for either depends on the store, and a written plan should give you dates rather than an average.
Can we rescue the store now and rebuild later?
Often that is the right plan. Stabilising and upgrading a store buys time to plan a rebuild properly, with the data cleaned and the requirements written while the store keeps trading. The rescue work is not wasted, because the cleaned data and documented integrations move with you.
Who should make the call, us or the agency?
You should, on evidence. Ask both the rescue and the rebuild agency what they read before quoting and what would change their recommendation. If the evidence is thin, an independent code review gives you a written basis for the decision that neither side wrote.
Sources
- Adobe. Adobe Commerce lifecycle policy
- Google Search Central. Site moves with URL changes
