Rescate y replatforming de proyectos Adobe Commerce: cómo salvar implementaciones en problemas

No todos los proyectos de Adobe Commerce salen bien. Vemos consistentemente — en discoveries iniciales con clientes nuevos y en auditorías para inversionistas — que un porcentaje significativo de implementaciones Adobe Commerce y Magento en LATAM arrancan con promesa y terminan estancadas: catálogos lentos, checkouts que abandonan, integraciones rotas con el ERP, deuda técnica que duplica el costo de cada nueva feature. Cuando esto pasa, hay cuatro caminos posibles: refactor, rescate, replatforming o greenfield. Elegir bien define si la operación se recupera en seis meses o se pierde un año más.

Este artículo describe cómo identificamos proyectos Adobe Commerce en problemas, qué auditamos antes de proponer un plan, cómo decidimos entre las cuatro opciones, y cuál es el proceso que aplicamos para llevar una implementación en crisis a producción sana en 3 a 9 meses.

¿Cuándo un proyecto Adobe Commerce está en problemas?

Diez señales recurrentes que vemos en proyectos que necesitan intervención:

1. Core Web Vitals en rojo persistente. LCP > 4s en home y PDP en mobile, CLS > 0.25, INP > 500ms. No mejoran después de optimizaciones puntuales.
2. Checkout con tasa de abandono atípicamente alta (>75% en B2C, >85% en flujos B2B), especialmente en pasos de pago o cálculo de envío.
3. Releases peligrosos. Cada deploy a producción dura horas, requiere ventana de mantenimiento o rompe features no relacionadas.
4. Ausencia de tests automatizados. Cero unit tests, cero integration tests, manual QA en cada release.
5. Custom modules monolíticos sin documentación, escritos por un equipo que ya no está. Cada cambio tarda 3-5 veces más de lo razonable.
6. Integración rota con ERP, OMS o PIM. Inventario desincronizado, pedidos perdidos, precios incorrectos, sincronización por archivo CSV en lugar de API.
7. Bugs persistentes en cálculo de impuestos, MSI (meses sin intereses) o promociones, especialmente cuando se cruzan con OXXO o métodos alternativos de pago.
8. Stack obsoleto. Magento Open Source 2.3.x sin upgrade path, PHP 7.x, dependencias con CVEs sin parchar, themes legacy con jQuery hardcodeado.
9. Performance que se degrada con el crecimiento. La tienda funcionaba bien con 5,000 SKUs y deja de funcionar con 20,000. Indexers tardando horas, full reindex bloqueando admin.
10. Equipo interno frustrado y sin ownership claro. El vendor original ya no responde con la rapidez necesaria, o la relación se rompió por escalamiento de costos.

Si tres o más de estos puntos están presentes, hay un proyecto en problemas que requiere intervención formal — no parches puntuales.

Las 4 categorías de proyectos en crisis

Cuando entramos a un audit, encontramos el problema en una (o varias) de estas cuatro categorías:

1. Performance crítico

Core Web Vitals rojos, base de datos con queries N+1, frontend pesado sin lazy loading, sin CDN edge correcto, sin Varnish o Fastly bien configurado, indexers asíncronos rotos. Síntoma típico: la tienda funciona, pero a velocidad inaceptable. Diagnóstico se hace en 1-2 semanas; fix puede ser refactor focalizado (4-8 semanas) o requerir replatforming a PWA Studio o frontend headless.

2. Funcionalidad rota

Features incompletas, lógica de negocio mal modelada en código, casos de uso B2B sin soportar, checkout con bugs intermitentes. La plataforma "funciona" pero deja dinero en la mesa todos los días. Suele requerir refactor profundo del módulo afectado más QA automatizado.

3. Stack obsoleto

Magento 1 (EOL desde 2020), Magento Open Source viejo sin upgrades, PHP fuera de soporte, OpenSearch/Elasticsearch desactualizado, custom themes basados en Luma sin path moderno. Requiere migración a Adobe Commerce actual, replatforming o, en casos extremos, greenfield.

4. Deuda arquitectónica

Monolito acoplado donde el catálogo, checkout, ERP integration y CMS están entrelazados en custom modules sin tests. CI/CD inexistente. Sin staging que refleje producción. Sin observabilidad. Es el caso donde un refactor superficial no alcanza — requiere replantear arquitectura, frecuentemente moviendo a composable commerce o headless.

El audit técnico: 20 puntos que evaluamos antes de proponer plan

Antes de comprometernos a un plan de rescate, hacemos un audit técnico estructurado de 2 a 3 semanas. Cubre seis dimensiones:

Performance (4 puntos)

1. Core Web Vitals reales en producción (CrUX + Lighthouse), separados por device y categoría de página.
2. Análisis de queries de base de datos lentas, indexers y full-page cache hit rate.
3. Auditoría de assets: imágenes sin optimizar, JS/CSS sin tree-shaking, fuentes bloqueando render.
4. CDN y edge caching (Fastly, CloudFront): TTLs, invalidaciones, headers, smart routing.

