Rescuing and replatforming Adobe Commerce projects: how to save implementations in crisis

Not every Adobe Commerce project ends well. We see it consistently — in initial discoveries with new clients and in audits for investors — that a significant share of Adobe Commerce and Magento implementations across LATAM start with promise and end up stuck: slow catalogs, abandoning checkouts, broken ERP integrations, technical debt that doubles the cost of every new feature. When that happens, there are four possible paths: refactor, rescue, replatform or greenfield. Choosing well defines whether the operation recovers in six months or loses another year.

This article describes how we identify struggling Adobe Commerce projects, what we audit before proposing a plan, how we decide between the four options, and the process we apply to take an implementation in crisis to a healthy production state in 3 to 9 months.

When is an Adobe Commerce project in trouble?

Ten recurring signals we see in projects that need intervention:

1. Persistent red Core Web Vitals. LCP > 4s on home and PDP on mobile, CLS > 0.25, INP > 500ms. No improvement after targeted optimizations.
2. Atypically high checkout abandonment (>75% on B2C, >85% on B2B flows), especially at payment or shipping calculation steps.
3. Dangerous releases. Each production deploy takes hours, requires a maintenance window or breaks unrelated features.
4. No automated tests. Zero unit tests, zero integration tests, manual QA on every release.
5. Monolithic custom modules without documentation, written by a team that's no longer around. Every change takes 3-5x more than reasonable.
6. Broken ERP, OMS or PIM integration. Out-of-sync inventory, lost orders, wrong prices, sync by CSV file instead of API.
7. Persistent bugs in tax calculation, MSI (interest-free installments) or promotions, especially when they intersect with OXXO or alternative payment methods.
8. Obsolete stack. Magento Open Source 2.3.x without upgrade path, PHP 7.x, dependencies with unpatched CVEs, legacy themes with hardcoded jQuery.
9. Performance that degrades with growth. The store worked well with 5,000 SKUs and stops working at 20,000. Indexers taking hours, full reindex blocking admin.
10. Frustrated internal team and unclear ownership. The original vendor no longer responds with required urgency, or the relationship broke down over cost escalation.

If three or more of these are present, you have a project in trouble that requires formal intervention — not point patches.

The 4 categories of projects in crisis

When we run an audit, we typically find the issue in one (or several) of these four categories:

1. Critical performance

Red Core Web Vitals, N+1 queries, heavy frontend without lazy loading, no correct CDN edge, no properly configured Varnish or Fastly, broken async indexers. Typical symptom: the store works, but at unacceptable speed. Diagnosis takes 1-2 weeks; fix can be a focused refactor (4-8 weeks) or require replatforming to PWA Studio or a headless frontend.

2. Broken functionality

Incomplete features, business logic poorly modeled in code, unsupported B2B use cases, checkout with intermittent bugs. The platform "works" but leaves money on the table every day. Usually requires deep refactor of the affected module plus automated QA.

3. Obsolete stack

Magento 1 (EOL since 2020), old Magento Open Source without upgrades, PHP out of support, outdated OpenSearch/Elasticsearch, custom themes based on Luma without a modern path. Requires migration to current Adobe Commerce, replatforming or, in extreme cases, greenfield.

4. Architectural debt

Coupled monolith where catalog, checkout, ERP integration and CMS are entangled in custom modules without tests. No CI/CD. No staging that reflects production. No observability. This is the case where a superficial refactor isn't enough — it requires re-thinking the architecture, often moving to composable commerce or headless.

The technical audit: 20 points we evaluate before proposing a plan

Before committing to a rescue plan, we run a structured 2-to-3-week technical audit. It covers six dimensions:

Performance (4 points)

1. Actual production Core Web Vitals (CrUX + Lighthouse), separated by device and page category.
2. Analysis of slow database queries, indexers and full-page cache hit rate.
3. Asset audit: unoptimized images, JS/CSS without tree-shaking, render-blocking fonts.
4. CDN and edge caching (Fastly, CloudFront): TTLs, invalidations, headers, smart routing.

