Adobe Commerce Cloud vs on-premise: arquitectura, costes y cuándo elegir cada opción

La decisión cloud vs on-premise define el futuro de tu ecommerce enterprise

Adobe Commerce (antes Magento) ofrece dos modelos de despliegue fundamentalmente diferentes: Adobe Commerce Cloud, la solución PaaS gestionada por Adobe, y Adobe Commerce on-premise (o la versión open-source Magento), donde tú controlas toda la infraestructura. Esta decisión no es solo técnica: impacta en costes operativos, velocidad de desarrollo, escalabilidad y la autonomía de tu equipo a largo plazo.

Adobe Commerce Cloud: la infraestructura gestionada

Commerce Cloud se ejecuta sobre AWS con una arquitectura auto-escalable que incluye Fastly CDN integrado, New Relic APM, Elasticsearch dedicado y Redis para caché de sesiones y objetos. La gran ventaja es que Adobe gestiona la infraestructura: actualizaciones de seguridad, patches del sistema operativo, y escala automática en picos de tráfico como Black Friday. El despliegue se realiza mediante pipelines CI/CD integrados con Magento Cloud CLI y Git, lo que estandariza el proceso de desarrollo.

El modelo de pricing de Cloud es por GMV (Gross Merchandise Value) o por licencia anual, con costes que arrancan en torno a los 40.000-60.000€/año para tiendas medianas. Esto incluye infraestructura, licencia, CDN y soporte. Para empresas que no quieren gestionar servidores, es un coste predecible que simplifica la planificación financiera.

Actualización julio 2026: el tablero ha cambiado

Desde que se publicó la primera versión de este artículo, Adobe ha movido ficha con fuerza. En junio de 2025 lanzó Adobe Commerce as a Cloud Service, una edición SaaS multi-tenant totalmente gestionada que se suma a los dos modelos clásicos. Ya no hablamos de una decisión binaria entre Cloud (PaaS) y on-premise: ahora hay tres modelos de despliegue con filosofías muy distintas, y la elección correcta depende más que nunca del perfil técnico de tu equipo y de tu horizonte de negocio.

El calendario de versiones también aprieta. Adobe Commerce 2.4.9 se publicó el 12 de mayo de 2026 con soporte regular hasta mayo de 2029; la 2.4.8 mantiene soporte hasta abril de 2028. En el otro extremo, el soporte de las ramas 2.4.5 y 2.4.6 termina en agosto de 2026: si tu tienda sigue en una de ellas, la ventana para planificar el upgrade se está cerrando ahora mismo. Y hay un dato que muchos CTOs aún no tienen en el radar: a partir de junio de 2027, Adobe se reserva el derecho de dejar de mantener (e incluso desmantelar) entornos Cloud que ejecuten versiones sin soporte. Quedarse quieto ha dejado de ser una opción neutra.

Adobe Commerce as a Cloud Service (SaaS): el tercer modelo

La edición Cloud Service representa el mayor cambio de rumbo de la plataforma en años. Es una arquitectura multi-tenant gestionada íntegramente por Adobe: no hay versiones que actualizar (el concepto de «upgrade» desaparece, las mejoras llegan de forma continua), no hay parches que aplicar y no hay infraestructura que dimensionar. El escalado en picos como Black Friday es automático y transparente.

Qué ganas y qué cedes

La contrapartida es el modelo de personalización. En SaaS no tocas el core de PHP: las extensiones tradicionales de Magento no se instalan tal cual, y la personalización se construye fuera del núcleo mediante API, webhooks y App Builder, junto con storefronts headless de alto rendimiento sobre Edge Delivery Services. Para catálogos y flujos estándar es una vía rapidísima; para lógica de negocio muy específica cosida al core (checkouts a medida, integraciones de bajo nivel con ERPs propietarios, módulos con overrides profundos), el encaje exige rediseñar esas piezas como servicios externos.

Cuándo tiene sentido

