De Magento 1 a Magento 2: una migración, no una actualización

Hay una conversación concreta que ocurre cuando un comerciante en Magento 1 pide un presupuesto de actualización y oye una cifra pensada para una reconstrucción. La cifra suena mal porque la palabra «actualización» está mal.

Magento 1 y Magento 2 no son dos versiones de la misma aplicación. Comparten un nombre, un linaje de proveedor y un conjunto amplio de conceptos de comercio. No comparten un código, una arquitectura de módulos, un sistema de temas, un stack de frontend ni un esquema de base de datos. La propia herramienta de Adobe es honesta al respecto: lo que se ejecuta se llama Data Migration Tool, no comando de actualización.

Así que el planteamiento útil es el que aplicaría a cualquier cambio de plataforma. Está construyendo una tienda nueva y llevándose sus datos. Todo lo que sigue viene de aceptar eso.

Dónde está Magento 1 en realidad

Magento 1 llegó al fin de soporte el 30 de junio de 2020. Desde esa fecha, Adobe no ha publicado ningún parche de seguridad para él. No es una fecha límite que se acerca; son seis años por el retrovisor.

De ahí se siguen dos cosas, y solo una es la que preocupa a la gente.

La evidente es la exposición a vulnerabilidades. Magento se escanea intensamente, las campañas de skimmers de tarjetas contra Magento 1 llevan años activas, y la población de tiendas sin parchear es bien conocida por quienes llevan esas campañas. Ser pequeño no es cobertura: el escaneo automatizado no se preocupa de quién es usted.

La menos evidente es el cumplimiento normativo, y suele ser el argumento que mueve de verdad a una dirección. PCI DSS exige que los parches de seguridad críticos se apliquen dentro de una ventana definida. Cuando no se publica ningún parche, ese requisito no es simplemente incumplido: es imposible de satisfacer en principio. «Estamos en una plataforma sin soporte» no es una respuesta que sobreviva a la pregunta de un QSA, y si tiene un seguro cibernético conviene leer cómo trata su póliza el software sin soporte antes de necesitar apoyarse en ella.

El contrapunto honesto: existen forks comunitarios. OpenMage LTS ejecuta Magento 1 sobre PHP 8 y se instala con Composer, portando correcciones de seguridad al código que ya tiene, y hay servicios comerciales que ofrecen algo parecido. Son reales, se mantienen activamente y son considerablemente más baratos que una reconstrucción. Pero está cambiando una relación con un proveedor por un proyecto de voluntarios, su ecosistema de extensiones está congelado y no llegan funciones de comercio nuevas. Como forma de comprar dos o tres años de margen para una migración planificada, es realmente defendible. Como estrategia permanente para un negocio cuyos requisitos siguen creciendo, está agravando el problema que ya tiene.

Qué cubre la Data Migration Tool

La Data Migration Tool de Adobe se ocupa de las entidades estructuradas, y lo hace bien:

Esa columna izquierda es realmente útil y es la parte en la que la gente se fija, porque es la parte que tiene una herramienta asociada. La columna derecha es donde vive el proyecto.

La herramienta funciona en tres modos —settings, data y delta—, y el modo delta está diseñado para capturar los cambios que se acumulan en la tienda Magento 1 en vivo mientras construye Magento 2 a su lado. Esa capacidad incremental es lo que hace posible un cambio con poco tiempo de inactividad, y es la razón principal para usar la herramienta oficial en lugar de escribir su propio extractor.

Donde se complica es en el mapeo de atributos. Magento 1 y Magento 2 modelan algunas cosas de forma distinta, y cualquier atributo que añadiera a lo largo de una década de ventas necesita una decisión explícita sobre dónde aterriza. En un catálogo grande y antiguo esta es la parte que consume el calendario, y no es un trabajo que se reparta bien entre varios desarrolladores.

Qué está reconstruyendo en realidad

Esta es la parte que determina su presupuesto.

Su tema. Los temas de Magento 1 no se portan. El frontend de Magento 2 es un sistema completamente distinto, y en 2026 la pregunta viva ni siquiera es Luma frente a un tema de Magento 1: es si construir sobre Hyvä en su lugar, que para una tienda que empieza de cero suele ser la mejor respuesta. En cualquier caso, esto es un proyecto de diseño y frontend, no una conversión.

Sus extensiones. Cada extensión de Magento 1 tiene que sustituirse por un equivalente de Magento 2, volver a comprarse o reconstruirse. Algunos proveedores ofrecen rutas de migración para sus propios productos. Muchas de las extensiones de una tienda Magento 1 de diez años ya no tienen ningún proveedor que las mantenga, y cada una de esas es una decisión: encontrar un sustituto, construir la funcionalidad o eliminarla. Haga ese inventario pronto, porque es la fuente más habitual de sorpresas de alcance.

