Qué dejas pasar cuando no realizas las migraciones a tiempo

Postergar la migración de Adobe Commerce, la plataforma que muchos conocen todavía como Magento, cuesta más que hacerla: cada versión sin soporte deja de recibir parches de seguridad, se aleja de los componentes modernos que exigen los medios de pago y los proveedores de infraestructura, y acumula una deuda técnica que el negocio termina pagando en ventas perdidas, riesgo de incidentes y proyectos que no pueden arrancar.

Es octubre y el comité de dirección de una cadena regional de tiendas revisa el plan de la temporada alta. El director de tecnología pide que se congele cualquier cambio en la tienda en línea hasta enero, porque el sitio funciona y nadie quiere tocarlo antes de las ventas más importantes del año. La directora financiera escucha con atención y pregunta lo que pocos se atreven a preguntar. ¿Hasta cuándo es seguro no tocarlo? La respuesta incómoda es que el sitio funciona precisamente porque lleva años sin tocarse, y que cada mes de espera encarece la migración que tarde o temprano habrá que hacer. Lo que parecía una decisión de prudencia se convierte, vista con calma, en una apuesta con un riesgo que nadie ha puesto en un número.

Esa conversación se repite en muchas empresas con tiendas construidas sobre Magento 2.3, una versión cuyo soporte regular terminó el 8 de septiembre de 2022, y en otras con tiendas en versiones 2.4 tempranas que hoy también están fuera de su ventana de soporte. Este artículo explica qué se deja pasar cuando las migraciones se aplazan, por qué la decisión es de negocio antes que técnica, cómo ha cambiado el panorama desde que se planteó el salto de 2.3 a 2.4 y cómo conducir una actualización con criterio, con una guía breve y vigente de los pasos técnicos.

Qué se deja pasar cuando no se realizan las migraciones a tiempo

La experiencia de los consultores de ICX en proyectos de Magento identifica cuatro pérdidas que se repiten cuando una tienda se queda en una versión anterior. Conviene recorrerlas con el lente del ejecutivo, porque cada una se traduce en un costo distinto.

La primera es el rendimiento. La versión 2.4 incorporó una arquitectura más moderna y optimizada, con tiempos de carga más rápidos y una mejor experiencia para el usuario. Una tienda lenta y poco receptiva pierde clientes y ventas, y la pérdida no aparece en ninguna línea del estado de resultados como tal. Se manifiesta como menor conversión, más abandono de carrito y una atención de soporte que explica a los clientes por qué el sitio no responde. La velocidad es parte de la experiencia de compra, y el cliente la juzga igual que juzga la amabilidad de un vendedor en una tienda física.

La segunda es la seguridad. Una versión sin soporte no recibe correcciones, y las vulnerabilidades se publican con detalle suficiente para que cualquiera las explote. Un ejemplo ilustra el riesgo real. El boletín de seguridad APSB24-40 de Adobe, publicado el 11 de junio de 2024, describió la vulnerabilidad CVE-2024-34102, de tipo XML External Entity, con una calificación crítica de 9.8 sobre 10 que no requiere autenticación, y Adobe indicó que tenía conocimiento de ataques limitados contra comercios de Adobe Commerce. Una tienda que no aplica parches o que ya no los recibe queda expuesta a incidentes que comprometen datos de clientes y reputación, y para un comercio que procesa pagos con tarjeta, también el cumplimiento de PCI.

La tercera son las funcionalidades. Cada versión incorpora mejoras en integraciones, medios de pago, gestión de inventario y administración. Al no actualizar, la empresa se pierde capacidades que sus competidores ya usan y termina construyendo a medida, con costo propio, lo que la plataforma ofrece de forma nativa. La cuarta es la compatibilidad. Los consultores de ICX señalaban que Magento 2.4 era compatible con tecnologías entonces recientes, como PHP 7.4, Elasticsearch 7.x y MySQL 8.0. Hoy esa referencia ha quedado superada, y vale la pena detenerse en ello porque es el corazón del problema.

¿Por qué es fundamental realizar la migración?

