De Magento a MedusaJS: no está migrando, está reconstruyendo

Todas las demás migraciones de esta serie le mueven entre plataformas que hacen a grandes rasgos el mismo trabajo, a grandes rasgos de la misma forma. Esta no, y fingir lo contrario es como estos proyectos salen mal.

Medusa es un framework de comercio modular y API-first en Node y TypeScript. Le da primitivas de comercio bien diseñadas —carrito, pedido, precios, cliente, inventario y un motor de workflows para componerlas—, más una aplicación de admin. Lo que no le da es una tienda, un sistema de temas, un marketplace con miles de extensiones ni un conjunto de pantallas de merchandising que un equipo no técnico pueda operar desde el primer día.

Magento le entrega una tienda que después personaliza. Medusa le entrega bloques de comercio que después ensambla. No es una crítica a ninguno de los dos; es toda la decisión.

Sea honesto sobre lo que asume

Lo que se subestima es cuánto de Magento está usando sin darse cuenta. De forma nativa tiene navegación por capas, reglas de precio de catálogo, reglas de precio del carrito con condiciones, grupos de clientes, reglas fiscales por zona, inventario multiorigen, páginas y bloques CMS, reseñas de producto, listas de deseos, un admin completo con ACL granular, un sistema de importación/exportación y un conjunto de informes.

En Medusa, algo de eso existe como módulos, algo existe como paquetes de la comunidad y algo es suyo para construirlo. Antes de comprometerse, coja su admin de Magento, recorra cada pantalla que su equipo toca en un mes normal y marque cada una: existe, hay plugin o la construimos nosotros. Esa lista es el alcance real de su proyecto, y suele ser más larga de lo que la estimación inicial daba por hecho.

Haga lo mismo con las extensiones. Una tienda que ejecuta veinte extensiones comerciales está ejecutando veinte funcionalidades sin equivalente esperándole.

Lo que recibe a cambio

No es un intercambio unilateral, y las ventajas son reales:

Control arquitectónico real. Los módulos de Medusa se pueden sustituir o extender sin forkear el núcleo. Si su lógica de negocio no encaja en el modelo de comercio estándar —suscripciones, cumplimiento complejo, mecánicas de marketplace, precios inusuales—, construirla como un módulo es muchísimo más limpio que pelearse con el sistema de plugins y la inyección de dependencias de Magento para forzar un comportamiento para el que no se diseñó.

Rendimiento por defecto, no como proyecto. Los benchmarks publicados por el propio Medusa afirman que su API es unas seis veces más rápida que la de Magento; trate los benchmarks de un proveedor con el escepticismo adecuado, pero el argumento estructural se sostiene. Un servicio Node sin estado delante de Postgres, con la tienda desplegada aparte, evita la mayor parte de lo que hace del trabajo de rendimiento en Magento una especialidad para empezar.

Escalado y despliegue independientes. La tienda y el backend se despliegan por separado, escalan por separado y fallan por separado. Para equipos que ya hacen frontend moderno, esto encaja con cómo quieren construir.

Bolsa de contratación. Los desarrolladores de TypeScript y React son más fáciles de encontrar que los desarrolladores de Magento con experiencia, y considerablemente más fáciles que los buenos.

La cuestión del equipo decide esto

El modo de fallo más habitual no tiene nada que ver con las plataformas.

Una tienda Magento la mantiene normalmente un equipo de PHP, una agencia o ambos. Medusa necesita capacidad en TypeScript y Node, ingeniería de frontend para la tienda y la propiedad continua de un código que antes le enviaba un proveedor. Si su plan es «nuestra agencia de Magento aprenderá Node», sea muy concreto sobre quién escribe la tienda de verdad y quién le da soporte a las dos de la mañana en el segundo año.

Pregunte directamente:

• ¿Quién es dueño del código de la tienda dentro de dieciocho meses?
• ¿Qué pasa cuando se va la única persona que entiende la personalización del carrito?
• ¿A quién pregunta el equipo de merchandising cuando necesita un tipo de promoción nuevo? ¿Y eso es un cambio de configuración o un sprint?

Esa última pilla a la gente. En Magento, mucho del merchandising es configuración del admin. En un desarrollo a medida, parte de ello se convierte en trabajo de ingeniería, y los equipos de marketing notan ese cambio de inmediato.

La migración de datos es la parte fácil

De verdad, y es la parte que más preocupa a la gente.

Medusa documenta un enfoque basado en plugins para importar datos de Magento, y la forma es sencilla: leer de la API REST o de la base de datos de Magento, escribir a través de los servicios de los módulos de Medusa.

# Pull catalog from Magento's REST API
curl -H "Authorization: Bearer $MAGENTO_TOKEN" \
  'https://your-store.example/rest/V1/products?searchCriteria[pageSize]=100&searchCriteria[currentPage]=1'

Las decisiones de mapeo que importan:

Ejecute la importación repetidamente desde el principio, compare las ejecuciones y cuente todo: productos, variantes, clientes, pedidos, archivos multimedia. «Parece correcto» no es una comprobación de migración.

Las contraseñas no se transfieren: distinto hashing. Planifique un flujo de restablecimiento, y escriba bien el correo.

Cuándo es la decisión correcta

Vaya si tiene capacidad interna en TypeScript y quiere conservarla; su lógica de comercio es realmente inusual y se está peleando con la plataforma para expresarla; está reconstruyendo el frontend de todos modos; o quiere propiedad arquitectónica y tiene el equipo para sostenerla.

Quédese si su equipo es de PHP y va a seguir siéndolo; depende de un stack de extensiones comerciales; su equipo de merchandising se apoya en la configuración del admin y no en desarrolladores; o el problema real es que su tienda Magento está sin parchear y es lenta, cosas que se arreglan sin moverse, por una fracción del coste.

Y sea escéptico ante cambiar de plataforma para escapar de la deuda técnica. La deuda es una práctica de mantenimiento, no una propiedad de la plataforma. Un desarrollo desde cero se siente limpio durante más o menos un año.

Si ha ido en esta dirección y no está funcionando, el camino de vuelta es una opción real y conviene entenderla antes de necesitarla.

Emyrix construye sobre Magento y sobre MedusaJS, lo que significa que le diremos cuándo una reconstrucción no es la respuesta. Si quiere que el alcance función por función se haga como es debido antes de comprometerse, escríbanos.

Las APIs de módulos y las herramientas de migración de Medusa evolucionan rápido: consulte la documentación actual antes de construir contra cualquier interfaz concreta.