Deuda técnica en Adobe Commerce: cómo medirla y reducirla

Cada upgrade cuesta más que el anterior. Una extensión que nadie recuerda por qué se instaló bloquea el cambio de PHP, un parche "temporal" de hace tres años se rompe en la siguiente versión y el equipo pasa más horas apagando incendios que construyendo. Eso es deuda técnica en Adobe Commerce (antes Magento): no se ve en el sitio, pero se paga en cada sprint. Y en 2026 tiene fechas de vencimiento concretas, porque Adobe ya publicó cuándo deja de dar soporte a cada versión y qué pasa en su nube con las tiendas que no se actualizan.

En WolfSellers damos soporte, mantenimiento y upgrades a tiendas de Adobe Commerce en México. Esta nota va un paso antes de un rescate: qué es la deuda técnica, de dónde sale, cómo medirla con las herramientas oficiales, cómo priorizarla y cómo pagarla sin frenar el negocio. Si tu proyecto ya está en crisis, el camino es otro y lo cubrimos en la guía de rescate y replatforming de proyectos Adobe Commerce. Lo que decimos de funciones de Adobe sale de su documentación en Experience League, revisada en octubre de 2026.

---

Qué es la deuda técnica en Adobe Commerce

La deuda técnica es el costo futuro de las decisiones que hoy ahorran tiempo: un parche en lugar de una corrección, una extensión que nadie mantiene, una personalización que reemplaza código de Adobe en vez de extenderlo. Como una deuda financiera, genera intereses: cada cambio nuevo cuesta más, cada upgrade se alarga y el riesgo de seguridad crece mientras no se paga.

En Adobe Commerce se acumula en tres capas:

1. Plataforma: la versión de Adobe Commerce y de sus dependencias (PHP, base de datos, OpenSearch, caché, colas de mensajes) se acerca a su fin de soporte o ya lo pasó.
2. Código: personalizaciones que se apartan de las prácticas de Adobe y extensiones de terceros que nadie revisa.
3. Operación: cron e indexadores mal configurados, parches acumulados, tablas que crecen sin control, integraciones frágiles y falta de pruebas.

¿Por qué se acumula? La guía de upgrades de Adobe lo explica: la flexibilidad de la plataforma es una ventaja, pero las personalizaciones que no siguen las buenas prácticas elevan el costo de cada actualización, y postergar upgrades acumula deuda que encarece el siguiente. Además, Adobe no da parches a dependencias de terceros como PHP o MariaDB: tu versión de Adobe Commerce puede tener soporte y el stack que corre debajo, no.

No toda la deuda es mala: salir a tiempo para El Buen Fin con un atajo documentado puede ser la decisión correcta. El problema es la deuda que nadie registró ni planea pagar.

De dónde sale la deuda técnica en Adobe Commerce

Las guías de Adobe respaldan tres de estas filas. Describe las preferences como una forma "codiciosa" (greedy) de cambiar la aplicación, que puede chocar con módulos de terceros y bloquear actualizaciones del núcleo. Pide evitar los plugins around que no hacen falta, porque alargan los stack traces y afectan el rendimiento; desde la 2.2, un plugin after ya recibe los parámetros del método. Y advierte que modificar una tabla grande retrasa el despliegue minutos u horas.

Hasta cuándo tiene soporte tu versión de Adobe Commerce

Adobe da tres años de soporte estándar desde la disponibilidad general (GA) de cada versión, con parches de calidad y de seguridad. A varias versiones les suma un año de soporte extendido sin costo, y 2.4.4, 2.4.5 y 2.4.6 tienen un periodo final solo con correcciones de seguridad, que Adobe pide tratar como tiempo para migrar. Fechas de su política de ciclo de vida, actualizada el 18 de septiembre de 2026:

Además, Adobe ahora publica parches de seguridad aislados cada mes, el segundo martes. No son acumulativos: se aplican en orden y solo están probados sobre el parche de seguridad (-pN) más reciente de tu línea. Si vas atrasado en los -pN, no puedes aplicar los mensuales.

PHP: la fecha que suele llegar primero

Cruzando los requisitos del sistema de Adobe con el calendario oficial de PHP:

Un caso típico: una tienda en 2.4.6 tiene soporte extendido de Adobe hasta el 31 de agosto de 2027, pero su PHP más nuevo, el 8.2, deja de recibir parches el 31 de diciembre de 2026, y la política de Adobe advierte que correr PHP fuera de soporte pone en riesgo el cumplimiento de PCI. Los servicios también se mueven: en los últimos parches de 2.4.5, 2.4.6 y 2.4.7, los requisitos ya marcan Redis como no soportado y piden Valkey.

