De MedusaJS a Magento: cuando un desarrollo a medida supera al equipo que lo construyó

Sobre esta dirección se escribe mucho menos que sobre la contraria, y es una pena, porque la situación es lo bastante habitual como para que fingir lo contrario no ayude a nadie.

Un equipo construye sobre Medusa. Va bien. Después el desarrollador que diseñó la lógica del carrito se va, la relación con la agencia termina, marketing quiere un tipo de promoción que necesita un sprint en lugar de un cambio de configuración, y el negocio descubre que «somos dueños de todo el stack» también significa «mantenemos todo el stack».

Eso no es un fallo de Medusa. Medusa hace lo que dice: le da primitivas de comercio y se aparta. Pero un framework que espera que usted construya encaja mal con una organización que ha dejado de poder hacerlo.

Las razones que aparecen de verdad

Dependencia de pocas personas. La más habitual con diferencia. Una o dos personas entendían los módulos a medida. Se han ido. Lo que queda es código bien escrito sin nadie que lo mantenga, y nadie que pueda cambiar el checkout con confianza.

Velocidad del merchandising. En Magento, una regla de precio del carrito nueva con condiciones es configuración del admin. En un desarrollo a medida, parte de eso es un ticket. Los equipos lo notan sobre todo en temporada alta, cuando el negocio quiere cinco promociones a la semana e ingeniería tiene un ciclo de releases.

Capacidad lista para usar, sobre todo B2B. Cuentas de empresa, presupuestos, listas de requisición, listas de precios por empresa, flujos de aprobación. Adobe Commerce lo incluye como un módulo soportado. Habiendo construido quizá el 40 %, el 60 % restante es de repente un cálculo evidente de comprar frente a construir, y comprar empieza a ganar.

Contratación y continuidad. En algunos mercados es sencillamente más fácil contratar capacidad en Magento o una agencia con banquillo que encontrar ingenieros senior de comercio en Node que hereden la arquitectura de otro.

Cumplimiento normativo y compras. Una plataforma respaldada por un proveedor con un contrato de soporte responde a preguntas que «lo construimos nosotros» no responde, en las salas donde eso importa.

Fíjese en lo pocas que son técnicas. Ese es el punto: normalmente es una decisión organizativa, y debería argumentarse en esos términos en lugar de disfrazarse de crítica a la arquitectura.

Tenga claro lo que está dejando

Conviene decirlo sin rodeos para que nadie se sorprenda en el cuarto mes:

• El rendimiento vuelve a ser una disciplina. Pasa de un servicio Node sin estado a una aplicación PHP que necesita full-page cache, Redis o Valkey, OpenSearch y atención continua para seguir rápida. Es alcanzable y está bien entendido, pero es trabajo que no estaba haciendo.
• Hereda una obligación de parcheo. Adobe publica boletines de seguridad con su propio calendario y usted tiene que actuar sobre cada uno. Si no tiene un proceso, constrúyalo antes de salir a producción, no después.
• La libertad arquitectónica se estrecha. La lógica de comercio inusual que era un módulo limpio de Medusa se convierte en un plugin peleándose con la inyección de dependencias. Si su negocio necesita de verdad esa lógica, sopéselo en serio.
• La flexibilidad del frontend cambia de forma. Puede ejecutar Magento headless con un frontend moderno, pero entonces vuelve a mantener una tienda a medida, que puede ser parte de aquello de lo que intentaba escapar.

Si el dolor es específicamente «nuestra tienda está sin mantener», mover el backend a Magento y conservar un frontend a medida resuelve solo la mitad del problema, y posiblemente la mitad equivocada.

El trabajo de datos

Estructuralmente, lo contrario del viaje de entrada, con una cosa a su favor: Postgres y una API de módulos bien definida son mucho más agradables para extraer que una base de datos de Magento.

Productos y variantes → configurables y simples. Cada variante de Medusa se convierte en un producto simple real de Magento con su propio SKU, registro de inventario y precio, agrupado bajo un padre configurable. Decida pronto las reglas de SKU y manténgalas estables entre ejecuciones: acaban en sus URLs, su ERP y su mapa de redirecciones.

Opciones → atributos, y los conjuntos de atributos hay que diseñarlos. Este es el paso que los equipos precipitan. Los conjuntos de atributos de Magento son una estructura deliberada, no un vertedero. Acabar con un conjunto universal y cientos de atributos dispersos es lento de indexar y desagradable de administrar, y reestructurarlo después es doloroso.

Regiones y canales de venta → sitios web, tiendas y vistas de tienda. La jerarquía difiere. Dibuje la estructura de destino antes de escribir código, incluidos la moneda, los impuestos y el ámbito del catálogo en cada nivel.

Las promociones son la importación arriesgada. Las reglas de promoción de Medusa y las reglas de precio de catálogo y carrito de Magento se solapan sin coincidir. Espere volver a implementar en lugar de traducir, y espere que unas cuantas reglas necesiten una expresión completamente distinta. Pruebe cada una contra escenarios reales de carrito, no de forma aislada.

Los pedidos como datos de referencia. Importe los pedidos históricos para atención al cliente e informes. No persiga la paridad funcional completa: repetir pedidos, devoluciones y facturación contra pedidos históricos migrados es una cantidad enorme de trabajo para algo que casi nadie usa.

Las contraseñas no se transfieren. Distinto hashing otra vez. Restablecimiento forzado con un correo claro, planificado por adelantado.

Use las rutas de importación soportadas de Magento —la importación CSV del catálogo y la API REST— en lugar de escribir directamente en las tablas EAV. Los inserts directos producen datos de los que los indexers no saben nada, y se entera semanas después cuando algo no aparece en la búsqueda.

Elija la versión de destino con cuidado

Llega de cero, sin una instalación heredada que arrastrar, que es la posición ideal desde la que tomar esta decisión como es debido. Merece la pena leer la decisión entre 2.4.8 y 2.4.9 antes de irse por defecto a la versión más nueva.

Decida también la edición de forma deliberada. Si el B2B es la razón por la que se mueve, eso apunta a Adobe Commerce. Si no lo es, Magento Open Source o Mage-OS pueden servirle perfectamente, y el dinero de la licencia se gasta mejor en la propia migración.

Antes de comprometerse

Tres preguntas que merece responder con honestidad:

1. ¿El problema real es la plataforma, o el modelo de propiedad? Si es la propiedad, un contrato de soporte para el desarrollo en Medusa podría resolverlo por una fracción del presupuesto de una migración. Consiga ese presupuesto antes de definir la migración.
2. ¿Qué funciones concretas está comprando? «Presupuestos B2B, segmentos de clientes y promociones configurables desde el admin» es una decisión que puede evaluar y poner precio. «Una plataforma más madura» no.
3. ¿Quién lo lleva después? Magento necesita parcheo, actualizaciones y atención al rendimiento. Si nadie es dueño de eso, ha cambiado un sistema sin mantener por otro, con una superficie mayor y un boletín de seguridad mensual.

Responda a esas tres y la decisión normalmente se toma sola. Sáltelas y tendrá esta misma conversación sobre otra plataforma dentro de tres años.

Emyrix trabaja en los dos stacks y no tiene interés en cuál elija. Si quiere una lectura honesta de si una migración o un acuerdo de soporte resuelve su problema real, escríbanos.

Las capacidades de las plataformas cambian rápido en los dos lados: verifique las APIs de módulos actuales de Medusa y las funciones de las ediciones de Magento antes de definir el alcance a partir de este artículo.