El SaaS encaja especialmente bien si tu personalización actual es moderada, si el coste de mantener upgrades bianuales te está drenando presupuesto de evolución, o si tu equipo quiere centrarse en negocio y no en plataforma. Adobe lo está posicionando como destino natural de las tiendas PaaS: su propia recomendación oficial es que si planeas migrar a Cloud Service entre 2026 y 2027, no inviertas en subir a 2.4.8 por el camino. En cambio, si tu ventaja competitiva está precisamente en un stack afinado a medida, los modelos con acceso a código siguen siendo tu terreno.

On-premise: control total, responsabilidad total

El modelo on-premise (con licencia Commerce o con Magento Open Source) te da control absoluto sobre la infraestructura. Puedes elegir tu propio stack: Nginx o Apache, MySQL o Percona, Redis, Varnish, Elasticsearch u OpenSearch, en el proveedor cloud que prefieras (AWS, GCP, Azure, Hetzner). Esto permite optimizaciones de rendimiento imposibles en Cloud, como configuraciones de Varnish personalizadas o clustering de base de datos específico para tu patrón de tráfico.

El coste de infraestructura suele ser significativamente menor: una arquitectura on-premise robusta en AWS puede costar 1.500-3.000€/mes, pero requiere un equipo DevOps o un partner técnico que gestione servidores, seguridad, backups y actualizaciones. La licencia de Adobe Commerce on-premise tiene un coste separado, mientras que Magento Open Source es gratuita pero sin algunas funcionalidades enterprise como staging de contenido, segmentación de clientes o B2B nativo.

Magento Open Source y Mage-OS: la vía comunitaria

La conversación on-premise en 2026 incluye un actor que gana peso: Mage-OS, la distribución comunitaria e independiente construida sobre Magento Open Source. Nació como respuesta al foco creciente de Adobe en sus ediciones de pago y mantiene compatibilidad con el ecosistema de módulos existente, añadiendo parches de seguridad más ágiles, optimizaciones de rendimiento y una gobernanza dirigida por la comunidad, sin coste de licencia ni vendor lock-in. Para tiendas medianas con partner técnico sólido, la combinación Open Source o Mage-OS más un stack bien tuneado (Nginx, Varnish, Redis, OpenSearch) sigue ofreciendo la mejor relación rendimiento/coste del ecosistema, a cambio de asumir tú la responsabilidad de seguridad, backups y actualizaciones. Magento Open Source, por su parte, sigue recibiendo releases alineadas con Commerce: la 2.4.9 de mayo de 2026 incorporó mejoras notables también en la edición gratuita, como la mutación GraphQL clearCart que antes era exclusiva de Commerce.

Comparativa técnica: rendimiento y personalización

En rendimiento puro, un entorno on-premise bien configurado suele superar a Cloud porque puedes tunear cada capa del stack. Cloud tiene limitaciones en la configuración de Varnish (VCL parcialmente bloqueado), en los tamaños de instancia disponibles, y en el acceso SSH (restringido en producción). Sin embargo, Cloud ofrece zero-downtime deployments nativos, entornos de staging automáticos por branch de Git, y auto-scaling que on-premise requiere configurar manualmente con Kubernetes o Auto Scaling Groups.

Frontend en 2026: Hyvä, headless y Edge Delivery

La capa de presentación merece capítulo propio porque condiciona el modelo de despliegue. En el mundo PaaS y on-premise, Hyvä se ha consolidado como el estándar de facto para el frontend de Magento: sustituye el pesado stack Luma por Tailwind y Alpine.js, y en la práctica es la vía más rápida para conseguir buenos Core Web Vitals sin re-arquitecturar la tienda. Para proyectos con equipo frontend propio y necesidades omnicanal, el enfoque headless (PWA Studio, o storefronts a medida en Next.js consumiendo GraphQL) separa por completo presentación y backend, a costa de mantener dos aplicaciones.