Adobe Commerce en la nube: fechas con consecuencias

Para Adobe Commerce on Cloud (la versión PaaS, de la 2.4.4 a la 2.4.9), Adobe publicó fechas obligatorias:

• Dependencias (PHP, MariaDB, Elasticsearch, OpenSearch, Redis y RabbitMQ): según el servicio y la versión, la fecha límite es el 30 de octubre de 2026 o el 31 de mayo de 2027.
• Versión de Adobe Commerce: 2.4.4 y 2.4.5 deben actualizarse o migrar a Adobe Commerce as a Cloud Service antes del 1 de junio de 2027; 2.4.6 y 2.4.7, antes del 1 de junio de 2028.
• Consecuencia: Adobe puede suspender el acceso al admin o el tráfico de entrada, y en ese caso la tienda queda fuera de línea.

Adobe advierte que pasar de Elasticsearch a OpenSearch o de Redis a Valkey es un cambio de software, no de versión, y que el código propio y las extensiones pueden necesitar ajustes. Estas fechas no aplican a Adobe Commerce as a Cloud Service ni a on-premises, donde mantener todo con soporte depende solo de ti.

Cómo medir la deuda técnica en Adobe Commerce

Medir es convertir "todo cuesta mucho" en una lista con dueño y fecha. Usamos tres fuentes: las herramientas de Adobe, un inventario de lo instalado y los datos de producción.

Herramientas oficiales y su estado en octubre de 2026

En Magento Open Source no hay Upgrade Compatibility Tool: el análisis se apoya en el estándar de código, Composer y revisión manual. Y la opción --vanilla-dir del UCT compara tu núcleo contra una copia limpia de tu versión; Adobe pide limpiar esas modificaciones antes del upgrade.

Inventario de extensiones y personalizaciones

Adobe identifica la revisión de los módulos propios como la parte del upgrade que más tiempo y recursos consume. Por cada módulo registramos origen (Marketplace, otro proveedor o propio), versión instalada frente a la más reciente, compatibilidad con la versión destino y con PHP, uso real, qué intercepta (preferences, plugins, plantillas) y quién es su dueño interno. La política de Adobe Commerce Marketplace pide que sus extensiones sean compatibles con la versión más reciente dentro de los 30 días posteriores a su GA.

Datos de producción con New Relic

Las herramientas dicen qué está mal; los datos de producción dicen cuánto cuesta. En Adobe Commerce en la nube, New Relic APM viene incluido: transacciones lentas, consultas que más tiempo consumen, servicios externos que frenan el checkout y el efecto de cada despliegue. Lo explicamos en la nota de monitoreo y observabilidad de Adobe Commerce con New Relic.

Con esas fuentes armamos un tablero. Los umbrales son nuestra recomendación:

Cómo priorizar la deuda técnica

No se paga todo a la vez. Clasificamos cada hallazgo en una de cuatro categorías:

Luego lo ubicamos en una matriz de impacto contra esfuerzo:

Una regla que no negociamos: la seguridad y las fechas de fin de soporte van primero, aunque el esfuerzo sea alto. Esas no esperan a la matriz.

Un ejemplo ilustrativo de cómo queda el backlog:

Cómo reducir la deuda técnica sin frenar el negocio

Capacidad reservada en cada sprint

Nuestra recomendación: reservar una parte fija de cada sprint para deuda, acordada con el negocio y visible en el backlog. Como punto de partida proponemos alrededor de una quinta parte y la ajustamos con los indicadores. Sale más barato que el "proyecto de deuda" que nunca encuentra presupuesto.

Upgrades frecuentes y pequeños

Adobe recomienda actualizar en cada ciclo de parches y recuerda que, para mantener el cumplimiento de PCI, hay que estar en el último parche o parche de seguridad. Su guía de upgrades lo plantea en términos de costo: actualizar con regularidad requiere menos esfuerzo total que hacerlo de vez en cuando, porque los cambios son incrementales; cuando se difiere, el upgrade crece y arrastra extensiones e integraciones. Un salto grande junta todo, incluidos PHP y los servicios, y suele llegar con la fecha de fin de soporte encima.

Quitar lo que sobra