Sus módulos a medida. La arquitectura de módulos de Magento 2 —inyección de dependencias, plugins, service contracts— es lo bastante distinta como para que el código a medida se reescriba en lugar de portarse. La buena noticia es que es una oportunidad para deshacerse de las soluciones alternativas acumuladas que solo existían para compensar las limitaciones de Magento 1. La mala es que alguien tiene que decidir, módulo a módulo, cuál era la regla de negocio en realidad.

Sus integraciones. Las conexiones con ERP, PIM, TPV, impuestos, envíos y pagos se vuelven a conectar contra APIs distintas. Cualquier cosa construida contra la capa SOAP/REST de Magento 1 se reconstruye contra los endpoints REST o GraphQL de Magento 2.

El trabajo de SEO decide si tiene éxito

Esta es la parte que convierte una migración técnicamente limpia en un fracaso comercial, y se subestima de forma sistemática.

Magento 1 y Magento 2 no generan las URLs de la misma forma. Las rutas de categoría, las claves de URL de producto, el manejo de sufijos y los parámetros de paginación difieren, y salvo que intervenga deliberadamente cambiará una fracción grande de sus URLs indexadas el día del cambio. Google se lo toma exactamente tan mal como suena.

El trabajo, en orden:

1. Rastree y exporte cada URL en vivo antes de construir nada, junto con su tráfico y sus ingresos. Ese es su mapa y su lista de prioridades.
2. Mapee cada una a su destino en Magento 2. No un patrón: un mapeo real, verificado para los cientos de URLs con más tráfico.
3. Implemente redirecciones 301 sin cadenas. Un salto, de la URL antigua a la URL nueva final. Las cadenas diluyen la señal y son trivialmente evitables si el mapa se construye bien.
4. Conserve los metadatos y los datos estructurados. Títulos, descripciones, etiquetas canonical y el schema de producto deberían sobrevivir al movimiento intactos.
5. Tome la línea base de posiciones y tráfico un mes antes del cambio, para que cuando algo se mueva después pueda distinguir un problema de migración de la estacionalidad.

Hemos escrito el mismo aviso sobre los cambios de plataforma a Shopware, porque no es un modo de fallo específico de Magento. Es lo que pasa siempre que una estructura de URLs cambia sin un plan.

Una secuencia realista

El patrón que funciona, y la razón por la que la Data Migration Tool tiene un modo delta:

• Magento 1 sigue en vivo y vendiendo durante toda la construcción. No está congelando el negocio seis meses.
• Magento 2 se construye en paralelo —tema, extensiones, módulos a medida, integraciones— contra una migración de datos inicial.
• Las ejecuciones delta mantienen la tienda nueva al día con los pedidos y clientes que se acumulan en la antigua.
• El cambio es una ventana corta: un delta final, un cambio de DNS o de balanceador, las redirecciones en vivo y un periodo de monitorización en el que alguien está mirando de verdad.
• La tienda Magento 1 se archiva, no se borra, por el historial de pedidos y cualquier obligación contable.

El cambio es la parte menos interesante si los meses anteriores se hicieron bien, y una catástrofe si no.

Qué haríamos

Si hoy está en Magento 1, la decisión no es si moverse, sino si ha aceptado lo que es moverse. Las tiendas que lo pasan mal son las que definieron una migración de datos y descubrieron una reconstrucción en el tercer mes.

Empiece por el inventario de extensiones y la exportación de URLs. Esos dos artefactos le dicen más sobre coste y riesgo que cualquier cantidad de comparación de plataformas, y son baratos de producir. Si el total sale mayor de lo que el negocio puede absorber este año, un fork de Magento 1 con soporte es una forma legítima de comprar tiempo, siempre que ese tiempo lo dedique a planificar la migración y no a olvidarse de ella otra vez.

Y si la conclusión honesta es que Magento es más plataforma de la que necesita ahora, ese también es un resultado válido, y merece leer nuestra prueba de encaje antes de comprometerse. La peor versión de este proyecto es un cambio de plataforma precipitado a una plataforma que nadie eligió deliberadamente.

Emyrix lleva migraciones de Magento 1 a Magento 2 de principio a fin: inventario de extensiones, mapeo de datos, desarrollo en Magento 2 y el trabajo de URLs que protege su tráfico. Si sigue en Magento 1 y quiere la cifra real y no una esperanzada, escríbanos.

Las fechas de fin de soporte de Magento 1 y las capacidades de la Data Migration Tool proceden de la documentación de Adobe, que es la fuente autorizada y conviene verificar directamente para su edición.