La razón de mayor peso es garantizar la seguridad y la estabilidad del comercio electrónico. Al actualizar se obtienen correcciones de seguridad y parches que protegen el negocio frente a vulnerabilidades y ataques, además de acceso a mejoras de rendimiento, nuevas funcionalidades y compatibilidad con tecnologías actuales. Esto permite ofrecer una experiencia de compra mejorada, optimizar las operaciones comerciales y mantener el negocio alineado con los estándares más recientes del comercio electrónico.

Hay un argumento adicional que el ejecutivo debería llevar a la mesa, y es que el costo de migrar no es constante en el tiempo. Una tienda que salta una o dos versiones dentro de la misma línea suele requerir ajustes menores. Una que acumula años de retraso enfrenta cambios de versión de PHP, de motor de búsqueda y de base de datos, extensiones que ya no se mantienen y personalizaciones que dependen de comportamientos que cambiaron. Cada capa de retraso multiplica el esfuerzo de prueba y el riesgo de regresiones. La migración temprana es la más barata, y la más cara es la que se hace de emergencia después de un incidente.

Cómo ha cambiado el panorama: de 2.3 y 2.4 a la política de soporte actual

El salto de 2.3 a 2.4 era, en su momento, la gran decisión pendiente. Hoy la línea 2.4 lleva años de evolución y Adobe publica versiones con una política de soporte explícita. Según la política de ciclo de vida de Adobe Commerce, cada versión cuenta con una ventana de soporte estándar de tres años desde su disponibilidad general, y las versiones 2.4.6 y 2.4.7 reciben además un año adicional de soporte extendido. La versión 2.4.8 salió el 8 de abril de 2025 con soporte estándar hasta el 31 de mayo de 2028, y la 2.4.9 salió el 12 de mayo de 2026 con soporte estándar hasta el 31 de mayo de 2029.

La misma política muestra el costo de esperar. La versión 2.4.4 terminó su soporte extendido el 14 de abril de 2026, la 2.4.5 el 11 de agosto de 2026 y la 2.4.6 terminó su soporte estándar el 11 de agosto de 2026. Además, a partir del 1 de junio de 2027 Adobe dejará de mantener entornos en la nube que ejecuten versiones sin soporte, y las tiendas afectadas podrían quedar fuera de línea. Para una empresa con ingresos en línea relevantes, esa fecha es un plazo de negocio, no un detalle de infraestructura.

También cambiaron los requisitos tecnológicos. Según los requisitos de sistema de Adobe Commerce, la versión 2.4.9 se ejecuta sobre PHP 8.5, OpenSearch 3 y MariaDB 12.3 (con MySQL 8.4 en instalaciones propias), mientras que la 2.4.8 admite PHP 8.4 u 8.3. Las referencias a PHP 7.4, Elasticsearch 7.x y MySQL 8.0 que sirvieron para explicar el beneficio de 2.4 corresponden a un ecosistema que ya salió de soporte, y la propia documentación advierte que PHP 8.1 llegó al fin de su vida útil el 31 de diciembre de 2025 y que PHP 8.2 la alcanza el 31 de diciembre de 2026, con riesgo para el cumplimiento de PCI en las versiones afectadas.

Qué cuesta realmente no migrar

El costo de aplazar rara vez se mide, y por eso se subestima. Imagine un distribuidor de autopartes que opera una tienda B2B sobre una versión antigua. Su equipo de tecnología dedica cada trimestre un tercio de su capacidad a mantener compatibilidad con componentes que ya no se actualizan, a resolver incidentes de rendimiento y a evitar tocar módulos frágiles. Ese tercio no se invierte en mejorar la experiencia del comprador, en integrar el catálogo con un nuevo proveedor logístico ni en lanzar listas de precios por cliente. La migración no es un gasto adicional. Es la recuperación de capacidad que hoy se consume en sostener lo viejo.

Ocurre algo similar con el riesgo. El presupuesto de seguridad suele concentrarse en herramientas, mientras que la exposición real crece en silencio con cada versión sin parches. Un incidente de datos en una tienda en línea tiene costos directos, como investigación forense y notificaciones, y costos indirectos más difíciles de reparar, como la confianza de los clientes y la relación con las entidades de pago. Para quien dirige el negocio, el argumento más sólido para migrar es el de reducir una exposición que no puede transferirse con facilidad.