• Extensiones sin uso: desinstálalas con Composer. Deshabilitar un módulo deja su código y sus dependencias en el proyecto.
• Parches propios: Adobe los considera temporales y recomienda reemplazarlos por una corrección permanente en las siguientes dos a cuatro semanas.
• Parches de calidad: la documentación del Quality Patches Tool advierte que aplicar muchos complica el código y el siguiente upgrade.

Reemplazar preferences por plugins u observers

La guía de Adobe para modificar código del núcleo y de terceros pide elegir siempre la opción de menor alcance. El orden que seguimos:

1. Observer, si el núcleo dispara un evento donde lo necesitas.
2. Plugin before o after, para cambiar argumentos o resultados de un método público.
3. Plugin around, solo si hay que detener la ejecución del método original.
4. Preference, solo si nada de lo anterior alcanza, y registrada como deuda.

Para datos extra, extension attributes en lugar de columnas nuevas en tablas del núcleo.

Sacar personalizaciones del proceso

Con la extensibilidad fuera de proceso (out-of-process), la lógica propia corre como aplicación en Adobe Developer App Builder y se conecta con la tienda por APIs, eventos de Adobe I/O y webhooks, sin agregar PHP al código de Commerce. API Mesh, sobre App Builder, une varias APIs en un endpoint GraphQL. Adobe recomienda este modelo para apps nuevas y para modernizar personalizaciones, porque la app se despliega con su propio ciclo, independiente de los upgrades. No todo conviene sacarlo: dentro del proceso sigues teniendo un control profundo y síncrono. Los mejores candidatos son las integraciones con ERP, OMS o CRM y los procesos pesados.

Pesa más si piensas migrar a Adobe Commerce as a Cloud Service, la versión SaaS. Ahí Adobe aplica las actualizaciones (con 30 días para probarlas en sandbox), garantiza compatibilidad hacia atrás para las personalizaciones que siguen el modelo API-first, trae App Builder configurado y no admite storefronts Luma. Su política de ciclo de vida la presenta como el destino recomendado a largo plazo para Adobe Commerce on Cloud. Lo explicamos en Adobe Commerce as a Cloud Service y Edge Delivery Services.

Pruebas automatizadas

Sin pruebas, cada pago de deuda es una apuesta. Empezamos por los flujos que más dinero mueven (checkout, carrito, búsqueda, pagos y facturación) y sumamos pruebas unitarias en cada módulo que se toca. Es parte de nuestro servicio de QA y testing.

Cómo explicarle la deuda técnica al negocio

Dirección no aprueba presupuesto para "refactorizar". Aprueba para reducir un riesgo con fecha o un costo que ya está pagando. La traducción que usamos:

Además de las fechas, dos argumentos funcionan. El primero es seguridad y PCI: Adobe recuerda que evaluar el cumplimiento le toca al comercio, con su asesor de seguridad calificado (QSA); qué exige hoy PCI DSS 4.0 a un checkout lo explicamos en PCI DSS 4.0 en ecommerce. El segundo es el costo de cada cambio: el tiempo que tarda un cambio pequeño en llegar a producción y la parte del sprint que se va en correctivo son cifras que dirección entiende, y un upgrade planeado suele costar menos que uno urgente.

Cuándo la deuda técnica ya justifica un rescate o un replatform

Pagar deuda por sprints funciona mientras la base sea recuperable. Estas señales indican que ya no alcanza:

1. La versión no tiene soporte y no hay una ruta realista a una versión soportada antes de la fecha límite.
2. El Upgrade Compatibility Tool reporta problemas críticos en buena parte del código propio y el núcleo está modificado: el upgrade equivale a rehacer.
3. Varios trimestres seguidos con más trabajo correctivo que nuevo, aun con capacidad reservada.
4. Extensiones críticas abandonadas sin reemplazo en el mercado.
5. Un storefront Luma tan personalizado que cambiar de frontend cuesta lo mismo que rehacerlo, sobre todo si el destino es Adobe Commerce as a Cloud Service.
6. Magento 1 o una plataforma sin ruta de upgrade.

En esos casos, seguir pagando intereses sale más caro que reestructurar. Cómo decidir entre refactor, rescate, replatform o empezar de cero está en la guía de rescate y replatforming. Si vienes de Magento Open Source, lee nuestra guía para migrar a Adobe Commerce y la comparativa entre Adobe Commerce y Magento Open Source.

Errores frecuentes al gestionar la deuda técnica