Code and architecture (4 points)

5. Inventory of custom modules: count, cyclomatic complexity, code smells, circular dependencies.
6. Test coverage (unit + integration) and existence of an automated QA pipeline.
7. Anti-Magento patterns: DI bypasses, chained plugins, badly implemented observers.
8. Magento Coding Standards compliance and version-upgrade debt.

Integrations (3 points)

9. Mapping of existing integrations: ERP, OMS, PIM, payment gateways, marketing, BI. Sync mode (real-time, batch, manual).
10. State of custom APIs: documentation, versioning, consumer contracts.
11. Resilience: how timeouts, retries, idempotency and dead letter queues are handled.

Operations (3 points)

12. Deploy pipeline: cadence, release duration, rollback capability, blue-green or canary.
13. Observability: structured logs, metrics, alerts, distributed tracing.
14. Operational documentation: runbooks, on-call, incident response.

Security and compliance (3 points)

15. Known vulnerabilities: missing patches, dependencies with CVEs, admin hardening.
16. PCI-DSS compliance if processing cards. LFPDPPP compliance (personal data in Mexico).
17. Access audit: active admin accounts, credential rotation, privilege separation.

Business (3 points)

18. Real funnel metrics: conversion rate by step, cart abandonment, 4xx/5xx errors per flow.
19. Pending roadmap: what was promised and not delivered, what's needed for next quarter.
20. Total cost of ownership today vs. alternative options (refactor vs. replatform).

The audit deliverable is an executive report + a technical plan prioritized by impact, risk and cost. It's the input for the strategic decision that follows.

Refactor, rescue, replatform or greenfield?

The decision crosses two axes: % of toxic code (undocumented custom code, no tests, anti-patterns) and state of the base architecture (Adobe Commerce version, integrations, infrastructure).

Option	When it applies	Typical duration	Risk
Focused refactor	<30% toxic code, healthy base (recent Adobe Commerce), internal team exists	2-4 months	Low
Full rescue	30-60% toxic code, recoverable base, problematic team and/or vendor	4-8 months	Medium
Replatforming	>60% toxic code, obsolete stack (Magento 1, M2 legacy without upgrade path)	6-12 months	Medium-High
Greenfield	Unviable stack, business model changed, or legacy complexity exceeds cost of starting clean	9-18 months	High

Focused refactor is the most efficient path when the Adobe Commerce base is healthy and the problem is localized: a checkout that needs redesign, an ERP integration that requires modernization, a frontend that justifies moving to headless. It keeps operations running, with controlled cost and value delivered in 2-week sprints.

Full rescue applies when the problem is cross-cutting but the Adobe Commerce version is still viable. It includes initial stabilization (4-6 weeks), refactor of critical modules, introduction of tests, CI/CD and observability, plus a change to the operating model. It's the most common path when a client switches vendors: the platform is alive, the problem is debt + missing practices.

Replatforming applies when the stack is no longer viable: Magento 1 (EOL since 2020 with no security patches), Magento Open Source on versions without a reasonable upgrade path, or when the monolithic architecture blocks the business roadmap. The migration to Adobe Commerce is done preserving SEO, data and customer experience.

Greenfield is the most expensive option and the last we suggest. It applies when: (a) the business model changed radically (from pure B2C to B2B + B2C hybrid, for example), (b) the legacy architecture is so chaotic that rescue cost exceeds starting clean, or (c) there are legal/contractual constraints that prevent continuing with the current stack.

The rescue process we apply across LATAM

When we define that a project requires rescue or replatforming, the typical plan has five phases:

Phase 1 — Discovery & audit (2-3 weeks)

Full technical audit (the 20 points above) + stakeholder interviews + roadmap and business-case review. Deliverable: report + recommendation + estimate.

Phase 2 — Stabilization + quick wins (4-6 weeks)

Before touching the architecture, we stabilize what's bleeding. Put out critical fires: checkout bugs, broken integrations, critical performance on home and PDP. The goal is to buy time and restore the internal team's confidence. In parallel, we introduce basic CI/CD, monitoring and a staging environment that mirrors production.

