¿Te preocupa que una actualización estropee tu tienda de Magento? Así es como actualizas las extensiones de Magento de forma segura

Hay otro mensaje de tu agencia indicando que hay actualizaciones de seguridad listas para tu tienda online de Magento. El mensaje anterior de ese mismo tenor también sigue ahí, de hace seis semanas. Nadie las programa porque la última vez el proceso de pago estuvo fuera de servicio medio día y, a posteriori, nadie pudo determinar exactamente a qué se debió.

Esa sensación está justificada y rara vez tiene que ver con la actualización en sí. Una actualización de Magento funciona como una factura. La pagas por todas las decisiones que se han tomado en tu tienda online durante los años anteriores: dónde se ha implementado la personalización, cómo se han incorporado las extensiones o si hay un espacio para probar algo antes de que se publique. Quien haya tomado bien esas decisiones, aplicará un parche en una mañana. Quien las haya descuidado, se enfrentará a todo un proyecto.

A continuación se detalla en qué consiste esa factura y qué puedes hacer al respecto antes de que esté lista la próxima actualización.

¿Por qué falla realmente una actualización de Magento?

Una actualización de Magento rara vez falla en Magento. Falla en lo que se ha construido a su alrededor. En la práctica, hay tres causas que se repiten constantemente.

La primera es una extensión que la nueva versión de Magento aún no admite. O bien el proveedor de la extensión va con retraso, o bien la extensión ya no recibe mantenimiento alguno. Ese único módulo acaba frenando toda tu instalación.

La segunda es una personalización escrita en el núcleo, en lugar de en un módulo propio. Al actualizar, se sustituye el núcleo y esa personalización desaparece. A veces con un mensaje de error, lo cual es molesto. A veces de forma silenciosa, lo que resulta aún más molesto, porque solo te das cuenta cuando llama un cliente.

El tercero es que dos módulos sobrescriben la misma parte del comportamiento. Mientras no cambie nada, funciona perfectamente. Tras una actualización, cambia el orden en el que se cargan.

Un ejemplo de un proyecto B2B: la tienda online tenía su propia lógica de stock integrada directamente en la gestión de pedidos. Con cada actualización, había que revisar y actualizar esa lógica de nuevo. La solución consistió en volver al estándar. La lógica propia se ha sustituido por el inventario de múltiples fuentes, la funcionalidad de stock que el propio Magento incluye, de modo que, a partir de ahora, esa parte se actualiza automáticamente con cada actualización.

¿Con qué frecuencia se publican actualizaciones de seguridad para Magento?

Con más frecuencia que hace unos años, y en 2026 el ritmo se ha acelerado. Adobe publicó en 2025 seis boletines de seguridad para Magento, con un intervalo medio de unas siete semanas entre ellos. En 2026 se publicaron el 10 de marzo, el 12 de mayo, el 14 de julio, el 11 de agosto, el 7 de septiembre y el 8 de septiembre. La segunda mitad de ese año se mantuvo, por tanto, a un ritmo de unas cuatro semanas, y en septiembre hubo dos en la misma semana.

Esos boletines proporcionan dos tipos de actualizaciones, y esa diferencia determina la facilidad con la que se pueden aplicar. Las grandes versiones de parches son acumulativas: incluyen todo lo que se ha corregido anteriormente. Además, aparecen correcciones independientes para una o varias vulnerabilidades, y estas, precisamente, no son acumulativas. Una corrección aislada de este tipo da por hecho que ya dispones de la última versión de parche de tu línea de lanzamiento. Por lo tanto, quien se haya saltado algunas actualizaciones no podrá instalarla sin más y deberá actualizar primero.

Además, tu propia tienda online tiene un segundo flujo de actualizaciones. Cada extensión sigue su propio ritmo de lanzamiento, y en una tienda Magento que se mantiene activamente hay pequeñas actualizaciones prácticamente cada semana y tareas de mantenimiento más importantes cada mes. En definitiva, las actualizaciones deben formar parte de tu planificación mensual. Cuanto mayor sea la acumulación de actualizaciones pendientes, más difícil resultará, además, determinar qué actualización ha provocado un fallo en caso de que se produzca.

¿Qué versión de Magento Open Source sigue recibiendo actualizaciones de seguridad?

