De Magento 1 a Shopware 6: la única migración en la que la elección de plataforma está abierta

Toda conversación sobre un cambio de plataforma empieza con la misma cuenta tácita: ¿cuánto de lo que ya pagamos viene con nosotros? Es la razón por la que la mayoría de las tiendas en Magento 2 siguen en Magento aunque estén frustradas con él. El tema funciona. Las extensiones funcionan. Las integraciones tardaron tres años en quedar bien. Moverse significa pagar por todo ello otra vez.

Desde Magento 1, esa cuenta no existe.

Magento 2 es una aplicación aparte que comparte nombre con Magento 1: distinto código, distinta arquitectura de módulos, distinto sistema de temas, distinto esquema de base de datos. La propia herramienta de Adobe lo admite al llamarse Data Migration Tool en lugar de comando de actualización. Así que su tema no viene con usted a Magento 2. Sus extensiones no. Sus módulos a medida no.

Lo que significa que, para exactamente un grupo de comerciantes —los que siguen en Magento 1—, la decisión de plataforma está genuinamente abierta. Va a reconstruir elija lo que elija. La única pregunta es sobre qué reconstruye.

Dónde le deja Magento 1

Brevemente, porque lo hemos escrito en detalle y probablemente ya lo ha oído: Magento 1 llegó al fin de soporte el 30 de junio de 2020. Desde entonces no se ha publicado ningún parche de seguridad oficial. 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 las llevan.

El argumento que mueve de verdad una decisión suele ser el cumplimiento normativo y no el miedo. PCI DSS exige los parches críticos dentro de una ventana definida, y cuando no se publica ningún parche el requisito no es simplemente incumplido: no puede satisfacerse en principio.

Hay un camino intermedio honesto. OpenMage LTS ejecuta Magento 1 sobre PHP 8 y porta correcciones de seguridad al código que ya tiene. Como forma de comprar dos o tres años para planificar bien una migración, es defendible. Como respuesta permanente para un negocio cuyos requisitos siguen creciendo, agrava el problema.

Qué se conserva de verdad, hacia cualquiera de los dos destinos

Esta es la tabla que nadie le pone delante, y es la que debería guiar la decisión:

Las seis primeras filas son idénticas. Ese es el punto. La diferencia de coste entre estos dos proyectos no está en la migración: está en las dos filas de abajo, y en lo bien que encaja su catálogo en el modelo de producto de cada plataforma.

Qué cubre el perfil de Magento

Shopware publica un Migration Assistant gratuito, y un plugin de perfil de Magento aparte le añade soporte para Magento 1.9.x y 2.x. Hacen falta los dos; el perfil no funciona solo. El plugin sigue la propia línea de versiones de Shopware, así que compruebe la matriz de versiones contra la versión de Shopware a la que apunta antes de construir un plan sobre ella.

Lee directamente su base de datos de Magento y mueve las entidades estructuradas: productos, categorías, clientes, pedidos, archivos multimedia y los atributos que hay detrás. Es trabajo real que no tiene que escribir.

Lo que no toca es la misma lista que en cualquier paso de Magento a Shopware, y cubrimos la mecánica en detalle en de Magento a Shopware 6, en particular el modelo de variantes, que es donde se va el calendario en un catálogo grande. Magento modela los productos configurables como un padre más hijos simples; Shopware genera combinaciones de variantes a partir de grupos de propiedades. No tienen la misma forma, y convertir entre ellos es una serie de decisiones explícitas y no un mapeo.

Todo lo de ese artículo aplica aquí. El resto de este es lo que es distinto por venir concretamente de Magento 1.

El parque de extensiones es el argumento que nadie dice en voz alta

Magento 1 lleva seis años sin soporte. Mire con honestidad lo que hay en app/code/local y app/code/community y pregúntese, por cada uno, si el proveedor sigue existiendo, sigue vendiéndolo y ha publicado algo desde 2020.

Para la mayoría de las tiendas la respuesta es no en la mayor parte de la lista. Lo que significa:

• No está comparando «conservar mis extensiones» con «sustituir mis extensiones». Las está sustituyendo en cualquier caso.
• Varias de esas extensiones codifican reglas de negocio que nadie documentó, y la persona que las entendía ya no está. Esa arqueología es un coste fijo que cae por igual en los dos proyectos.
• Un puñado resultará estar haciendo algo que ya no necesita en absoluto, porque el negocio cambió y el módulo se quedó. Encontrar esas es la única parte realmente buena de este proyecto.

Ese último punto merece tomarse en serio. Los comerciantes reconstruyen con regularidad en una plataforma nueva con un tercio menos de piezas móviles de las que tenían, y la reducción viene de esta auditoría y no de nada que hiciera la plataforma.

Los problemas específicos de M1