Phase 3 — Structural plan + architecture (2-4 weeks)

With operations stabilized, we define the target architecture: does it stay on optimized monolithic Adobe Commerce? does it move to composable commerce with a headless frontend? are integrations replaced with modern middleware? The plan gets validated with stakeholders and an updated business case.

Phase 4 — Sprint execution (3-9 months)

Two-week sprints with visible deliverables. Each sprint pays down one piece of critical debt and adds a new capability. Automated tests get built in parallel. Releases move from monthly to weekly or daily. Observability gets consolidated.

Phase 5 — Knowledge transfer + governance (4-8 weeks)

This phase is what separates a sustainable rescue from one that deteriorates again. Living documentation, training for the internal team, governance definition (code review, standards, architecture decisions) and a continuous support model. Ideally the client team is left able to operate autonomously, with us as on-demand backup.

Typical mistakes we see in LATAM

There are patterns that repeat in struggling Adobe Commerce projects in Mexico and broader LATAM:

• Poorly modeled CFDI. The integration with SAT (Mexican Tax Authority) is built as a checkout afterthought instead of modeling RFC, tax regime and CFDI usage from the customer model. Result: every B2B customer requires manual fix, every cross-border sale fails.
• OMS without optimistic locking on multi-channel stock. The online store sells what was physically already sold in store. Systematic overselling, forced returns, destroyed NPS.
• OXXO/SPEI integrated as an isolated module without reconciliation. Confirmed payments that don't appear in the ERP, orders in "payment pending" state for days, saturated support.
• MSI promotions hardcoded by bank instead of data-driven configuration. Every change requires a developer, every new bank is a sprint.
• Live Search without a clear re-indexing schedule. Search returns discontinued products, search conversion rate drops without explanation.
• Custom checkout without E2E tests covering critical flows: guest, registration, MSI, OXXO, invoicing, international shipping address.
• Poorly executed SEO migration during replatforming. Old URLs return 404, no 301 redirects, lost schema markup, Google positions drop 60-80% within weeks.

Most of these mistakes aren't technically complex — they're cultural. Teams that didn't invest in testing, vendors that charged for features but not governance, decisions made without understanding Adobe Commerce in depth. The typical rescue fixes all of these as part of the process.

When to migrate to Adobe Commerce from another platform

Not every rescue is about Adobe Commerce. Sometimes the client is on another platform and the decision is to replatform to Adobe Commerce. Cases where we recommend it:

• Magento 1 EOL. Zero security patches since 2020. PCI compliance impossible. Migration to Adobe Commerce 2 is mandatory.
• Shopify Plus topping out on catalog or customization. Complex B2B catalogs with quotes, purchase lists, hierarchical approvals, per-customer pricing saturate Shopify Plus. Adobe Commerce B2B solves this natively.
• VTEX with impossible custom requirements. When VTEX's extension model doesn't allow the logic the business needs and the workarounds break upgrades.
• Legacy custom platforms. Custom PHP from 10 years ago, Java EE with WebSphere, .NET monolith — where the cost of maintaining far exceeds the cost of migrating.
• Multi-country / multi-brand with fragmented stacks. When the group has 3-5 different platforms by country or brand, consolidating on Adobe Commerce with multi-store + multi-website + Adobe Experience Cloud pays for itself.

How we help

At WolfSellers we are an Adobe Gold Partner with more than 10 years in LATAM and 40 specialists certified in Adobe Commerce. Rescue and replatforming projects are one of our most mature practices: discovery and audit in 2-3 weeks, structural plan with a business case, sprint execution and knowledge transfer to the client team. If your Adobe Commerce or Magento implementation is in trouble, or you're evaluating replatforming to Adobe Commerce, we can run a first technical audit to define the path. Let's talk.

Related services

If this topic is relevant to your business, these WolfSellers services can help you implement it:

• Migration to Adobe Commerce
• Adobe Commerce
• Adobe Commerce Implementation
• Support and maintenance
• Composable Commerce
• ERP Integration
• Consulting