Actualmente, solo las versiones 2.4.7, 2.4.8 y 2.4.9 siguen recibiendo actualizaciones de seguridad para Magento Open Source. Fechas de soporte de Adobe:

  • La versión 2.4.9, publicada el 12 de mayo de 2026, recibirá soporte hasta el 31 de mayo de 2029.
  • 2.4.8 estará disponible hasta el 31 de mayo de 2028
  • La versión 2.4.7 tendrá soporte hasta el 31 de mayo de 2027.
  • 2.4.6 dejó de recibir soporte el 11 de agosto de 2026
  • Las versiones 2.4.5 y anteriores llevan ya tiempo sin recibir actualizaciones.

En el ámbito del código abierto, una fecha de finalización de este tipo es más definitiva de lo que parece a primera vista. El soporte ampliado del que se habla en la documentación, que sigue proporcionando parches tras la fecha de finalización habitual, se aplica a la versión de pago. Para el código fuente abierto, no se publican esos parches ampliados. Por lo tanto, no hay un periodo de transición en el que puedas seguir trabajando tranquilamente durante un año más.

Cómo se traduce esto en la práctica quedó reflejado en el boletín de seguridad de septiembre de 2026. En él, las versiones de Magento Open Source 2.4.6 a 2.4.9, ambas inclusive, figuran en la lista de versiones afectadas, mientras que solo se ha publicado una versión Open Source corregida para las versiones 2.4.7, 2.4.8 y 2.4.9. Quien en ese momento utilizara la versión 2.4.6 figuraba, por tanto, en la lista de versiones vulnerables sin que hubiera un parche correspondiente. De ahí que la pregunta sobre qué versión utilizas sea la primera de toda esta historia, incluso antes de preguntarte qué extensiones tienes.

¿Por qué una actualización tarda tres horas en una tienda online y tres semanas en otra?

La diferencia casi nunca radica en el tamaño de la tienda online. Radica en la forma en que se ha implementado la personalización. Cuatro preguntas determinan la mayor parte de ese plazo de ejecución.

¿La personalización se encuentra en un módulo propio o en el núcleo? El código de un módulo propio sobrevive a una actualización. El código del núcleo debe volver a implementarse y probarse cada vez.

¿Las extensiones se instalan a través de Composer o se copian como carpetas? Con Composer sabes exactamente qué versión se ejecuta en cada lugar y puedes actualizar de forma específica. Las extensiones copiadas deben ser comparadas manualmente con la nueva versión.

¿Cuántas extensiones hay instaladas y se utilizan todas? Cada extensión es una dependencia que se comprueba en cada actualización. Un módulo que ya nadie utiliza, pero que sigue instalado, te hace perder tiempo con cada actualización.

¿Existe un entorno de aceptación similar al entorno de producción? Sin un entorno de este tipo, los cambios se ponen en marcha sin haber sido probados en la práctica, por mucho cuidado que se ponga en el resto del trabajo.

No hace falta ser desarrollador para hacerse una idea de esto. Solicita una lista de todas las extensiones activas con su número de versión y proveedor, la fecha de la última actualización del núcleo y un resumen de lo que se ha modificado directamente en el núcleo. Si no recibes esa lista en el plazo de un día, ahí tienes ya tu respuesta.

¿Cómo se prueba una actualización de Magento antes de que se publique?

Con un entorno de aceptación similar al de producción y con una prueba que recorre los flujos críticos antes de que la actualización pase a producción. Por «crítico» se entiende aquí: desde la página del producto hasta el proceso de pago, incluyendo el pago, el inicio de sesión y la búsqueda. Esa es precisamente la parte que, en una comprobación manual, se omite en primer lugar, porque resulta aburrida y requiere muchos clics.

En nuestra práctica, la configuración de un conjunto de pruebas automatizadas lleva entre una y dos semanas. A continuación, dicho conjunto recorre varias veces al día todos los flujos críticos y se genera un informe diario sobre lo que se ha probado y cómo ha ido.

Para una pequeña tienda online con poca personalización y dos métodos de pago, una suite de este tipo resulta excesiva. Una lista de comprobación fija de diez pasos manuales, más un entorno de aceptación, cubre la mayor parte de las necesidades, y su configuración no supone ningún coste. La suite empieza a amortizarse en cuanto crece el número de flujos, grupos de clientes y integraciones, ya que, en ese momento, las pruebas manuales se convierten precisamente en el eslabón más débil.

