Magento 1 dejó de recibir soporte y parches de seguridad de Adobe el 30 de junio de 2020, así que una tienda que sigue ahí lleva más de seis años sin correcciones oficiales. La salida no es una actualización sino una migración, a Magento 2 / Adobe Commerce o a otra plataforma, y mientras se planifica conviene blindar la tienda con fecha de vencimiento.
En DCisGlobal vemos el mismo patrón en tiendas de España y Latinoamérica: el catálogo vende, nadie quiere tocar nada y cada mes el problema crece. A eso se suma el servidor: la versión oficial de Magento 1 llegó, como mucho, a PHP 7.2, y PHP 7.2 dejó de recibir parches el 30/11/2020.
Esta guía explica el riesgo real, por qué pasar a Magento 2 es un proyecto y no un clic, y cómo elegir camino.
Qué significa que Magento 1 esté sin soporte
Significa que Adobe no publica más correcciones. Las fallas que se descubran desde entonces quedan abiertas en el software oficial.
No quiere decir que la tienda deje de funcionar mañana, sino que acumula fallas conocidas sin arreglo y que ya no hay un fabricante que responda por ella.
Qué riesgos corre una tienda en Magento 1
Pagos y tarjetas
Es el riesgo más caro. Una tienda que procesa tarjetas tiene que cumplir PCI DSS, el estándar de seguridad de la industria de pagos, y operar con software sin parches lo complica.
Ya en 2020, Mastercard advirtió que los comercios que siguieran en Magento 1 después del 30 de junio de ese año corrían más riesgo de sufrir una filtración de datos y podían quedar fuera de PCI DSS. En la práctica, eso se traduce en preguntas incómodas del procesador de pagos, del banco o de la aseguradora.
Además, los módulos de pago dependen de que el proveedor los mantenga. Cuando la pasarela cambia su API, una tienda en Magento 1 queda esperando un parche que quizá nunca llegue.
Integraciones
ERP, facturación electrónica, logística, marketplaces, email marketing: cada conexión es un módulo escrito para una plataforma que ya no evoluciona.
El costo no suele aparecer como un incidente sino como fricción: una integración que se cae y nadie sabe arreglar, un proveedor nuevo sin conector para Magento 1, un cambio fiscal que obliga a parchear a mano.
Seguridad y PHP viejo
PHP es el lenguaje en el que está escrito Magento. Como la versión oficial de Magento 1 se quedó en PHP 7.2, el servidor entero queda atado a versiones sin soporte, y con él todo lo que corre ahí.
El 21/10/2026, PHP corrigió dos fallas críticas conocidas como PHP2Shell. Las versiones 8.1 o anteriores no reciben esa corrección oficial, así que un servidor con Magento 1 queda fuera del arreglo.
Una tienda expuesta puede filtrar datos de clientes, sufrir caídas en plena campaña o perder una confianza que tardó años en construir.
Por qué pasar de Magento 1 a 2 no es una actualización
Magento 2 comparte el nombre, pero es otra aplicación: otra arquitectura, otra estructura de base de datos y otra forma de construir módulos y temas. Por eso hablamos de migración.
| Componente | Qué pasa al migrar | Impacto para el negocio |
|---|---|---|
| Datos: productos, clientes, pedidos, configuración | Adobe ofrece una herramienta oficial que los traslada por etapas | Se conserva el historial, pero hay que validarlo |
| Imágenes, diseño, usuarios del panel y permisos | La documentación de Adobe los indica como migración manual | Horas de trabajo y pruebas |
| Tema (el diseño de la tienda) | Se rehace | Oportunidad de mejorar la experiencia móvil |
| Extensiones | El código no se traslada: se reemplaza por su versión para Magento 2, si existe, o se reescribe | La partida más variable del presupuesto |
| Personalizaciones propias | Se reescriben | Momento de revisar cuáles siguen haciendo falta |
La lectura de negocio es simple: el presupuesto no lo fija el tamaño del catálogo sino la cantidad de extensiones y personalizaciones. Una tienda con diez módulos y lógica propia no se parece en nada a una casi estándar.
Cómo está hoy Magento 2.4
Si el destino es Magento 2, la versión importa. Adobe da tres años de soporte estándar desde el lanzamiento de cada versión, y algunas tienen un período extendido.
| Versión | Lanzamiento | Fin del soporte regular | PHP compatible |
|---|---|---|---|
| 2.4.9 | 12/5/2026 | 31/5/2029 | 8.5 |
| 2.4.8 | 8/4/2025 | 31/5/2028 | 8.3 y 8.4 |
| 2.4.7 | 9/4/2024 | 31/5/2027 (extendido hasta 31/5/2028) | 8.2 y 8.3 |
| 2.4.6 | 14/3/2023 | Terminó el 11/8/2026 (extendido hasta 31/8/2027) | 8.1 y 8.2 |
Nuestro criterio: migrar hoy a algo anterior a 2.4.8 es comprar una segunda migración a corto plazo. La 2.4.6 admite PHP 8.1, que ya no recibe parches, y la 2.4.7 llega como máximo a PHP 8.3, con soporte hasta el 31/12/2027.
Para quien use Adobe Commerce en la nube hay otro reloj: Adobe anunció que desde el 1/6/2027 dejará de mantener entornos que corran versiones sin soporte.
Los tres caminos posibles
1. Migrar a Magento 2 / Adobe Commerce
Tiene sentido con catálogos grandes o complejos, varias tiendas o idiomas, o procesos propios que una plataforma cerrada no permite. Magento Open Source no tiene costo de licencia; Adobe Commerce sí, a cambio de soporte del fabricante.
Exige un equipo capaz de mantenerla. Magento 2 es muy flexible, pero no es liviano.
2. Cambiar de plataforma
Si la tienda es relativamente estándar, otra plataforma puede salir más barata de operar. El trabajo es parecido (datos, diseño, integraciones), pero se gana simplicidad a cambio de flexibilidad.
El problema de las versiones viejas no es exclusivo de Magento: también lo explicamos para PrestaShop 1.6 sin soporte.
3. Blindar mientras se planifica
Es un puente, no un destino. Son medidas que reducen la exposición mientras se decide:
- Sacar los datos de tarjeta del servidor propio con una página de pago alojada por la pasarela.
- Restringir el acceso al panel de administración y revisar quién tiene usuario.
- Poner un firewall de aplicaciones web (WAF) delante de la tienda.
- Tener copias de seguridad probadas y monitoreo de cambios en archivos.
- Desinstalar las extensiones que ya no se usan.
Todo esto compra tiempo, pero no arregla el software. Recomendamos ponerle fecha: seis meses, no seis años.
Cómo decidir
Cuatro preguntas ordenan la decisión:
- ¿Cuánto cuesta una semana con la tienda caída? Eso marca cuánto invertir en hacerlo bien.
- ¿Cuántas extensiones y personalizaciones son críticas? Si son muchas y propias, Magento 2 o un desarrollo a medida suelen ganar.
- ¿Quién va a mantenerla? Una plataforma potente sin equipo técnico es otro sistema heredado en tres años.
- ¿Qué integraciones son obligatorias? ERP, facturación y logística definen qué plataforma encaja.
Para el contexto del servidor sirven nuestra guía para actualizar PHP en sistemas sin soporte y la nota sobre el fin de soporte de PHP 7.4.
Qué hacer ahora
- Confirmar la versión exacta de Magento y la de PHP del servidor.
- Inventariar extensiones, personalizaciones e integraciones, y marcar cuáles son críticas.
- Revisar cómo se procesan los pagos y si los datos de tarjeta pasan por el servidor propio.
- Aplicar el blindaje mínimo: acceso al panel, WAF y copias probadas.
- Elegir el destino con las cuatro preguntas anteriores y fijar una fecha de salida.
- Planificar la migración con una tienda de prueba y un corte fuera de los picos de venta.
Cómo lo resolvemos en DCisGlobal
Empezamos con un diagnóstico tecnológico de la tienda: versión, servidor, extensiones, integraciones y riesgo en pagos. Con eso proponemos el camino (migrar, cambiar de plataforma o blindar con fecha) y un plan por etapas que no corte las ventas.
Durante la transición podemos sumar soporte y mantenimiento para que la tienda actual siga en pie hasta el día del cambio.
Ver modernización de sistemas legacy · Consultar por WhatsApp
