De Shopware 6 a Magento: la migración para la que nadie construyó una herramienta

Shopware distribuye un Migration Assistant oficial para entrar en Shopware. No existe nada comparable para salir de él hacia Magento, y ningún proveedor tiene un incentivo comercial para construirlo.

Ese único hecho da forma a todo el proyecto. Donde un paso de Magento a Shopware empieza con una herramienta que se ocupa de las entidades estructuradas, esta dirección empieza con una página en blanco y una API. No es más difícil en principio —la Admin API de Shopware está bien documentada y es completa—, pero la capa de extracción y mapeo es suya para escribirla, probarla y mantenerla.

Así que la primera pregunta es si el paso está justificado siquiera, porque la respuesta a menudo es no.

Cuándo está justificado de verdad

Cuatro casos en los que hemos visto que tiene sentido:

La complejidad del catálogo superó el modelo. La estructura EAV de Magento recibe críticas con frecuencia, y se las gana en rendimiento. También maneja catálogos realmente desordenados —miles de atributos, conjuntos de atributos que difieren muchísimo por tipo de producto, sobreescrituras de atributos por vista de tienda— de formas que son dolorosas de reproducir en otro sitio. Si se pelea cada semana con su modelo de producto, esta es una razón real.

Los requisitos B2B se pusieron serios. Cuentas de empresa, presupuestos negociables, listas de requisición, catálogos y listas de precios por empresa, cadenas de aprobación de órdenes de compra. Adobe Commerce lo incluye como un módulo soportado. Construir el equivalente es un producto por derecho propio.

Inventario multiorigen y cumplimiento complejo. El MSI de Magento maneja de forma nativa el stock multialmacén, la prioridad de fuentes y las reservas. Si ha construido esa lógica en middleware porque su plataforma no la modela, moverla a la plataforma es una simplificación legítima.

Ecosistema y contratación. En algunos mercados, sobre todo en Estados Unidos, la bolsa de agencias y desarrolladores de Magento es más profunda. Si su relación con un partner de Shopware terminó mal y no hay sustituto local, eso es un riesgo de negocio, no técnico, pero sigue siendo real.

Y cuándo no lo está: el rendimiento por sí solo es una mala razón. Magento no es más rápido que Shopware por defecto; es una plataforma que puede hacer rápida con trabajo deliberado. Cambiar de plataforma para arreglar la velocidad suele reproducir los mismos problemas en un stack nuevo, más una migración.

La extracción la construye usted

La Admin API de Shopware 6 es REST, está bien documentada y cubre lo que necesita. Cuente con escribir una capa de ETL más o menos así:

# Authenticate against the Admin API
curl -X POST https://your-shop.example/api/oauth/token \
  -H 'Content-Type: application/json' \
  -d '{"grant_type":"client_credentials","client_id":"...","client_secret":"..."}'

# Then page through entities — products, with their associations
curl -H "Authorization: Bearer $TOKEN" \
  'https://your-shop.example/api/search/product' \
  -H 'Content-Type: application/json' \
  -d '{"limit":100,"page":1,"associations":{"options":{},"properties":{},"prices":{},"media":{},"categories":{}}}'

Constrúyala como un pipeline repetible, no como un script de un solo uso. Lo ejecutará decenas de veces, y las ejecuciones que importan son aquellas en las que compara la salida con la ejecución anterior y explica cada diferencia.

En el lado de Magento, resista la tentación de escribir directamente en la base de datos. Use las rutas de importación que soporta la plataforma: los comandos de bin/magento, la importación CSV estándar para el catálogo y la API REST para el resto. Los inserts SQL directos en las tablas EAV son la forma en que las tiendas acaban con datos que los indexers no pueden ver.

Las decisiones de mapeo que importan

