OpenMage LTS: Magento 1 sobre PHP 8, instalado con Composer

Si ejecuta Magento 1, llevan seis años diciéndole que tiene dos opciones: migrar a Magento 2, o aceptar que está ejecutando software sin parchear sobre una versión de PHP que dejó de recibir correcciones de seguridad hace tiempo.

Hay una tercera opción, no es un apaño, y a un número sorprendente de comerciantes nunca se la han explicado como es debido.

OpenMage LTS es un fork de Magento 1 Open Source mantenido por la comunidad. Corre sobre PHP actual, se instala con Composer y ha seguido recibiendo parches de seguridad cada año desde que Adobe se desentendió. En el momento de escribir esto, el proyecto ha publicado 94 versiones, la última en mayo de 2026, y tenía commits del último día.

Eso no lo convierte en la respuesta correcta para todos. Sí convierte «migrar o pudrirse» en una falsa dicotomía.

Qué es en realidad

OpenMage LTS es el código de Magento 1 Open Source, forkeado y mantenido por la comunidad bajo la misma licencia OSL-3.0, distribuido como un paquete de Composer:

composer require openmage/magento-lts

Las propiedades importantes, todas ellas lo contrario de un Magento 1.9 estándar:

La fila de PHP es la que más importa, y conviene ser preciso sobre por qué. El problema de un Magento 1 estándar nunca fue solo que Magento dejara de parchearlo: era que le ataba a una rama de PHP que también dejó de parchearse. Acababa con dos capas de software sin soporte apiladas una sobre otra. OpenMage sobre PHP 8.4 reduce eso a una, y la capa que queda se mantiene activamente.

El cambio a Composer es menos drástico pero cambia el día a día. Parchear un Magento 1 estándar significaba descargar archivos .patch y aplicarlos a mano, que es exactamente el flujo que hace que los parches se salten. Una instalación gestionada por Composer convierte actualizar en un cambio de dependencia, y esa diferencia es la mayor parte de por qué las tiendas se quedan atrás.

Lo que no arregla

Aquí es donde el consejo honesto se separa del entusiasmo, y es la parte que normalmente se omite.

Sus proveedores de extensiones siguen sin estar. OpenMage mantiene el núcleo. No mantiene la extensión comercial que compró en 2016 a una empresa que ya no existe. Las extensiones escritas para Magento 1.9 generalmente funcionan, pero cualquier cosa que haga algo ingenioso con las entrañas de PHP puede necesitar arreglos para PHP 8, y no hay nadie a quien llamar. En la práctica, la mayoría de las tiendas encuentran que un puñado de módulos necesita atención; de vez en cuando, uno necesita sustituirse por completo.

No llegan funciones de comercio nuevas. Es un proyecto de preservación, no una hoja de ruta de producto. El admin no se modernizará, el frontend no se volverá más rápido por sí solo, y las capacidades headless y componibles por las que preguntan los comerciantes en 2026 no van a llegar. Si sus requisitos comerciales siguen creciendo, está eligiendo una plataforma que se ha detenido.

No hay proveedor ni SLA. Los mantenedores son voluntarios que hacen un trabajo realmente bueno sin ninguna obligación hacia usted. El proyecto está sano hoy —commits activos, una cadencia real de versiones, cientos de forks de contribuidores—, pero «sano hoy» es una garantía distinta de un contrato. Es un riesgo legítimo que sopesar, no una razón para descartarlo.

El hosting y la infraestructura siguen siendo su problema. Nada en el fork cambia el hecho de que está ejecutando una arquitectura de aplicación de hace una década, con las características de rendimiento que eso implica.

La cuestión del cumplimiento normativo, con honestidad

El argumento de PCI DSS es el que suele forzar la decisión, y merece más cuidado del que normalmente recibe.

El caso contra un Magento 1 estándar es hermético: PCI DSS exige que los parches de seguridad críticos se apliquen dentro de una ventana definida, y cuando una plataforma no recibe ningún parche, ese requisito es imposible de satisfacer en principio. No hay argumento que hacer.

OpenMage cambia eso de verdad. Los parches existen, se publican, y puede demostrar un proceso para aplicarlos. La imposibilidad desaparece.

