Este texto le da una respuesta simple: si su tienda sigue recibiendo parches. Después mostramos qué implica para los costes, qué tumba de verdad a las tiendas Magento y cómo es un presupuesto honesto. Si al terminar comprueba la versión y decide el paso siguiente, el texto ha cumplido.
Las fechas de las que parte todo
La política de ciclo de vida de Adobe Commerce es simple: tres años de soporte estándar desde la fecha GA y, en parte de las versiones, soporte ampliado. Debajo, los plazos que hoy importan.
| Versión | Soporte estándar hasta | Soporte ampliado hasta |
|---|---|---|
| 2.4.5 | 12/08/2025 | 11/08/2026 |
| 2.4.6 | 11/08/2026 | 31/08/2027 |
| 2.4.7 | 31/05/2027 | 31/05/2028 |
| 2.4.8 | 31/05/2028 | sin fecha publicada aparte |
Estamos en septiembre de 2026, las conclusiones son cortas. En 2.4.5 han vencido el soporte estándar y el ampliado (11/08/2026): no hay parches nuevos y cada vulnerabilidad pública se queda con usted para siempre. En 2.4.6 el soporte estándar terminó el 11/08/2026, pero el ampliado llega al 31/08/2027: su ventana para una actualización planificada, no para aplazar el asunto.
En 2.4.7 o 2.4.8 puede decidir con calma, con tiempo antes del 31/05/2027 y del 31/05/2028 respectivamente.
Magento Open Source es asunto aparte: sin soporte comercial y sin plazos propios publicados. Depende de los parches de la comunidad y de que alguien de su lado los aplique. No traslade a ella las fechas de la tabla, el modelo es otro.
Cómo comprobar en cinco minutos dónde está
No necesita proveedor ni auditoría. Bastan tres gestos.
Primero: el panel de administración. El número de versión aparece en el pie al entrar, quince segundos.
Segundo: composer.json en el directorio de la aplicación, o mejor composer.lock. Allí se ve la versión del núcleo y los módulos de terceros. Sin acceso al servidor, pida una copia por correo.
Tercero: una pregunta a su proveedor que no admita generalidades. Qué versión exacta hay en producción, cuándo se aplicó el último parche de seguridad y si se probó antes en pruebas. Una respuesta sin versión ni fecha no es una respuesta.
Por qué mantener Magento cuesta más que WooCommerce o PrestaShop
No es cuestión de margen, sino de tres diferencias técnicas.
Infraestructura. Junto a la aplicación hay servicios que deben funcionar y vigilarse: buscador, capa de caché, colas de mensajes y programador cron. En WooCommerce una avería suele ser la caída de un proceso. En Magento son varios puntos que pueden pararse al margen de lo que ve el cliente.
Competencias. Magento es trabajo de programador, no de administrador de contenidos. Lo que en otras plataformas es un clic, aquí significa código, recalcular índices y un despliegue. La tarifa por hora es la misma, pero mucha menos gente puede trabajarla.
Tiempo hasta el cambio. En Magento no se toca producción: hay entorno de pruebas, procedimiento de despliegue y pruebas de regresión, porque un cambio en un módulo puede tumbar el carrito. La misma corrección pequeña consume más horas que en PrestaShop, la sorpresa más común en la primera factura. Lo desarrollamos en el artículo sobre cuánto cuesta mantener una tienda online.
Qué tumba de verdad a las tiendas Magento
Cinco cosas que en nuestra práctica generan más incidencias: síntoma, causa y orden de magnitud de recuperación. Es una observación de nuestro trabajo, no un tiempo de reparación comprometido: el tiempo de eliminar una avería no se puede prometer de antemano.
Colas y crons parados. El síntoma engaña: la tienda parece sana, las páginas abren y los pedidos entran, pero no llegan al ERP, los correos transaccionales no salen y el stock no se mueve. La causa suele ser un consumidor de cola muerto o el programador apagado tras reiniciar. Orden de magnitud: de decenas de minutos a unas horas, y lo más largo es el atasco.
Disco lleno y logs. Síntoma: errores de escritura, el panel deja de responder. La causa suele ser banal: depuración activada en el lanzamiento y nunca apagada. Orden de magnitud: de un cuarto de hora a una hora, si alguien mira el espacio libre a tiempo.
Reindexación y caché tras el despliegue. Síntoma: la tienda muestra precios viejos, categorías vacías o el diseño roto. La causa son índices sin recalcular o contenido estático sin reconstruir. Orden de magnitud: de decenas de minutos a unas horas, según el catálogo.
Módulos de terceros incompatibles con la versión. El síntoma aparece tras la actualización: un error 500 en un paso del carrito o en el panel. La causa es un módulo que no declara compatibilidad con el nuevo núcleo. Orden de magnitud: de unas horas a unos días, porque a menudo hay que esperar al fabricante.
Integraciones de pago. Síntoma: el pago empieza, no vuelve el estado y el pedido queda pendiente. La causa es un cambio del operador, un certificado caducado o una clave. Orden de magnitud: de decenas de minutos a unas horas, con parte fuera de nuestras manos. Lo que cuesta esa parada está en el artículo sobre el coste de la caída de una tienda online.
Qué debe incluir el mantenimiento mensual de una tienda Adobe Commerce
El mínimo exigible a cualquier proveedor, también a nosotros.
Parches de seguridad con un régimen fijado. Con nosotros las críticas entran en 72 horas y el resto en 14 días, siempre primero en pruebas. Sin esa última condición, parchear rápido es un riesgo, no un servicio.
Monitorización de lo que puede pararse. Comprobar la portada cada 60 segundos es necesario y aquí insuficiente. Hay que vigilar colas, crons y si los eventos salen al exterior, donde empiezan las averías silenciosas.
Copias de seguridad con prueba de restauración. Una copia que nadie ha restaurado es una suposición, no una protección. En el paquete básico copiamos cada 7 días y probamos la restauración cada trimestre.
Revisión de logs. Leerlos con regularidad es aburrido y es la única forma de ver el problema antes que el cliente.
Presupuesto: tres perfiles de tienda
Perfil uno: tienda en 2.4.7 o 2.4.8, pocas integraciones, catálogo de unos miles de referencias, pocos cambios. El paquete realista es Advanced por 440 EUR al mes con 20 horas: parches, cambios pequeños e incidencias.
Perfil dos: tienda en 2.4.6, antes de actualizar, con una docena de módulos de terceros e integración con ERP. Aquí las 20 horas se agotan el mes de la actualización. El paquete realista es Premium por 880 EUR al mes con 40 horas.
Perfil tres: tienda en 2.4.5, fuera de soporte, con módulos propios. Antes de hablar de cuota mensual hace falta un plan de salida: el mantenimiento mensual no resuelve la falta de parches.
Una advertencia honesta: una tienda Magento rara vez cabe en el paquete Basic por 220 EUR con 10 horas. Diez horas se van aquí en un despliegue con pruebas de regresión. Si alguien le ofrece Magento por 220 EUR, pregunte qué pasa al agotar el paquete. La hora dentro del paquete cuesta 22 EUR y fuera del paquete 35 EUR.
La supervisión de la disponibilidad se factura aparte: es otro servicio, distinto de la bolsa de horas. El nivel Estándar empieza en 210 EUR. Con Magento suele entrar el Ampliado por 550 EUR: no se vigila una dirección, sino colas, crons y procesos en segundo plano, y el diagnóstico de un evento crítico exige conocer la plataforma. La guardia continua 24/7 solo existe en nuestro nivel de SLA más alto. Lo desglosamos en el artículo sobre soporte técnico y SLA.
Actualizar o migrar a otra plataforma
Conviene plantearla con honestidad, sobre todo en una versión sin soporte. No vamos a convencerle de migrar: salir de Magento es caro, largo y en la mitad de los casos acaba con los mismos problemas en otro sitio. En su lugar, tres criterios.
Primero: calcule el mantenimiento a un año, la cuota por doce más las horas fuera del paquete y el alojamiento. Solo esa cifra, no la factura de un mes, se puede comparar.
Segundo: compruebe cuántas funciones de su tienda son específicas. Listas de precios B2B complejas, varios almacenes y una integración dura con el ERP significan que Magento hace el trabajo que paga. Un catálogo simple con pago significa pagar por posibilidades que no usa.
Tercero: pregunte si su equipo sabe usar esta plataforma. Magento exige a alguien que entienda la diferencia entre un índice y la caché. Sin esa persona, cada cambio se compra por horas, una parte real de la cuenta.
Si dos de tres criterios caen del lado de Magento, quédese y planifique la actualización. Si ninguno, migrar es una conversación razonable, pero es un proyecto aparte y no un anexo al contrato de mantenimiento.
Empiece por una revisión de la versión y del estado técnico. Comprobamos en qué versión está la tienda, cuándo recibió parches, si colas y crons funcionan, y entregamos una lista de tareas con estimación en horas. Escríbanos por /es/sla-help-desk y le diremos si basta con una bolsa de horas o hace falta supervisión de la disponibilidad.