Adobe Commerce as a Cloud Service: qué es y qué cambia frente a Magento Open Source

• Qué es: el modelo SaaS de Adobe Commerce, disponible de forma general desde el 25 de junio de 2025.
• Qué ganas: actualizaciones continuas administradas por Adobe y cero mantenimiento de servidores, PHP o base de datos.
• Qué pierdes: módulos PHP dentro de la aplicación, temas como Hyvä o Luma y parte de la personalización del admin, búsqueda y correos.
• Qué no cambia: Magento Open Source y Adobe Commerce en PaaS u on-premise siguen existiendo y recibiendo soporte.

En este artículo:

• Qué es Adobe Commerce as a Cloud Service
• Los tres modelos: SaaS, PaaS y Magento autohospedado
• Qué cambia en extensiones y personalización
• Qué pasa con el frontend, Luma y Hyvä
• Tabla comparativa
• Cuándo conviene y cuándo no
• Qué implica migrar
• Preguntas frecuentes

Durante más de una década, elegir Magento significaba elegir entre Magento Open Source y Adobe Commerce, y luego decidir dónde hospedarlo. Con Adobe Commerce as a Cloud Service aparece una tercera vía: Adobe Commerce como SaaS. Aquí explicamos qué es, qué cambia frente a Magento Open Source y para qué tipo de tienda tiene sentido.

¿Qué es Adobe Commerce as a Cloud Service?

Es Adobe Commerce entregado como software como servicio. Adobe lo anunció en Adobe Summit en marzo de 2025 y lo liberó de forma general el 25 de junio de 2025. Adobe aloja y administra la aplicación, la infraestructura y las actualizaciones. Tú configuras la tienda y la extiendes por APIs, sin acceso al código del núcleo.

Adobe lo describe con cinco atributos: nativo de la nube, siempre actualizado, aprovisionamiento autoservicio, preconfigurado y componible. En la práctica, la plataforma es versionless: no hay versiones 2.4.x que actualizar porque los cambios llegan de forma continua.

¿En qué se diferencia de Adobe Commerce en la nube y de Magento autohospedado?

La diferencia está en quién es responsable de cada capa. Adobe documenta tres modelos de despliegue y el reparto de trabajo cambia mucho entre ellos:

• Adobe Commerce as a Cloud Service (SaaS): Adobe opera la aplicación, la infraestructura y las actualizaciones. El comerciante no puede modificar el núcleo.
• Adobe Commerce on Cloud Infrastructure (PaaS): responsabilidad compartida. Adobe administra la plataforma; tú aplicas parches, mantienes tu código y actualizas PHP, base de datos, caché, búsqueda y colas a versiones soportadas.
• Adobe Commerce on-premise y Magento Open Source: tú o tu proveedor de hosting administran toda la infraestructura y todos los servicios.

Magento Open Source no tiene versión SaaS. Es el código abierto gratuito que se instala en tu propio servidor, por ejemplo en hosting administrado como Cloudways. Si comparas las ediciones con licencia, lo explicamos en Adobe Commerce vs Magento Open Source en 2026.

¿Qué cambia en extensiones y personalización?

Es el cambio más grande. En Magento autohospedado y en Adobe Commerce PaaS, la personalización vive dentro de la aplicación: módulos PHP, plugins y observers instalados con Composer. En ACCS ese modelo ya no aplica: todo se extiende fuera del proceso.

• App Builder: las personalizaciones se convierten en aplicaciones externas que se comunican con la tienda por eventos, webhooks y APIs.
• API Mesh: unifica APIs en un solo endpoint GraphQL.
• Tecnologías: la tabla de Adobe lista CSS, CLI, HTML, JavaScript y Node para SaaS; PHP y XML quedan para PaaS.
• Datos: el modelo de datos se limita a atributos personalizados, y el almacenamiento propio usa la librería de estado de App Builder.
• Límites adicionales: la personalización de búsqueda requiere un tercero y los correos usan solo plantillas estándar.

Esto también afecta a las extensiones del Marketplace. Un módulo PHP que hoy instalas con Composer no corre en ACCS; necesita una versión construida para App Builder.