Lo que no hace es zanjar la cuestión por usted. Que un QSA acepte un fork mantenido por la comunidad como cumplimiento de la intención del requisito es una decisión de criterio, y es una conversación que tener antes de su evaluación, no durante ella. Algunos evaluadores están completamente cómodos con ello. Otros querrán ver su proceso de parcheo documentado de una forma que de otro modo no se habría molestado en hacer. Vaya habiendo preguntado.

Pasar a él no es un cambio de plataforma

Esta es la parte que cambia la economía, y la razón por la que esta opción merece consideración y no una nota al pie.

Como OpenMage es un fork del código que ya está ejecutando, las cosas que hacen cara una migración de Magento 1 a Magento 2 en gran medida no aplican. El esquema de base de datos es el que tiene. La estructura del tema es la que tiene. La arquitectura de módulos, las plantillas, el layout XML, el admin: todo igual. No hay migración de datos, porque no hay una base de datos nueva a la que migrar.

Lo que hace de verdad:

1. Llegue primero al último nivel de parche de Magento 1.9, para partir de un estado conocido y no de uno arbitrario.
2. Pase el código a un OpenMage gestionado por Composer, que es el cambio estructural y el que hay que ensayar en staging.
3. Suba PHP de forma deliberada: aquí es donde aparece el trabajo real, en extensiones y código a medida escritos con los modismos de PHP 7.
4. Audite cada módulo de terceros para compatibilidad con PHP 8. Dé por hecho que es la partida más grande, exactamente como lo sería en cualquier actualización.
5. Pruebe la regresión del checkout con más dureza, después el catálogo y el admin, con datos similares a los de producción.

Defínalo como una actualización con una pasada de compatibilidad seria. Comparado con una reconstrucción en Magento 2, es una fracción del coste, y para una tienda cuya funcionalidad está realmente asentada esa proporción es todo el argumento.

Quién debería hacer esto de verdad

Buen encaje: una tienda rentable y estable con un conjunto de funciones asentado, una lista de extensiones manejable y ningún apetito por un cambio de plataforma de seis cifras este año. También cualquiera que sí esté planeando pasar a Magento 2 pero necesite dos o tres años de operación con soporte para planificarlo y financiarlo bien: es una posición de espera mucho mejor que quedarse en 1.9 y confiar en la suerte.

Mal encaje: un negocio cuyos requisitos comerciales siguen expandiéndose, cualquiera que necesite integraciones modernas o entrega headless, y cualquier equipo sin la capacidad de ingeniería para hacerse cargo de una auditoría de extensiones sin un proveedor al que escalar. Si va a acabar en Magento 2 en dieciocho meses de todos modos, la doble migración es difícil de justificar.

La trampa que hay que evitar es tratarlo como una decisión que nunca hay que revisar. El modo de fallo no es técnico: es pasar a OpenMage, sentir alivio y encontrarse en 2032 habiendo tenido la misma conversación dos veces.

Qué haríamos

Si hoy está en un Magento 1.9 estándar, pasar a OpenMage LTS es casi seguro mejor que lo que está haciendo ahora, decida lo que decida al final sobre Magento 2. Gana una rama de PHP con soporte, un proceso de parcheo real y dependencias gestionadas por Composer, por bastante menos que un cambio de plataforma.

Trátelo como una posición deliberada de dos a tres años y no como una respuesta permanente. Escriba qué dispararía el paso a Magento 2 —una función que no puede construir, una conversación de cumplimiento que sale mal, una extensión que por fin se rompe— para que la decisión tenga un detonante en lugar de esperar a otra emergencia.

Y si sus requisitos han dejado de crecer de verdad y la tienda simplemente necesita seguir vendiendo con fiabilidad, ese es un sitio legítimo en el que aterrizar. No todos los negocios necesitan un cambio de plataforma; algunos solo necesitan que lo que tienen sea mantenible. Nuestra prueba de encaje para Magento es la versión honesta de esa conversación.

Emyrix trabaja en Magento en todas sus versiones, incluidas las tiendas que se quedan donde están. Si está sopesando OpenMage frente a una migración a Magento 2 y quiere los números de las dos opciones en lugar de una recomendación disfrazada, escríbanos, o vea cómo llevamos el soporte continuo de Magento.

Los detalles de versiones, licencia y compatibilidad con PHP de OpenMage LTS están tomados de los metadatos del proyecto en Packagist y GitHub a agosto de 2026. Verifique los requisitos actuales directamente en el proyecto antes de planificar sobre ellos.