Hay que reconocer también el contraargumento. Migrar tiene riesgo propio. Una actualización mal planificada puede romper integraciones, extensiones o personalizaciones, y hacerlo en plena temporada alta es la peor combinación posible. Por eso la pregunta correcta no es si migrar, sino cuándo y con qué método, y la respuesta madura suele ser en una ventana planificada fuera de los picos de ventas, con pruebas en un entorno equivalente al de producción y un plan de reversa.

Cómo actualizar Adobe Commerce: guía breve y vigente

La documentación oficial de Adobe sobre requisitos previos de una actualización ordena el trabajo técnico con claridad. Antes de tocar nada, hay que revisar los requisitos de sistema de la versión de destino y actualizar el software de terceros y la configuración de PHP. Después hay que verificar que el motor de búsqueda sea compatible, porque MySQL dejó de ser compatible como motor de búsqueda de catálogo desde la versión 2.4, y confirmar con los proveedores de extensiones que cada una funciona con la versión de destino. La guía pide además convertir las tablas de la base de datos al formato de filas dinámico y al motor InnoDB, subir el límite de archivos abiertos, verificar que las tareas programadas se ejecuten con el propietario del sistema de archivos, ajustar los permisos y definir el directorio pub como raíz del sitio. Para resolver conflictos de dependencias, Adobe recomienda instalar el complemento de actualización de la raíz de Composer.

Con ese terreno preparado, la secuencia típica de un proyecto sensato es la siguiente.

1. Inventariar versión, extensiones, personalizaciones, integraciones y componentes de infraestructura, y definir la versión de destino según la política de soporte.
2. Replicar el entorno de producción en un ambiente de pruebas y ejecutar allí la actualización completa, incluida la migración de datos.
3. Corregir o reemplazar las extensiones y personalizaciones incompatibles, y repetir las pruebas funcionales y de rendimiento sobre los recorridos que más ingresos generan.
4. Planificar la ventana de producción con respaldo completo, modo de mantenimiento y plan de reversa definidos y ensayados.
5. Monitorear conversión, errores y velocidad durante las primeras semanas y documentar lo aprendido para la siguiente actualización.

Una vez al año conviene revisar el calendario de soporte y decidir con anticipación el próximo salto. Quien actualiza de manera regular, en pasos pequeños, convierte la migración en una rutina de bajo riesgo y no en un proyecto traumático cada cuatro años. Si desea profundizar en el momento correcto para hacerlo, el artículo cuándo actualizar mi software a una última versión disponible ofrece criterios complementarios, y la nota sobre migración y actualización con carga de productos en Adobe Commerce cubre la parte del catálogo.

Qué significa para la alta dirección

La decisión de migrar toca varias palancas del negocio, aunque no siempre se discuta en esos términos. En conversión y retención, una tienda rápida y estable reduce el abandono y protege la experiencia de los clientes recurrentes, que son quienes más valor aportan. En servicio, una plataforma moderna permite integrar el catálogo, el inventario y los pedidos con el resto de la operación, de modo que el cliente reciba información coherente. En eficiencia, la migración libera el tiempo del equipo técnico que hoy se dedica a mantener lo obsoleto.

La decisión tiene además una dimensión de gobierno que conviene institucionalizar. El calendario de soporte de la plataforma debería formar parte del plan anual de tecnología con la misma jerarquía que un vencimiento contractual, con un responsable y un presupuesto reservado. Cuando la actualización depende de que alguien recuerde hacerla, casi nunca se hace a tiempo. El comité de dirección debería pedir cada año tres datos simples, la versión en producción, la fecha en que su soporte termina y el plan para la siguiente actualización.

Por último, vale la pena preguntarse qué plataforma sostiene la estrategia a cinco años. Para algunos negocios, la migración es la oportunidad de revisar si la arquitectura actual sigue siendo la adecuada, por ejemplo si el crecimiento B2B exige capacidades como catálogos compartidos, cotizaciones y cuentas de empresa que la tienda actual no tiene. Para otros, es la ocasión de simplificar. En ambos casos conviene que la conversación empiece por el negocio y termine en la tecnología, y no al revés.

Cómo empezar el lunes