¿Qué pasa con el frontend: Luma, Hyvä y Edge Delivery Services?

Adobe indica que ACCS no soporta storefronts Luma. El frontend por defecto es Commerce Storefront sobre Edge Delivery Services, totalmente headless, que lee los datos por GraphQL. Cualquier tema que se renderiza dentro de la aplicación PHP tiene que reconstruirse.

Eso incluye a Hyvä Theme y Hyvä Checkout, que funcionan sobre el frontend PHP de Magento. Hyvä sigue siendo la opción natural para Magento Open Source y Adobe Commerce PaaS u on-premise, con Hyvä Commerce para Open Source. Si tu tienda ya invirtió en Hyvä, migrar a ACCS implica rehacer ese frontend.

Tabla comparativa: ACCS vs Adobe Commerce PaaS vs Magento Open Source

¿Cuándo conviene Adobe Commerce as a Cloud Service y cuándo no?

Conviene a empresas que ya pagan Adobe Commerce, usan otros productos de Adobe Experience Cloud y prefieren no operar infraestructura ni hacer upgrades. También a quien arranca de cero con pocas personalizaciones y puede construir directamente sobre App Builder y Edge Delivery Services.

Es menos conveniente si tu operación depende de módulos PHP a la medida, de lógica dentro del núcleo, de un frontend Hyvä ya optimizado o de integraciones que hoy viven dentro de Magento. Para una tienda en México que no paga licencia de Adobe, Magento Open Source con Hyvä mantiene control total del código y del costo de hosting.

Adobe no publica precios de ACCS en su sitio; se cotiza con su equipo de ventas. Haz la comparación con propuestas reales, no con estimaciones genéricas.

¿Qué implica migrar de Magento o Adobe Commerce a ACCS?

No es un upgrade, es una replataforma. Adobe lo dice así: ninguna de las áreas se migra sin adaptarla. Las personalizaciones se rehacen en App Builder, el storefront se reconstruye en Edge Delivery Services, los datos se mueven a un nuevo tenant y las integraciones se rehacen con patrones SaaS.

1. Evaluar: inventario de módulos, extensiones, integraciones, frontend y tablas propias. Adobe ofrece una herramienta de evaluación con IA para esto.
2. Modernizar la aplicación y migrar datos: catálogo, clientes y pedidos con el Commerce Data Migration Service. Los datos de extensiones de terceros en tablas propias no se migran automáticamente.
3. Reconstruir el storefront sobre Edge Delivery Services.
4. Corte y operación: cambio de tráfico y retiro de los sistemas anteriores.

Antes de decidir, el primer paso es el mismo que en cualquier proyecto serio: saber qué tienes. Nuestro checklist de takeover de Magento sirve para hacer ese inventario. Si decides quedarte en Magento, la ruta es mantener la versión al día; lo explicamos en cómo hacer un upgrade de Magento sin perder datos.

Conclusión

Adobe Commerce as a Cloud Service cambia la pregunta de siempre. Ya no es solo qué edición de Magento elegir, sino cuánto control quieres conservar a cambio de no operar la plataforma.

Para muchas tiendas con módulos a la medida, integraciones con ERP y un frontend Hyvä, quedarse en Magento sigue siendo lo sensato. Si necesitas apoyo para decidir o para mantener tu tienda, revisa nuestro soporte Magento y nuestros servicios de integraciones.

Sobre el autor

Panamerik dirige Panamerik, agencia especializada en Magento y Adobe Commerce desde Guadalajara. Su equipo diseña, desarrolla, integra y da soporte a tiendas en línea.

Fuentes

• Adobe Experience League: Migrate to Adobe Commerce as a Cloud Service (actualizada el 20 de octubre de 2026)
• Adobe Experience League: Feature comparison (actualizada el 20 de octubre de 2026)
• Adobe Experience League: Adobe Commerce as a Cloud Service overview (consultado el 28 de octubre de 2026)
• Adobe Experience League: Getting started (consultado el 28 de octubre de 2026)
• Adobe Developer: Extension compatibility (consultado el 28 de octubre de 2026)
• Adobe Blog: Drive conversions and lower costs with Adobe Commerce as a Cloud Service (consultado el 28 de octubre de 2026)