¿Qué haces si, tras una actualización, algo deja de funcionar?

La reversión debe ser una operación que se realice en cuestión de minutos. Hay tres factores que lo hacen posible: un solo cambio por implementación para que se sepa cuál fue, una implementación que se pueda revertir sin tiempo de inactividad y una copia de seguridad de la base de datos realizada justo antes de la actualización.

Esta primera opción es la más barata y la que más se suele pasar por alto. Quien ponga en producción de una sola vez cuatro actualizaciones de extensiones, un parche de seguridad y una personalización, en caso de fallo no sabrá dónde buscar el problema y tendrá que revertir todo, incluidas las cosas que sí funcionaban.

El momento del lanzamiento también es importante. Un parche que se pone en marcha un martes por la mañana cuenta con toda una jornada laboral de personal disponible para gestionarlo. El viernes por la tarde y la semana previa a tu periodo de mayor actividad son los dos momentos en los que una pequeña avería se convierte en una avería costosa.

¿Cuándo es mejor posponer una actualización de Magento?

A veces, posponer las cosas es lo más sensato que se puede hacer.

Si tu tienda online se sustituye en el plazo de un año, una actualización completa de la versión será una pérdida de dinero. Basta con un parche de seguridad específico, siempre que tu versión actual de Magento aún lo reciba.

Si la instalación está tan deteriorada que la actualización cuesta más que crear una tienda nueva desde cero, hay que tomar otra decisión. Una evaluación técnica del código da respuesta a esta cuestión antes de iniciar el proyecto, incluyendo una valoración de qué personalizaciones y qué extensiones suponen un obstáculo.

El aplazamiento deja de ser una opción en cuanto se utiliza una versión que ya no recibe parches de seguridad. El 19 de octubre de 2026, esto se aplicará a todas las tiendas online de Magento Open Source que utilicen la versión 2.4.6 o anterior, ya que para el código fuente de Open Source no existe un soporte ampliado que te dé un año más de margen.

Empieza por saber qué contiene

Las actualizaciones resultan más fáciles cuanto menos obstáculos hay. El primer paso es saber qué hay en tu instalación: qué extensiones, cuánto trabajo a medida, dónde se encuentra ese trabajo a medida y en qué versión de Magento estás trabajando. Con esa visión general, una actualización se convierte en una acción planificada cuya duración puedes estimar de antemano.

Si quieres tenerlo claro antes de aplicar el próximo parche, una revisión del código es el camino más directo para obtener una respuesta sincera.

¿Con qué frecuencia hay que actualizar Magento?

Los parches de seguridad deben instalarse tan pronto como estén disponibles, y eso ocurre con más frecuencia de lo que muchos propietarios de tiendas online creen. Adobe publicó seis boletines de seguridad para Magento en 2025 y, hasta septiembre de 2026, otros seis, con un ritmo que en la segunda mitad de 2026 se situó en aproximadamente cada cuatro semanas. Además, en una tienda Magento que se mantiene de forma activa, hay pequeñas actualizaciones de extensiones prácticamente cada semana y tareas de mantenimiento más importantes cada mes.

Solo 2.4.7, 2.4.8 y 2.4.9. La versión 2.4.9 se publicó el 12 de mayo de 2026 y recibirá soporte hasta el 31 de mayo de 2029; la 2.4.8, hasta el 31 de mayo de 2028, y la 2.4.7, hasta el 31 de mayo de 2027. El soporte para la versión 2.4.6 finalizó el 11 de agosto de 2026, y las versiones 2.4.5 y anteriores ya no reciben soporte desde hace tiempo.

En ese caso, las vulnerabilidades conocidas de tu instalación seguirán sin solucionarse, ya que no se publicará ninguna versión corregida para esa línea de versiones. En el boletín de seguridad de septiembre de 2026, Magento Open Source 2.4.6 sí figuraba en la lista de versiones afectadas, mientras que solo se publicó una corrección para las versiones 2.4.7 a 2.4.9, ambas incluidas. Actualizar a una versión compatible es, por tanto, la única solución real; un cortafuegos o la aplicación de parches virtuales por parte de tu proveedor de alojamiento solo te dará un respiro temporal.