Código y arquitectura (4 puntos)

5. Inventario de custom modules: cuántos, complejidad ciclomática, code smells, dependencias circulares.
6. Coverage de tests (unit + integration) y existencia de pipeline de QA automatizado.
7. Patrones anti-Magento: bypasses del DI, plugins encadenados, observers mal implementados.
8. Cumplimiento de Magento Coding Standards y deuda de upgrades de versión.

Integraciones (3 puntos)

9. Mapeo de integraciones existentes: ERP, OMS, PIM, payment gateways, marketing, BI. Sync mode (real-time, batch, manual).
10. Estado de las APIs custom: documentación, versionado, contratos con consumidores.
11. Resilencia: cómo se manejan timeouts, retries, idempotencia, dead letter queues.

Operación (3 puntos)

12. Pipeline de deploy: cadencia, tiempo de release, capacidad de rollback, blue-green o canary.
13. Observabilidad: logs estructurados, métricas, alertas, distributed tracing.
14. Documentación operativa: runbooks, on-call, incident response.

Seguridad y compliance (3 puntos)

15. Vulnerabilidades conocidas: patches faltantes, dependencies con CVEs, hardening de admin.
16. Cumplimiento PCI-DSS si procesa tarjeta. Cumplimiento LFPDPPP (datos personales en México).
17. Auditoría de accesos: cuentas admin activas, rotación de credenciales, separación de privilegios.

Negocio (3 puntos)

18. Métricas reales de funnel: tasa de conversión por step, abandono de carrito, errores 4xx/5xx por flujo.
19. Roadmap pendiente: qué se prometió y no se entregó, qué se necesita para el próximo cuarto.
20. Costo total de propiedad actual vs. opciones alternativas (refactor vs. replatform).

El entregable del audit es un informe ejecutivo + plan técnico priorizado por impacto, riesgo y costo. Es el insumo para la decisión estratégica que sigue.

¿Refactor, rescate, replatforming o greenfield?

La decisión se toma cruzando dos ejes: % de código tóxico (custom no documentado, sin tests, anti-patrón) y estado de la arquitectura base (versión Adobe Commerce, integraciones, infraestructura).

Opción	Cuándo aplica	Duración típica	Riesgo
Refactor focalizado	<30% código tóxico, base sana (Adobe Commerce reciente), equipo interno existe	2-4 meses	Bajo
Rescate completo	30-60% código tóxico, base recuperable, equipo y/o vendor problemático	4-8 meses	Medio
Replatforming	>60% código tóxico, stack obsoleto (Magento 1, M2 legacy sin upgrade path)	6-12 meses	Medio-Alto
Greenfield	Stack inviable, modelo de negocio cambió, o la complejidad del legacy supera costo de empezar de cero	9-18 meses	Alto

Refactor focalizado es el camino más eficiente cuando la base de Adobe Commerce está sana y el problema es localizado: un checkout que necesita rediseño, una integración ERP que requiere modernización, un frontend que justifica pasar a headless. Mantiene operación, costo controlado y entrega valor en sprints de 2 semanas.

Rescate completo aplica cuando el problema es transversal pero la versión de Adobe Commerce sigue siendo viable. Incluye estabilización inicial (4-6 semanas), refactor de los módulos críticos, introducción de tests, CI/CD y observabilidad, más cambio del modelo de operación. Es lo más común cuando un cliente cambia de vendor: la plataforma vive, el problema es deuda + falta de practices.

Replatforming aplica cuando el stack ya no es viable: Magento 1 (EOL desde 2020 sin parches de seguridad), Magento Open Source en versiones sin upgrade path razonable, o cuando la arquitectura monolítica frena el roadmap de negocio. La migración a Adobe Commerce se hace con preservación de SEO, datos y experiencia de cliente.

Greenfield es la opción más cara y la última que sugerimos. Aplica cuando: (a) el modelo de negocio cambió radicalmente (de B2C puro a B2B + B2C híbrido, por ejemplo), (b) la arquitectura legacy es tan caótica que el costo de rescate supera el costo de empezar limpio, o (c) hay restricciones legales/contractuales que impiden seguir con el stack actual.

El proceso de rescate que aplicamos en LATAM

Cuando definimos que un proyecto requiere rescate o replatforming, el plan típico tiene cinco fases:

Fase 1 — Discovery & audit (2-3 semanas)

Audit técnico completo (los 20 puntos arriba) + entrevistas con stakeholders + revisión de roadmap y business case. Entregable: informe + recomendación + estimación.

Fase 2 — Estabilización + quick wins (4-6 semanas)

Antes de tocar la arquitectura, estabilizamos lo que sangra. Apagar fuegos críticos: bugs de checkout, integraciones rotas, performance crítica en home y PDP. El objetivo es comprar tiempo y restaurar confianza del equipo interno. En paralelo, introducimos CI/CD básico, monitoreo y staging que refleje producción.