En el mundo SaaS, Adobe empuja los storefronts sobre Edge Delivery Services, con renderizado en el edge y puntuaciones de rendimiento muy altas de serie. Es una diferencia estratégica real entre modelos: en Cloud Service el camino frontend «bendecido» viene marcado por Adobe, mientras que en PaaS/on-premise eliges libremente entre Hyvä, headless o Luma legacy. Si tu tienda sufre de velocidad hoy, este suele ser el primer frente a atacar sea cual sea el modelo de despliegue, porque el impacto en conversión y SEO es inmediato.

Costes reales en 2026: TCO comparado

Con tres modelos sobre la mesa, comparar solo la licencia lleva a decisiones equivocadas. Lo que hay que comparar es el coste total de propiedad (TCO) a 3-5 años: licencia + infraestructura + equipo/partner + coste de upgrades.

En PaaS, el paquete (licencia + infraestructura + Fastly + soporte) sigue moviéndose en rangos que van de los 40.000-60.000 €/año de una tienda mediana hasta cifras muy superiores para GMV altos; a eso hay que sumar el coste real de cada upgrade mayor, que en proyectos con muchas personalizaciones puede suponer semanas de trabajo. En SaaS, el precio es por paquetes según uso y elimina la partida de upgrades e infraestructura, lo que baja el TCO en tiendas estandarizadas; la letra pequeña está en el coste de re-arquitectura inicial si vienes de un PaaS muy personalizado. En on-premise/Open Source, la infraestructura de una arquitectura robusta sigue siendo la más barata (desde 1.500-3.000 €/mes en cloud genérico), pero el TCO depende casi por completo del equipo DevOps o partner que la opere: bien gestionado es imbatible en coste; mal gestionado, es el más caro de los tres en incidentes.

Seguridad, parches y cumplimiento

La seguridad es hoy un eje de decisión tan importante como el coste. Desde 2026 Adobe publica parches de seguridad con cadencia mensual, y los incidentes recientes del ecosistema (como la vulnerabilidad crítica SessionReaper de 2025) demostraron que la velocidad de aplicación de parches marca la diferencia entre un susto y una brecha. En SaaS, Adobe parchea por ti; en PaaS aplicas tú los parches sobre una base gestionada; en on-premise todo el ciclo es tuyo. Si operas Magento por tu cuenta, tenemos una guía completa de hardening y parcheo de Magento 2 con el detalle operativo.

En cumplimiento, los tres modelos pueden operar bajo PCI DSS 4.0, pero el reparto de responsabilidades cambia radicalmente: el SaaS hereda la certificación de Adobe en casi toda la pila, mientras que en on-premise el alcance de auditoría recae en tu organización. Si tu empresa se plantea formalizar la gestión de seguridad más allá de la plataforma, una certificación ISO 27001 estructura exactamente este tipo de decisiones de responsabilidad compartida con proveedores cloud, y es más accesible para pymes de lo que suele pensarse.

¿Cuándo elegir cada opción?

Elige Cloud si: tu equipo técnico es pequeño y no quiere gestionar infraestructura, necesitas cumplir PCI DSS sin inversión adicional (Cloud es PCI compliant), tu GMV justifica el coste de licencia, o necesitas desplegar rápido sin preocuparte por la operación del servidor. Elige on-premise si: tienes un equipo DevOps capaz o un partner técnico de confianza, necesitas control total sobre el stack para optimizaciones específicas, tu volumen de negocio hace que el modelo de pricing de Cloud sea prohibitivo, o necesitas integraciones de bajo nivel con sistemas propietarios que requieren acceso completo al servidor.

Y desde 2025 hay una tercera respuesta: elige SaaS (Cloud Service) si tu personalización es moderada y encaja en API + App Builder, si quieres eliminar upgrades y parches de tu roadmap para siempre, y si prefieres invertir el presupuesto de plataforma en experiencia de cliente en lugar de en operación.

Rutas de migración típicas en 2026