1. Tratarla como un proyecto único que se hará "cuando haya tiempo".
2. Vigilar solo la versión de Adobe Commerce y olvidar PHP y los demás servicios.
3. Dejar que los parches temporales se vuelvan permanentes.
4. Resolver todo con preferences porque hoy es más rápido.
5. Actualizar sin pruebas de regresión del checkout y las integraciones.
6. Pagar deuda que no importa, como refactors cosméticos, mientras se acerca el fin de soporte.
7. No registrar la deuda nueva: cada atajo sin ticket es deuda invisible.

Cómo lo hacemos en WolfSellers

Empezamos con un diagnóstico: inventario de extensiones y personalizaciones, las herramientas de Adobe que aplican a tu edición y los datos de producción. Entregamos un backlog de deuda con categoría, impacto, esfuerzo y fecha límite, y un calendario de upgrades alineado con el de Adobe. Después la pagamos por sprints, con capacidad reservada y los indicadores a la vista del negocio.

Para no generar deuda nueva, cada módulo que escribimos sigue el mismo estándar:

• Interruptor en el admin para encenderlo y apagarlo sin redeploy.
• Log propio, separado de los logs generales.
• Permisos (ACL) para su configuración.
• Pruebas unitarias de su configuración y su lógica.
• README con pasos de verificación, de rollback y el impacto en caché.
• Validación con phpcs (estándar Magento2) y bin/magento setup:di:compile antes de cada PR.
• Plugins around solo cuando están justificados; primero observers, before y after.

Somos Adobe Solution Partner nivel Gold, con un equipo de 135 personas que opera desde la Ciudad de México en modelo nearshore. Nuestro servicio de soporte y mantenimiento da atención 24/7 en los planes Business y Enterprise (Starter es 8x5). Si la tienda necesita algo más que mantenimiento, entran rescate y optimización o migración a Adobe Commerce. Si quieres revisar tu caso, escríbenos.

---

Preguntas frecuentes sobre deuda técnica en Adobe Commerce

¿Qué es la deuda técnica en Adobe Commerce?

Es el costo futuro de decisiones que hoy ahorran tiempo: versiones y PHP sin actualizar, extensiones abandonadas, preferences, cambios al núcleo y parches temporales. Se paga con upgrades más caros, cambios lentos y riesgo de seguridad.

¿Cuánto tiempo de soporte tiene cada versión de Adobe Commerce?

Tres años de soporte estándar desde su disponibilidad general: 2.4.7 hasta el 31 de mayo de 2027, 2.4.8 hasta el 31 de mayo de 2028 y 2.4.9 hasta el 31 de mayo de 2029. 2.4.6 y 2.4.7 suman un año de soporte extendido.

¿Cómo sé cuánta deuda técnica tiene mi tienda?

Con el Upgrade Compatibility Tool contra la versión destino, el estado de parches de seguridad, composer audit, phpcs, un inventario de extensiones y los datos de New Relic. El resultado es un backlog con categoría, impacto, esfuerzo y fecha.

¿El Upgrade Compatibility Tool funciona en Magento Open Source?

No. Requiere licencia de Adobe Commerce. En Magento Open Source el análisis se hace con el estándar de código, Composer y revisión manual; la Security Scan Tool y la Commerce Version Tool sí están disponibles para esa edición.

¿Qué pasa si mi versión de PHP queda fuera de soporte?

PHP deja de recibir correcciones de seguridad y Adobe no las suple. Su política de ciclo de vida señala que eso pone en riesgo el cumplimiento de PCI. PHP 8.1 terminó el 31 de diciembre de 2025 y PHP 8.2 termina el 31 de diciembre de 2026.

¿Conviene actualizar seguido o hacer un salto grande?

Seguido. Adobe recomienda actualizar en cada ciclo de parches y documenta que los upgrades regulares requieren menos esfuerzo total que los esporádicos.

¿Migrar a Adobe Commerce as a Cloud Service elimina la deuda técnica?

Elimina la de plataforma, porque Adobe opera y actualiza la aplicación, pero no la de tu código: Adobe solo garantiza compatibilidad para las personalizaciones que siguen su modelo API-first, y no admite storefronts Luma. Conviene pagar deuda antes de migrar.

¿Cuándo conviene un rescate en lugar de seguir pagando la deuda?

Cuando no hay ruta a una versión con soporte antes de la fecha límite, cuando el núcleo modificado hace que el upgrade equivalga a rehacer, o cuando el trabajo correctivo supera al nuevo durante varios trimestres.

Servicios relacionados

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

• Adobe Commerce
• Implementación Adobe Commerce
• Migración a Adobe Commerce