Fase 3 — Plan estructural + arquitectura (2-4 semanas)

Con la operación estabilizada, definimos arquitectura objetivo: ¿se queda en Adobe Commerce monolítico optimizado? ¿se mueve a composable commerce con frontend headless? ¿se reemplazan integraciones por middleware moderno? El plan se valida con stakeholders y business case actualizado.

Fase 4 — Ejecución por sprints (3-9 meses)

Sprints de dos semanas con entregables visibles. Cada sprint baja un punto de deuda crítica y suma una capacidad nueva. Tests automatizados se construyen en paralelo. Releases se mueven de mensuales a semanales o diarios. Observabilidad se consolida.

Fase 5 — Knowledge transfer + governance (4-8 semanas)

Esta fase es la que separa un rescate sostenible de uno que vuelve a deteriorarse. Documentación viva, training al equipo interno, definición de governance (code review, standards, decisión de arquitectura) y modelo de soporte continuo. Idealmente el equipo cliente queda en capacidad de operar autónomamente, con nosotros como respaldo on-demand.

Errores típicos que vemos en LATAM

Hay patrones que se repiten en proyectos Adobe Commerce con problemas en el mercado mexicano y LATAM:

• CFDI mal modelado. La integración con SAT se construye como afterthought en el checkout en lugar de modelar el RFC, régimen fiscal y uso de CFDI desde el customer model. Resultado: cada cliente B2B requiere fix manual y cada venta cross-border falla.
• OMS sin lock optimista en stock multi-canal. La tienda online vende lo que físicamente ya se vendió en tienda. Overselling sistemático, devoluciones forzadas, NPS destruido.
• OXXO/SPEI integrados como módulo aislado sin reconciliación. Pagos confirmados que no aparecen en el ERP, pedidos en estado "pago pendiente" durante días, soporte saturado.
• Promociones MSI hardcodeadas por banco en lugar de configuración data-driven. Cada cambio requiere developer, cada banco nuevo es un sprint.
• Live Search sin schedule de re-indexing claro. Búsqueda devuelve productos descontinuados, conversion rate de search baja sin explicación.
• Custom checkout sin tests E2E que cubran flujos críticos: invitado, registro, MSI, OXXO, factura, dirección de envío internacional.
• Migración SEO mal hecha en replatforming. URLs antiguas devuelven 404, redirects 301 inexistentes, schema markup perdido, posiciones en Google caen 60-80% en semanas.

La mayoría de estos errores no son técnicamente complejos — son culturales. Equipos que no invirtieron en testing, vendors que cobraron por features pero no por governance, decisiones tomadas sin entender Adobe Commerce a profundidad. El rescate típico arregla todos ellos como parte del proceso.

Cuándo migrar a Adobe Commerce desde otra plataforma

No todos los rescates son sobre Adobe Commerce. A veces el cliente está en otra plataforma y la decisión es replatformar hacia Adobe Commerce. Los casos donde lo recomendamos:

• Magento 1 EOL. Cero parches de seguridad desde 2020. PCI compliance imposible. Migración a Adobe Commerce 2 es obligada.
• Shopify Plus topando catálogo o customización. Catálogos B2B complejos con cotizaciones, listas de compra, aprobaciones jerárquicas, precios por cliente saturan Shopify Plus. Adobe Commerce B2B resuelve nativamente.
• VTEX con requirements custom imposibles. Cuando el modelo de extension de VTEX no permite la lógica que el negocio requiere y los workarounds rompen upgrades.
• Plataformas custom legacy. PHP custom de hace 10 años, Java EE con WebSphere, .NET monolítico — donde el costo de mantener supera con creces el costo de migrar.
• Multi-país / multi-marca con stacks fragmentados. Cuando el grupo tiene 3-5 plataformas diferentes por país o marca, consolidar en Adobe Commerce con multi-store + multi-website + Adobe Experience Cloud paga sola.

Cómo te ayudamos

En WolfSellers somos Adobe Gold Partner con más de 10 años en LATAM y 40 specialists certificados en Adobe Commerce. Los proyectos de rescate y replatforming son una de nuestras prácticas más maduras: discovery y audit en 2-3 semanas, plan estructural con business case, ejecución por sprints y knowledge transfer al equipo cliente. Si tu implementación Adobe Commerce o Magento está en problemas, o estás evaluando replatforming hacia Adobe Commerce, podemos hacer un primer audit técnico para definir el camino. Hablemos.

Servicios relacionados

Si este tema es relevante para tu negocio, estos servicios de WolfSellers pueden ayudarte a implementarlo:

• Migración a Adobe Commerce
• Adobe Commerce
• Implementación Adobe Commerce
• Soporte y mantenimiento
• Composable Commerce
• Integración ERP
• Consultoría