De Mage-OS de vuelta a Magento o Adobe Commerce: cuándo y cómo
Esta es la mitad menos escrita de la conversación sobre Mage-OS, y merece escribirse con honestidad porque las razones para ir en esta dirección casi nunca son técnicas.
Mage-OS es una distribución de Magento Open Source construida sobre el mismo código. Así que «migrar de vuelta» a Magento Open Source es, mecánicamente, el mismo cambio pequeño que hizo para irse. Migrar hacia arriba a Adobe Commerce es otra cosa completamente distinta: una compra, una licencia y un proyecto de adopción de funciones.
Dos destinos distintos, y confundirlos es la principal forma en que esto se planifica mal.
De vuelta a Magento Open Source
Si el destino es Open Source, esto es un cambio a nivel de Composer y nada más. Su base de datos, su tema, sus extensiones y sus personalizaciones no se ven afectados porque nunca fueron específicos de la distribución.
# Point Composer back at Adobe's repository
composer config repositories.magento composer https://repo.magento.com/
# Swap the metapackage back
composer require magento/product-community-edition=<version> --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
Tres cosas que comprobar en lugar de dar por hechas:
Paridad de versiones. Aterrice en la versión de Magento que coincida con la base sobre la que se construyó su versión de Mage-OS. Mage-OS 3.x sigue 2.4.9, así que 2.4.9 es su destino. Cambiar distribución y versión a la vez es como se acaba sin poder atribuir una regresión.
Credenciales de Composer. Necesitará claves de repo.magento.com que funcionen en auth.json, en el servidor y en CI. Caducan y se olvidan. Verifique que autentican antes de la ventana de deploy, no durante ella.
Cualquier cosa específica de Mage-OS que adoptara. Si por el camino incorporó complementos incluidos o paquetes específicos de Mage-OS, tienen que salir o sustituirse. Busque mage-os/ en su composer.json y dé cuenta de cada línea. Hágalo de forma deliberada y no mecánica: la distribución incluye devoluciones, un registro de actividad del admin y un montón de trabajo de rendimiento para los que Magento no tiene equivalente, y «ya lo resolveremos más tarde» tiende a significar que alguien descubre en la segunda semana que el flujo de devoluciones ha desaparecido.
Igual que en el viaje de ida: la base de datos no se toca, así que el rollback es una reversión de código. De medio día a un día en una tienda sana.
Hacia arriba, a Adobe Commerce
Otro ejercicio, y las razones son comerciales y organizativas mucho más que técnicas.
El conjunto de funciones. El motivo honesto en la mayoría de los casos. Adobe Commerce incluye capacidades que Open Source y Mage-OS no tienen; hemos puesto precio a esa diferencia en detalle, y es la parte que decide el presupuesto:
| Capacidad | Por qué los equipos acaban necesitándola |
|---|---|
| Módulo B2B | Cuentas de empresa, presupuestos, listas de requisición, catálogos y precios por empresa |
| Content Staging y Preview | Marketing programando campañas sin un desarrollador |
| Segmentos de clientes | Contenido, precios y promociones dirigidos según el comportamiento |
| Merchandising avanzado | Merchandising visual de categorías y ordenación por reglas |
| Commerce Cloud | Infraestructura gestionada con SLA |
Si ha pasado dieciocho meses construyendo presupuestos B2B sobre Open Source con tres extensiones y un módulo a medida, el coste de mantenimiento de ese stack es una razón legítima para comprar la versión soportada en su lugar.
Requisitos de compras. Los compradores enterprise, las empresas matrices y algunos sectores regulados quieren un contrato con proveedor, un SLA de soporte y una ruta de escalado con nombre. «Lo mantiene la comunidad» es una respuesta correcta que pierde acuerdos en ciertas salas. No es un argumento técnico, pero es real.
Tolerancia al riesgo a escala. Por encima de cierto volumen de ingresos, algunas organizaciones quieren una contraparte comercial para su plataforma de comercio. Razonable, y merece ponerle precio con honestidad frente a lo que cuesta de verdad la licencia.
Qué implica: el cambio de distribución es la mitad fácil —el metapaquete pasa a ser magento/product-enterprise-edition y la licencia se valida a través de sus claves de Composer—. El trabajo real es adoptar las funciones que compró. Activar el B2B es un proyecto de modelado de datos y de procesos, no una casilla que marcar. Presupuéstelo como un proyecto por derecho propio, idealmente después de que el cambio de plataforma se haya asentado.
Cuándo lo desaconsejaríamos
No se mueva por un soporte que no va a usar. Un SLA que nunca invoca cuesta lo mismo que uno que sí. Si su agencia ya responde en menos de una hora, ponga precio a la licencia frente al volumen de incidentes que tiene de verdad.
No se mueva para arreglar un problema de mantenimiento. Una tienda sin parchear con extensiones abandonadas está sin parchear en cualquier distribución. Adobe Commerce no le aplica los parches. Arregle primero el proceso de parcheo, sobre lo que sea que ejecute hoy, y después decida.
No se mueva a mitad de una actualización. Si va atrasado de versiones, póngase al día primero. Cambiar distribución, versión y edición a la vez produce una regresión que nadie puede atribuir.
Una secuencia que funciona
- Escriba la capacidad concreta que está comprando. «Presupuestos B2B» y «un SLA de soporte con respuesta en 4 horas» son decisiones que puede evaluar. «De nivel enterprise» no.
- Ponga precio a la alternativa. Extensiones más desarrollo más mantenimiento para las mismas funciones en Open Source o Mage-OS, a tres años, frente al coste de la licencia. A veces la licencia gana con claridad. A veces, ni de lejos.
- Llegue primero a la paridad de versiones, como deploy aparte.
- Cambie la distribución, verifique, y déjela asentarse en producción un par de semanas.
- Después adopte las funciones de Commerce, de una en una, cada una con sus propias pruebas.
Ese último punto es el que la gente comprime, y comprimirlo es lo que convierte un cambio de plataforma en un mal trimestre.
La versión corta
De Mage-OS a Magento Open Source es un cambio pequeño, reversible y de bajo riesgo: el mismo que hizo en la otra dirección.
De Mage-OS a Adobe Commerce es una decisión comercial con disfraz técnico. Tómela sobre las funciones concretas y las garantías contractuales que necesita, póngale precio frente a construir la misma capacidad usted mismo, y secuénciela para no estar nunca depurando tres cambios a la vez.
Emyrix trabaja en Magento Open Source, Adobe Commerce y Mage-OS, y no tiene ningún incentivo para empujar hacia ninguno. Si quiere que la comparación de licencia frente a construcción se haga como es debido para su tienda, escríbanos.
La disponibilidad de funciones y las condiciones de licencia de Adobe Commerce cambian: confirme con Adobe el contenido actual del paquete antes de presupuestar a partir de esta tabla.
Preguntas frecuentes
¿Cómo de difícil es pasar de Mage-OS de vuelta a Magento Open Source?
Es un cambio a nivel de Composer y nada más, porque su base de datos, su tema, sus extensiones y sus personalizaciones nunca fueron específicas de la distribución. En una tienda sana es más o menos de medio día a un día, y el rollback es una reversión de código, porque la base de datos no se toca.
¿A qué versión de Magento debería apuntar viniendo de Mage-OS?
Aterrice en la versión de Magento que coincida con la base sobre la que se construyó su versión de Mage-OS. Mage-OS 3.x sigue 2.4.9, así que 2.4.9 es su destino. Cambiar distribución y versión a la vez es como se acaba sin poder atribuir una regresión.
¿Por qué pasaría un negocio de Mage-OS a Adobe Commerce?
Las razones son comerciales y organizativas mucho más que técnicas: el conjunto de funciones de Adobe Commerce, como el módulo B2B, Content Staging, los segmentos de clientes y Commerce Cloud; los requisitos de compras de un contrato con proveedor y un SLA de soporte; y la tolerancia al riesgo a escala, que quiere una contraparte comercial.
¿Qué debería comprobar antes de cambiar de distribución desde Mage-OS?
Compruebe la paridad de versiones para aterrizar en la base de Magento correspondiente, verifique que hay credenciales de Composer de repo.magento.com que funcionen en el auth.json del servidor y en CI antes de la ventana de deploy, y busque en su composer.json cualquier paquete específico de Mage-OS que haya que eliminar o sustituir.