En los proyectos que estamos viendo este año se repiten tres rutas. La primera es el upgrade dentro de PaaS/on-premise: subir de 2.4.5/2.4.6 a 2.4.8 o 2.4.9 antes de agosto de 2026, imprescindible si vas a permanecer en el modelo actual varios años. La segunda es la migración PaaS → SaaS: inventariar personalizaciones, decidir cuáles se rediseñan como apps externas y cuáles se abandonan, y mover el storefront a Edge Delivery o headless; Adobe ofrece herramientas de migración de datos, pero el grueso del esfuerzo está en el código a medida. La tercera es la consolidación on-premise con Open Source o Mage-OS para quien prioriza control y coste. En cualquiera de las tres, empezar por una auditoría técnica del estado real de la tienda (deuda técnica, módulos abandonados, overrides) evita descubrir sorpresas a mitad de migración.

Errores comunes al decidir

El primero es comparar precios de lista en lugar de TCO a 3-5 años, ignorando el coste recurrente de upgrades y del equipo necesario. El segundo, subestimar el inventario de personalizaciones: la viabilidad del SaaS depende de un análisis honesto de cuánta lógica vive cosida al core. El tercero, decidir sin fecha de caducidad en la mano: con el fin de soporte de 2.4.5/2.4.6 en agosto de 2026 y la política de decomisado de junio de 2027, el calendario ya no lo marca tu roadmap sino el de Adobe. Y el cuarto, tratar la migración como un proyecto puramente de infraestructura cuando en realidad es un proyecto de arquitectura de aplicación.

Preguntas frecuentes

¿Va a desaparecer el modelo PaaS de Adobe Commerce?

No a corto plazo. Adobe mantiene el soporte de las ramas 2.4.8 (hasta abril de 2028) y 2.4.9 (hasta mayo de 2029) y sigue vendiendo el modelo PaaS. Pero la dirección estratégica es clara: la inversión en producto se concentra en Cloud Service, y conviene tomar decisiones asumiendo ese rumbo.

¿Puedo usar mis módulos de Magento en Adobe Commerce as a Cloud Service?

No directamente. El SaaS no permite instalar extensiones que modifican el core; la funcionalidad equivalente se implementa vía API, webhooks y App Builder. Parte del ecosistema de vendors está publicando versiones «app» de sus extensiones, pero el catálogo aún es menor que el de módulos clásicos.

Sigo en Magento 2.4.6, ¿qué hago antes de agosto de 2026?

Planificar ya el salto a 2.4.9 (o 2.4.8 si tu stack de módulos aún no es compatible). Operar sin parches de seguridad en un ecommerce con pagos es un riesgo inasumible, y en Cloud además te expone a la política de decomisado de 2027.

¿Qué es mejor para una tienda mediana en España: Open Source o Mage-OS?

Funcionalmente hoy son casi equivalentes y compatibles entre sí. Mage-OS aporta una gobernanza comunitaria y parches más ágiles; Open Source aporta el respaldo directo de las releases de Adobe. La decisión suele depender más del partner técnico que te acompañe que de la distribución en sí.

¿Cuánto cuesta migrar de PaaS a Cloud Service (SaaS)?

Depende casi por completo del volumen de personalizaciones a rediseñar como apps externas. Una tienda cercana al estándar puede migrar en pocas semanas aprovechando las herramientas de datos de Adobe; una tienda con años de módulos a medida debe presupuestar un proyecto de re-arquitectura por fases. Por eso el primer paso sensato es siempre un inventario técnico de módulos, overrides e integraciones, cuantificando qué porcentaje del código encaja en el modelo API + App Builder.

Conclusión

La pregunta ya no es solo «¿cloud o on-premise?» sino «¿cuánto control necesito y cuánta operación quiero asumir?». El SaaS convierte la plataforma en un servicio y libera al equipo de la gestión de versiones; el PaaS mantiene el equilibrio entre gestión delegada y acceso a código; el on-premise (con Open Source o Mage-OS) sigue siendo el rey del control y del coste de infraestructura para quien puede operarlo bien. Las fechas de soporte de 2026-2027 obligan a decidir pronto y con datos. Si estás valorando el movimiento —o simplemente eligiendo plataforma—, nuestra guía para elegir plataforma ecommerce en 2026 complementa este análisis con la foto completa del mercado.