Ecommerce Recovery: Fix, Refactor or Replatform?

Recovery should restore control of sales and releases—not turn every inherited defect into a rewrite. The useful question is: what is the smallest change that makes a critical flow reliable, testable, and supportable?

Fix when one localized defect explains the failure and a regression test can verify the correction. Refactor when evidence points to a bounded structural problem, such as conflicting copies of a shared mapping. Consider replatforming when a verified platform limitation or a comparable business case justifies the transition. Evaluate whether a fix or refactor can meet the requirement first; you need not implement a doomed repair simply to rule it out.

Retaining a working component is a valid decision. So is postponing a choice while a specific test resolves the uncertainty. The size of a supplier's proposal is not evidence of the size of the problem.

What to fix, what to refactor, and what to leave alone

In this comparison, a fix corrects a localized defect. A refactor changes the internal structure of a bounded component while preserving its agreed behavior; adding or changing business behavior is separate scope. Replatforming moves commerce capabilities to a different platform and includes the necessary data, integrations, and operating transition.

“Leave it alone” is also an option. A functioning component does not need replacement merely because it is old or another team wrote it. Document why it is being retained, how it will be tested at its boundaries, and who will support it.

Acceptance still needs a boundary: a fix gets regression and release checks; a refactor preserves agreed behavior across normal and failure scenarios; a migration also needs accepted data, cutover reconciliation and operational handover. No option compensates for undefined rules or missing owners.

Do not compare an inexpensive patch that excludes support with a migration proposal that includes training, integration rebuilds, and ongoing operation. Normalize the boundaries first.

For a platform transition, include data reconciliation, product URL/redirect mapping, analytics continuity, and the search-visibility baseline in that boundary. A working target checkout does not, by itself, establish that the existing route into the store has been preserved.

Possible replatforming triggers include an unsupported platform version with no acceptable upgrade path, a required checkout or pricing behavior that cannot be supported without an unacceptable core fork, or a license/hosting model that fails your own cost comparison. These are hypothetical triggers, not findings about any named platform. Verify support and capability constraints with the vendor's current documentation and a fit-gap on your must-have flows; verify costs with your terms and workload.

Test each option against the actual failure

Import or checkout keeps failing

A single incorrect mapping points toward a fix. Conflicting transformations duplicated across jobs point toward a bounded structural investigation. For checkout, compare each option on the same payment, order, retry and downstream acceptance cases—not just page submission.

Search or navigation returns the wrong result

An incorrect source attribute calls for a data correction; duplicated conflicting category logic may call for refactoring. Replace a search engine only after demonstrating a capability gap on agreed queries and filters.

CRM or loyalty interrupts the order flow

A local timeout-handling defect may need a fix. Coupling that prevents isolation or safe retries may justify a refactor. Moving the storefront while retaining that dependency may carry the failure into the new store.

Another team must take over support

A change of supplier is not a platform gap: test whether the receiving team can operate the retained system. If the failure itself is still unclear, start with the recurring store-failure guide, rather than comparing remedies for different problems.

Compare the options on the same cost and risk lines

Use a common horizon—12 months, for example, if that suits your decision—and a common set of must-have flows. Twelve months here is a comparison choice, not a project-duration promise. Finance should separate verified current costs, supplier estimates, internal effort assumptions, and unquantified exposure.

Comparison structure: one-time work—diagnosis, delivery, transition, data work and training—plus recurring cost over the chosen horizon: licenses, infrastructure, apps, support and manual operating work.

Add the evidence owner, source date, available estimate range and decision-changing uncertainty; keep unquantified incident exposure separate from the total. For a detailed cost ledger and continuity scenarios, see repair or replatform: comparing commerce costs and operational risk.

An import mismatch can justify a fix without choosing a platform

A fictional B2B distributor has an agreed launch process: supplier records must reach the storefront with the correct pack size, category, and filters. Its catalog team manually checks ten batches a month, spending 40 minutes per batch on the affected mapping problem. That is 400 minutes, or six hours and 40 minutes monthly—not the whole catalog team's workload.

The logs show a consistent mismatch between two supplier pack-size values and the channel’s permitted values. Other mappings work. The business also wants a redesigned storefront, but that is a separate goal.

The first candidate is a mapping fix with validation and a clear exception report. Acceptance checks both known values, a missing value, an unsupported value and a corrected re-import, including appearance under the agreed storefront filter. Record input, expected behavior and observed evidence for each case. A job marked “complete” does not satisfy the requirement by itself.

A refactor becomes a stronger candidate if the mapping is duplicated across jobs with conflicting results. Name the shared component and retained behavior; do not quietly absorb the storefront redesign.

A migration becomes a candidate only if a verified requirement cannot be met acceptably within the current arrangement, or the comparable business case supports moving. The ten-batch baseline alone does not establish that case. Over the illustrative 12-month horizon, the current manual burden is 80 hours. That figure is a baseline to test—not a claim that any option will eliminate all 80 hours.

Illustrative structures to distinguish during investigation—not findings about a merchant.

Record the smallest sufficient decision

Record a one-page decision: chosen option, retained systems, excluded work, unresolved assumptions, acceptance scenarios, release/recovery owner, and receiving support owner. If no option has enough evidence, assign the smallest test that would distinguish them.

If you need an external team to implement that decision, the Dinarys Rescue Team page describes a bounded recovery engagement. Choosing a team does not turn a targeted repair into approval for a rebuild.

Ready to define the smallest sufficient scope? Contact Dinarys to talk through your own evidence and options.