De Magento a Mage-OS: un cambio de distribución, no de plataforma
La mayoría de los artículos sobre migraciones tratan de dejar una plataforma por otra distinta. Este en su mayor parte no, y dejarlo claro desde el principio ahorra mucha planificación inútil.
Mage-OS es una distribución independiente y sin ánimo de lucro de Magento Open Source. No es una reescritura, ni un fork hostil que divergió hace años: es una distribución construida sobre el mismo código, que actualmente sigue la línea 2.4.9 de Magento Open Source, con el objetivo declarado de seguir siendo compatible con las extensiones e integraciones existentes de Magento 2.
Lo que significa que la respuesta honesta a «¿cómo de difícil es la migración?» depende por completo de una pregunta: ¿está en Magento Open Source o en Adobe Commerce?
Los dos puntos de partida no se parecen en nada
Desde Magento Open Source, esto es un cambio de distribución. Su base de datos no cambia. Su tema no cambia. Sus extensiones siguen funcionando. Lo que cambia es de dónde obtiene Composer los paquetes y, con el tiempo, quién le envía las correcciones.
Desde Adobe Commerce, es una migración de verdad, porque Mage-OS forkea Open Source, no Commerce. Todo lo que paga a Adobe y no está en Open Source hay que sustituirlo o reconstruirlo. Es un proyecto distinto con un presupuesto distinto.
Sea preciso sobre cuál de los dos es antes de seguir leyendo, y tenga en cuenta que «tenemos una licencia de Magento» no lo zanja. Compruebe qué requiere de verdad su archivo de Composer: magento/product-community-edition o magento/product-enterprise-edition.
Por qué los equipos lo miran
Las razones que oímos, más o menos por orden de frecuencia; y desde entonces hemos escrito el argumento completo, función por función:
Gobernanza y visibilidad de la hoja de ruta. Mage-OS publica una hoja de ruta abierta y está gobernado por una asociación sin ánimo de lucro y no por las prioridades comerciales de un solo proveedor. Para equipos a los que un cambio de licencia o de ciclo de vida sorprendió alguna vez, esa predictibilidad tiene valor real.
Cadencia de parches. Mage-OS publica versiones que incorporan las correcciones de seguridad de Adobe: su versión 3.2.0 de julio de 2026 llevaba el parche de seguridad de Magento 249-2026-07-001, por ejemplo. En la práctica recibe el mismo contenido de seguridad por otro canal, y sigue teniendo que aplicarlo.
Cosas que Magento no incluye en absoluto. La distribución agrupa módulos que no existen ni en Magento Open Source ni en Adobe Commerce, incluidos interceptors de plugins compilados y otro trabajo de rendimiento que Adobe declinó integrar upstream.
Alineación del ecosistema. Una parte grande de los proveedores de extensiones y las agencias que construyeron el ecosistema de Magento participan en Mage-OS. Si sus proveedores ya están ahí, estar en la misma distribución reduce la fricción.
Coste, pero solo desde Commerce. De Open Source a Mage-OS no ahorra nada directamente: Open Source ya es gratuito. El ahorro está en dejar una licencia de Adobe Commerce, y eso viene con los intercambios de más abajo.
Lo que no es: un arreglo para una tienda sin mantener. Si su instalación va tres años por detrás con extensiones abandonadas, Mage-OS hereda cada uno de esos problemas. Resuelva primero su posición de parcheo.
Viniendo de Magento Open Source
La mecánica no tiene dramatismo. Mage-OS replica los paquetes de Magento y publica su propia distribución, así que el cambio está a nivel de Composer:
# Point Composer at the Mage-OS mirror instead of repo.magento.com
composer config repositories.magento composer https://mirror.mage-os.org/
# Then switch the metapackage to the Mage-OS distribution
composer require mage-os/product-community-edition=<version> --no-update
composer update
bin/magento setup:upgrade
bin/magento setup:di:compile
bin/magento setup:static-content:deploy -f
Compruebe los nombres y versiones actuales de los paquetes contra la propia documentación de Mage-OS antes de ejecutar nada de esto: la distribución se ha movido más rápido que la mayoría de los artículos sobre ella.
Qué planificar de verdad:
Alineación de versiones. Mage-OS 3.x está construido sobre la base 2.4.9, y abandona PHP 8.2 junto con alguna otra cosa. Si está en 2.4.6 o 2.4.7, está haciendo una actualización de versión de Magento y un cambio de distribución. Hágalos como dos deploys separados: actualice primero, confirme que la tienda es estable, y después cambie de distribución. Combinarlos significa que, cuando algo se rompa, no sabrá qué cambio lo causó.
Servidores de licencias de extensiones. Algunas extensiones comerciales llaman a casa y validan contra una instalación de Magento. A la mayoría no le importa la distribución; unas pocas comprueban las cadenas de versión de formas que sorprenden a todos los implicados. Haga inventario de sus extensiones de pago y pregunte a cada proveedor directamente. Es la fuente más habitual de sorpresas desagradables.
Su pipeline de deploy. Cualquier cosa que tenga escritas a fuego las credenciales de repo.magento.com —la configuración de CI, las builds de Docker, el auth.json del servidor, su composer.lock— necesita actualizarse a la vez. Olvidar una produce una build que funciona en local y falla en CI.
Su rollback. Como la base de datos no se toca, el rollback es una reversión a nivel de código: release anterior, composer.lock anterior, listo. Eso lo convierte en uno de los cambios más seguros que puede hacer a una tienda Magento, y conviene confirmarlo en lugar de darlo por hecho.
De forma realista: uno o dos días de trabajo en una tienda bien mantenida, la mayor parte verificación y no cambios.
Viniendo de Adobe Commerce
Otro proyecto. Mage-OS es un fork de Open Source, así que cada capacidad exclusiva de Commerce hay que sustituirla. La versión corta está abajo; la larga, incluida la infraestructura y el contrato, es donde está el coste real:
| Función de Adobe Commerce | Qué pasa en Mage-OS |
|---|---|
| Módulo B2B (cuentas de empresa, presupuestos, listas de requisición) | No incluido: sustituir con extensiones o desarrollo a medida |
| Content Staging y Preview | No incluido |
| Segmentos de clientes y reglas dirigidas | No incluido |
| Merchandising avanzado/visual | No incluido |
| Infraestructura de Adobe Commerce Cloud | El hosting lo proporciona y opera usted |
| SLA de soporte de Adobe | La comunidad y su agencia |
Si usa dos de esas de forma ligera, es un ejercicio de alcance manejable. Si su negocio funciona sobre los presupuestos B2B y la segmentación de clientes, sustituirlos es el proyecto, y el trabajo de Magento es accesorio.
Planifique también el lado comercial: condiciones de licencia, fechas de renovación y si algo en su contrato regula cómo y cuándo puede irse. Es una conversación que tener pronto, no después de aprobar el plan técnico.
Cómo decidir
Cambie si está en Open Source, razonablemente al día, y quiere transparencia de gobernanza y de hoja de ruta: el riesgo técnico es realmente bajo y reversible.
Mírelo con cuidado si está en Adobe Commerce y usa sobre todo funciones de Open Source de todos modos. Muchas tiendas pagan Commerce y usan muy poco de él. Audite el uso real antes de dar por hecho que las funciones son estructurales.
No lo haga si está en Commerce y depende del B2B, del staging o de la segmentación, salvo que haya puesto precio a su sustitución como es debido. «Ya lo reconstruiremos» es donde estos proyectos se pasan de plazo.
Y en cualquier caso: póngase al día con los parches primero. Un cambio de distribución es un buen momento para estar al día, no un sustituto de estarlo.
Qué haríamos primero
- Confirme en qué edición está de verdad, desde
composer.json, no de memoria. - Haga inventario de las extensiones de pago y escriba a cada proveedor sobre la compatibilidad con Mage-OS. Hágalo antes que nada: las respuestas marcan el calendario.
- Si va atrasado, actualice a la línea 2.4.9 como proyecto aparte y despliéguelo.
- Cambie la distribución en staging, ejecute una regresión completa y cronometre un rollback.
- Despliegue en una ventana de poco tráfico con la release anterior lista para restaurar.
Si más adelante decide que no era para usted, volver atrás es más o menos el mismo ejercicio a la inversa, que es en buena parte por lo que el riesgo aquí es menor de lo que parece a primera vista.
Emyrix trabaja en Magento, Adobe Commerce y Mage-OS, incluidos los cambios de distribución y la auditoría de compatibilidad de extensiones que decide si uno es sencillo. Si quiere que evaluemos el suyo, escríbanos.
Los nombres de paquetes, las versiones y la hoja de ruta de Mage-OS cambian más rápido que los artículos: consulte mage-os.org para el estado actual antes de planificar una versión concreta.
Preguntas frecuentes
¿Mage-OS es un fork de Magento?
Mage-OS es una distribución independiente y sin ánimo de lucro de Magento Open Source construida sobre el mismo código —no una reescritura ni un fork hostil—, que actualmente sigue la línea 2.4.9 de Magento Open Source con el objetivo de seguir siendo compatible con las extensiones e integraciones existentes de Magento 2.
¿Cómo de difícil es pasar de Magento Open Source a Mage-OS?
En una tienda bien mantenida son, de forma realista, uno o dos días de trabajo, la mayor parte verificación y no cambios, porque el cambio ocurre a nivel de Composer y la base de datos no se toca, lo que convierte el rollback en una reversión a nivel de código.
¿Cambiar a Mage-OS ahorra dinero?
De Open Source a Mage-OS no ahorra nada directamente, porque Open Source ya es gratuito. El ahorro viene solo de dejar una licencia de Adobe Commerce, que trae consigo el intercambio de sustituir las funciones exclusivas de Commerce.
¿Qué funciones de Adobe Commerce no están incluidas en Mage-OS?
Las capacidades exclusivas de Commerce, como el módulo B2B, Content Staging y Preview, los segmentos de clientes y las reglas dirigidas, el merchandising avanzado, la infraestructura de Commerce Cloud y el SLA de soporte de Adobe, no están incluidas y hay que sustituirlas con extensiones, desarrollo a medida o su propia operación.