La estructura de URLs y el sufijo .html. Magento 1 viene por defecto con un sufijo .html en las URLs de producto y categoría, y muchísimas tiendas nunca lo cambiaron. Cada una de ellas es una URL indexada que tiene que redirigir a algún sitio. Shopware no genera las URLs así, de modo que esto no es un ajuste que pueda reflejar: es un mapa explícito, producido antes del cambio, a partir de su sitemap, Search Console y los logs del servidor. Cualquier cosa de esa exportación sin destino es una decisión que todavía no ha tomado.

Las URLs de navegación por capas son la otra mitad del mismo problema. Magento 1 genera una superficie grande de URLs de categoría filtradas, algunas de las cuales han acumulado enlaces y posiciones a lo largo de una década. Decida de forma deliberada cuáles reciben destino y cuáles se consolidan, pero decida, en lugar de descubrir la respuesta en su analítica un mes después.

Las contraseñas de los clientes. Magento 1 y Shopware generan los hashes de contraseña de forma distinta y los hashes almacenados no son portables. Planifique un restablecimiento forzado con un correo que explique por qué, y prográmelo lejos de sus semanas punta. Es una tarea de comunicación más que de ingeniería, y tratarla como ingeniería es como sale mal.

El historial de pedidos como registros, no como objetos vivos. Sus pedidos migrados llegan como datos históricos. Los flujos de repetir pedido, el estado de las RMA, el estado de las suscripciones y cualquier cosa en la que haga clic su equipo de atención al cliente en un pedido vivo no se comportará como antes. Averigüe pronto cuáles de esas usa su equipo a diario, porque la respuesta determina cuántas herramientas necesita después de la migración.

Una década de deriva del catálogo. Las tiendas Magento 1 que llevan funcionando desde 2012 suelen arrastrar conjuntos de atributos que nadie puede explicar, atributos usados en nueve productos y tipos de producto elegidos por razones perdidas en la historia. El Migration Assistant lo llevará todo fielmente. Límpielo primero en Magento 1, o como mínimo decida qué no migrar: es mucho más barato antes del movimiento que después.

Cuándo Magento 2 sigue siendo la mejor respuesta

Trabajamos en las dos plataformas, y este no es un artículo que defienda Shopware.

Magento 2 encaja mejor si tiene un catálogo muy grande con estructuras de atributos complejas, requisitos B2B reales en torno a cuentas de empresa, precios por nivel y presupuestos, una integración con ERP construida durante años contra el modelo de datos de Magento, o un equipo y una relación con una agencia ya muy metidos en el ecosistema de Magento. También encaja mejor si está en Estados Unidos y quiere la bolsa más amplia posible de desarrolladores e integraciones de la que contratar.

Shopware encaja mejor si está en Europa o vende principalmente allí, si quiere un núcleo moderno y API-first con una buena historia de contenido y merchandising de forma nativa, o si sus requisitos son realmente más sencillos que la instalación de Magento que acumuló y preferiría no volver a cargar con ese peso.

La versión de este proyecto que sale mal es aquella en la que un comerciante elige una plataforma para escapar de la frustración en lugar de para encajar con un requisito. Desde Magento 1 la frustración es real y completamente justificada, pero la causa es ejecutar software sin soporte de hace seis años, y los dos destinos lo arreglan por igual.

Qué haríamos

Dedique una semana a la auditoría antes de dedicar un mes a la decisión. Tres cosas, en este orden:

1. Exporte cada URL indexada de su sitemap y de Search Console. El tamaño de ese archivo es el tamaño de su proyecto de SEO, y es el mismo número en las dos plataformas.
2. Liste cada extensión y módulo a medida, con un veredicto de vivo/muerto sobre el proveedor al lado de cada uno. Ese es el alcance honesto de la reconstrucción.
3. Mire sus cinco peores problemas de catálogo —el conjunto de atributos que nadie entiende, los configurables con hijos con precio a mano— y compruebe cómo se mapea cada uno en los dos modelos de producto. Si una plataforma hace desaparecer tres de los cinco, esa es una señal real.

Después elija. Vaya como vaya, la construcción en sí es trabajo de desarrollo en Shopware 6 o de desarrollo en Magento 2, y la herramienta de migración es un acelerador útil al principio, no el proyecto en sí.

Si va en la otra dirección, o compara con quedarse donde está, también hemos escrito sobre de Shopware a Magento y sobre por qué algunas tiendas deberían quedarse en Magento.

Emyrix trabaja en Magento y en Shopware, y dirá sin rodeos cuándo un cambio de plataforma no es la respuesta. Si está en Magento 1 y quiere que la auditoría de arriba se convierta en una comparación con alcance, escríbanos.

La cobertura del Migration Assistant y la compatibilidad del perfil cambian entre versiones. Verifique las dos contra la documentación actual de Shopware antes de definir el alcance, y consulte la política de ciclo de vida de Adobe para las fechas de soporte de Magento.