Un consultor con experiencia en estos proyectos le sugeriría comenzar por una pregunta que se puede responder en una hora, qué versión de la plataforma tiene hoy en producción y hasta qué fecha recibirá parches. Con ese dato en mano, pida a su equipo técnico un inventario honesto de extensiones y personalizaciones, señalando cuáles ya no tienen mantenimiento del proveedor. Es frecuente descubrir que el verdadero cuello de botella no es la plataforma sino tres o cuatro módulos críticos que nadie quiere tocar.

Después, convierta la migración en una decisión financiera. Pida una estimación del costo de migrar ahora, del costo de migrar dentro de un año y de la exposición que se acumula mientras tanto, y compárelos en una sola hoja. Casi siempre el resultado ayuda a ordenar prioridades. Finalmente, elija la ventana: una fecha fuera de los picos de venta, con tiempo suficiente para pruebas y con un plan de reversa. Las empresas que hacen este ejercicio con antelación llegan a la temporada alta con una plataforma estable en lugar de con una prohibición de tocar el sitio.

Cómo le ayuda ICX

ICX Consulting, firma de consultoría en experiencia del cliente y estrategia comercial con sede en Miami, acompaña a empresas de Estados Unidos y Latinoamérica para que sus decisiones de plataforma respondan al negocio. Evaluamos el estado de su tienda sobre Adobe Commerce, construimos junto con su equipo la hoja de ruta de la migración y revisamos el impacto en conversión, experiencia de compra y operación, desde nuestra práctica de comercio electrónico B2C y de comercio electrónico B2B. Si le interesa también la dimensión de riesgo, nuestro equipo de seguridad en plataformas digitales revisa la exposición de la tienda actual y el artículo sobre ciberseguridad esencial para su tienda en Adobe Commerce amplía el tema. ¿Quiere saber cuánto le cuesta hoy esperar? Solicite un diagnóstico con un consultor de ICX.

Para ordenar el plan con su equipo, el Kit de Transformación Digital de ICX ofrece plantillas para priorizar iniciativas, definir la hoja de ruta y presentar el caso de negocio a la dirección.

Otros artículos relacionados: Magento B2C y B2B, Personalización de contenidos en Magento Commerce, 6 integraciones clave en su eCommerce, Uso de la administración de usuarios en Magento Commerce y la Guía para crear y usar bloques en Adobe Commerce. Para el detalle de cada versión, consulte las notas de la versión 2.4.2.

Preguntas frecuentes

¿Cuándo debe actualizarse Adobe Commerce a una nueva versión?

Lo recomendable es planificar la actualización dentro de la ventana de soporte de la versión que se usa y antes de que termine, evitando los picos de venta. Adobe mantiene un calendario público de fechas de fin de soporte, y conviene incorporarlo al plan anual de tecnología, igual que se hace con los vencimientos contractuales.

¿Qué riesgos tiene seguir en una versión sin soporte?

Además de no recibir parches de seguridad, la tienda queda atada a versiones de PHP, motor de búsqueda y base de datos que los proveedores también dejan de mantener. Esto complica el cumplimiento de PCI, encarece las integraciones nuevas y, en entornos en la nube, puede derivar en que Adobe deje de mantener el entorno.

¿Se puede migrar sin detener las ventas?

Sí, aunque normalmente requiere una ventana corta de mantenimiento. El trabajo pesado se hace antes, en un entorno de pruebas equivalente al de producción, de modo que la ventana real se limita a aplicar el cambio con respaldo y plan de reversa. Programarla fuera de campañas y temporadas altas reduce el impacto comercial.

¿Migrar a una versión nueva obliga a rehacer las personalizaciones?

No siempre, pero conviene revisarlas una por una. Las personalizaciones que respetan la arquitectura de extensión suelen adaptarse con ajustes menores, mientras que las que modifican el núcleo o dependen de extensiones sin mantenimiento requieren rediseño. El inventario previo permite estimar ese esfuerzo con precisión antes de comprometer fechas.

La pregunta no es si su plataforma necesita actualizarse, sino cuánto va a costar hacerlo tarde. Si quiere llegar a su próxima temporada alta con una tienda segura, rápida y respaldada, converse con un consultor de ICX y pongamos fechas, costos y riesgos sobre la mesa antes de que el calendario de soporte lo haga por usted.