Skip to the decision guide
Commerce Recovery DeskTakeover evidence, not promises

Decision gate / salvage or replace

Magento Rescue vs Rebuild: A Buyer Decision Guide

Use the takeover assessment to decide whether to stabilize, refactor, rebuild on Magento, or move to another platform. No fixed percentage can make this decision safely.

Direct answer: repair when the platform still fits, ownership is clear, data is sound, and defects can be bounded. Rebuild when the inherited implementation cannot be evolved safely. Replatform only when the platform itself blocks the required operating model or total cost.

Do not begin with sunk cost

Money already spent does not prove that a system should be saved, and a failed delivery does not prove the platform is wrong. Separate four questions: does the platform fit the business, can the buyer prove ownership, can data and transactions be trusted, and can the architecture be changed without creating more risk?

Four decision paths

Evidence-led recovery paths
PathEvidence in favorEvidence againstFirst acceptance gate
Stabilize and repairMagento still fits; core data is reliable; failures are bounded; rollback is possible.Unknown ownership, systemic data corruption, or recurring failures without a testable cause.Checkout, orders, integration, and deployment meet a defined stable baseline.
Refactor in placeBusiness workflows are valuable, but custom modules, releases, or integrations create recurring risk.Refactoring would recreate most of the platform while the business keeps paying for two systems.One high-risk area is replaced behind tests and observable acceptance criteria.
Rebuild on MagentoThe platform fits, but the inherited codebase, theme, or deployment model cannot be evolved safely.Platform licensing, operating model, or capability limits are the real problem.Destination architecture and migration scope pass an independent challenge review.
ReplatformA different platform better fits the required capabilities, skills, cost, and operating model.The proposed destination has not been validated against data, SEO, integrations, and peak load.A buyer-owned decision record proves why migration risk is lower than recovery risk.

Ownership can decide before architecture

A technically repairable system may still be unsafe to rescue if the buyer cannot prove ownership of repositories, licenses, cloud accounts, domains, or critical custom code. Resolve contracts and access before asking a new agency to recreate credentials or copy assets. Use the takeover checklist.

Data and order integrity come before frontend quality

Prioritize payment state, order IDs, totals, stock, customer records, and ERP or PIM synchronization. A faster storefront is not a successful rescue if orders disappear, replay twice, or reach ERP with incorrect values. Require a documented reconciliation method and accepted exception list.

Test the platform-fit hypothesis

Avoid the false 70% rule

No active evidence rule on this site says that rescue is correct below a fixed percentage of rebuild cost. Cost estimates are uncertain, and risk is not proportional to code volume. Use ranges, dependencies, confidence, and explicit stop conditions instead.

Minimum decision output

The assessment should end with an evidence pack, option table, dependencies, estimates, risk register, data plan, integration plan, SEO plan where relevant, acceptance tests, and one recommended path with a documented dissent or alternative. The buyer should be able to give that package to another provider.

A good rescue adviser can recommend repair, rebuild, or replatform. A delivery provider may still benefit from the chosen path, so compare the decision logic before comparing implementation proposals.

Continue the rescue review

Return to the eight rescue agencies, use the first 72 hours plan, or review the RESTORE-100 evidence method.