A menudo sí, con implementaciones sin tiempo de inactividad, aunque esto no se aplica a todas las actualizaciones. Las actualizaciones que realizan una migración de la base de datos o requieren una reindexación completa necesitan un breve periodo de mantenimiento. Planifícalo fuera de tus horas punta e informa a tu servicio de atención al cliente de cuándo tendrá lugar.

Dado que una extensión se desarrolla para una versión específica de Magento, si cambia el núcleo, el punto de conexión que utiliza la extensión puede desaparecer o modificarse. Además, dos extensiones que sobrescriben el mismo comportamiento pueden causar problemas en cuanto cambia el orden de carga.

Eso depende de tu instalación y no del tamaño de tu tienda online. Los factores determinantes son el número de extensiones activas, la cantidad de personalización y si dicha personalización se encuentra en módulos propios o en el núcleo. Solo se puede hacer una estimación realista tras un inventario de las extensiones y las personalizaciones; quien mencione un plazo de ejecución de antemano sin ese inventario, está haciendo conjeturas.

No. Una actualización de una extensión que solo añada funciones que no utilizas puede esperar. Las actualizaciones de seguridad y las necesarias para la compatibilidad con tu versión de Magento no pueden esperar. Es mejor eliminar las extensiones que no utilizas que actualizarlas, ya que cada módulo instalado sigue contando a la hora de las próximas actualizaciones.

Un entorno de aceptación es una copia de tu tienda online en la que se prueban los cambios antes de que se implementen en el entorno en producción. Es necesario disponer de uno en cuanto haya más de una persona trabajando en la tienda o en cuanto haya integraciones con otros sistemas. Sin un entorno de aceptación, los cambios se implementan en producción sin haber sido probados previamente.

Una revisión de código cuesta con nosotros 2.500 euros, dependiendo del tamaño de la instalación, el número de extensiones y la cantidad de personalización. El resultado es un informe documentado con el estado del código, el nivel de seguridad y la compatibilidad con los estándares de Magento.

Solicita dos resúmenes. La primera es una lista de todas las modificaciones realizadas fuera de los módulos propios, es decir, directamente en el núcleo o en un tema copiado. La segunda es una lista de extensiones que no se han instalado a través de Composer. Esas dos listas juntas permiten predecir la mayor parte del tiempo de ejecución de tu próxima actualización.

Artículos relacionados

¿Los agentes de IA no te recomiendan productos? Así es como puedes dar visibilidad a tu tienda online de Magento
Lo que realmente implica encargar la creación de un configurador de productos dentro de una organización
Tres presupuestos, tres importes muy diferentes: cuánto cuesta una tienda online B2B de Magento
Qué significa el «agentic commerce» para tu tienda online Magento B2B
¿Has terminado con tu agencia actual? Así se lleva a cabo la transferencia de la gestión de tu Magento
AFAS Software en tres pantallas: tableta, ordenador de sobremesa y móvil. Artículo sobre la integración de Magento con AFAS.
¿Qué sistema tiene razón?: la cuestión detrás de la integración entre AFAS y Magento
La licencia es gratuita, pero la migración no: lo que Hyvä supone para tu tienda online de Magento
Camión con palés para el almacén de la tienda online B2B de Magento
Un precio diferente para cada cliente: lo que esto implica para tu tienda online Magento B2B
Migración de Shopify a Magento: cajas de mudanza a la vista, se ve a alguien trasladándolas
Migración de Shopify a Magento: de alquilar a ser propietario
Copias en unas pocas horas: crece el número de réplicas de tiendas online creadas con IA
Pasaporte Digital del Producto (DPP): ¿qué significa esto para tus datos de producto y tu PIM?
MageCraft: Magento + Hyvä por una cuota mensual fija
Un año después de la EAA: ninguna gran tienda online es totalmente accesible
¿Qué es iPaaS y cuándo lo necesitas?
Deja de limitarte a la supervisión del tiempo de actividad y empieza a realizar pruebas reales

CUÉNTANOS QUÉ TE PREOCUPA

Somos el departamento técnico que se preocupa por tu tiempo de actividad, tu rendimiento y tu próximo paso. No como contratistas. No como proveedores. Sino como personas que tienen tanto interés en tu éxito como tú mismo.

¿Nos cuentas qué pasa? Nosotros decimos lo que vemos.

Jesper van den Bogaard, fundador y propietario de Factor Blue , en una foto de retrato sentado en una silla.

La experiencia de Factor Blue