Las variantes pasan a ser configurables. Shopware genera variantes a partir de grupos de propiedades; Magento quiere un padre configurable más un producto simple real por combinación, cada uno con su propio SKU. Está creando registros de producto que antes no existían como registros. Decida pronto las reglas de generación de SKU, escríbalas y manténgalas estables entre ejecuciones; si no, cada ejecución de la migración produce SKU distintos y su mapa de redirecciones no vale nada.

Las propiedades pasan a ser atributos, y los conjuntos de atributos hay que diseñarlos. Las propiedades de Shopware son relativamente planas. Los conjuntos de atributos de Magento son una estructura que tiene que diseñar de forma deliberada. Hacerlo mal le deja con un conjunto de atributos gigante y 400 atributos casi todos vacíos en cada producto, lo que es lento, feo de administrar y difícil de deshacer después.

Los canales de venta pasan a ser vistas de tienda, de forma imperfecta. Los canales de venta de Shopware y la jerarquía de sitio web/tienda/vista de tienda de Magento se solapan sin coincidir. Las instalaciones multiidioma y multimoneda necesitan un mapeo explícito, y conviene dibujarlo antes de escribir ningún código.

Las contraseñas de los clientes no se transfieren. Distinto hashing. Planifique un restablecimiento forzado con un correo bien escrito, o un shim transparente de rehash al iniciar sesión si puede soportar los dos algoritmos durante una ventana de transición. Decídalo antes del lanzamiento, porque es lo primero con lo que se encuentra cada cliente que vuelve.

El historial de pedidos son datos de referencia. No intente que los pedidos históricos sean pedidos de Magento completamente funcionales, con repetición de pedido y devoluciones operativas. Impórtelos como registros para atención al cliente e informes, y sea explícito con el negocio sobre lo que esos registros pueden y no pueden hacer.

Secuencia

1. Audite los dos lados. Recuentos y estructura de entidades en Shopware; la versión y edición de Magento de destino. Elija ya su versión de Magento: si va a aterrizar en una línea actual, lea primero la decisión entre 2.4.8 y 2.4.9.
2. Diseñe el modelo de datos antes de escribir el extractor. Conjuntos de atributos, reglas de SKU, jerarquía de tiendas, árbol de categorías. Sobre papel, revisado por alguien que conozca el catálogo.
3. Construya el pipeline y ejecútelo cada semana. Hacia una instancia de Magento desechable. Compare cada ejecución.
4. Reconstruya la tienda en paralelo. No se transfiere ningún tema ni extensión.
5. Reintegre. Pagos, envíos, impuestos, ERP, PIM, búsqueda, marketing. Cada uno es su propia pieza probable.
6. Mapee las URLs y planifique las redirecciones desde el principio, no la semana antes del lanzamiento. La disciplina de SEO es idéntica en esta dirección e igual de decisiva.
7. Haga el cambio con una ejecución delta, una ventana congelada y un rollback ensayado.

Cuánto cuesta

Comparable a la otra dirección —piense en tres a seis meses para una tienda de complejidad media—, pero con el peso repartido de otra forma. Pasa menos tiempo aprendiendo una herramienta de migración y más construyendo y validando el extractor. Si su catálogo está limpio y sus integraciones son pocas, puede ser menos. Si alguna de las dos cosas está desordenada, el trabajo de datos domina y ninguna cantidad de desarrolladores lo comprime.

Presupueste una persona dedicada a los datos durante todo el proyecto, no un desarrollador que hace datos los jueves. Ese es el rol que determina si esto sale bien, junto con el trabajo de desarrollo en Magento 2 de reconstruir la tienda y las integraciones que el extractor no puede trasladar.

Emyrix construye pipelines de migración en las dos direcciones y no tiene problema en decir cuándo un cambio de plataforma no merece la pena. Si está sopesando este paso, escríbanos y definiremos el trabajo de datos con honestidad.

La Admin API de Shopware y las rutas de importación de Magento cambian entre versiones: verifique los detalles de endpoints y comandos contra la documentación actual antes de construir a partir de estos ejemplos.