Elegir entre Drupal Commerce y WooCommerce no es una cuestión de cuál es mejor en abstracto: es una cuestión de qué proyecto tienes entre manos. Las dos son soluciones de ecommerce open source, maduras y con años de recorrido, pero resuelven problemas distintos y arrastran ecosistemas, costes y perfiles de equipo muy diferentes.
En esta guía las comparamos desde el punto de vista de quien las implanta y las mantiene: arquitectura, modelo de datos, rendimiento, coste real de propiedad, disponibilidad de talento y, sobre todo, en qué escenarios concretos merece la pena cada una. Al final encontrarás un árbol de decisión en cuatro preguntas y los errores que vemos con más frecuencia en proyectos que eligieron mal.
Actualizado en septiembre de 2026 con el estado real de ambos proyectos: Drupal 11, el fin de soporte de Drupal 10, la rama 3.x de Drupal Commerce y el ciclo de releases de WooCommerce 10.x.
Dos ecosistemas, dos filosofías de ecommerce
Drupal Commerce y WooCommerce son soluciones open source de ecommerce, pero parten de CMSs muy diferentes. WooCommerce domina el mercado en número de instalaciones —según la fuente y la metodología, entre un 20% y un 39% de cuota, con algo más de 4,3 millones de tiendas activas en 2026—, mientras que Drupal Commerce ocupa un nicho más especializado pero con capacidades únicas.
Conviene leer esas cifras con cuidado: las cuotas altas salen de contar todas las webs con la plataforma instalada, y las bajas de mirar solo el millón de sitios de ecommerce con más tráfico, donde el reparto cambia bastante. En cualquier caso, la conclusión práctica se mantiene: WooCommerce es el volumen y Drupal Commerce es la especialización.
La diferencia de fondo es de diseño. WooCommerce parte de un gestor de contenidos pensado para publicar y le añade encima una capa de tienda. Drupal Commerce parte de un framework de contenido estructurado y modela la tienda como un tipo más de entidad dentro de ese sistema. Esa decisión explica casi todo lo demás: por qué WooCommerce arranca antes y por qué Drupal Commerce aguanta mejor los modelos de negocio poco convencionales.
Qué significa en la práctica
En WooCommerce, un producto es un tipo de contenido (post type) con metadatos. Funciona muy bien mientras el producto se parezca a un producto de catálogo: nombre, precio, variantes, stock, imágenes. Cuando necesitas que un producto se relacione con una ficha técnica, con un curso, con un contrato de servicio y con un catálogo por país, empiezas a añadir plugins que resuelven cada pieza por separado y la coherencia del conjunto pasa a depender de ti.
En Drupal Commerce, producto, variación, tienda, pedido, perfil de cliente y método de pago son entidades de primera clase del sistema, con campos configurables y referencias entre ellas. Modelar esas relaciones es trabajo de configuración, no de integración de plugins de terceros. A cambio, ese modelado exige criterio y un equipo que sepa lo que hace: la flexibilidad mal usada se convierte en complejidad.
Estado de ambas plataformas en 2026
Antes de comparar capacidades conviene fijar en qué punto está cada proyecto, porque el calendario de versiones condiciona la decisión tanto como las funcionalidades.
Drupal y Drupal Commerce
Drupal 11 es la rama estable y en activo, con la serie 11.4.x publicada durante el verano de 2026. Lo relevante para cualquier proyecto vivo es la fecha de caducidad de la generación anterior: Drupal 10 llega a su fin de vida el 9 de diciembre de 2026, y a partir de ahí deja de recibir parches de seguridad. Drupal 12 está previsto para la semana del 7 de diciembre de 2026, en línea con el ciclo de una versión mayor cada dos años.
Drupal Commerce va por la rama 3.x, compatible con Drupal 10.3 en adelante y con Drupal 11, con versiones estables publicadas de forma regular a lo largo de 2026. La actualización desde Commerce 2.x es razonablemente directa siempre que el código propio no dependa de APIs marcadas como obsoletas durante el ciclo de la 2.x. Si tienes una tienda en Commerce 2 sobre Drupal 10, la ventana para planificar el salto es ahora, no en diciembre.
Si quieres el detalle de qué cambió con la versión mayor, lo desglosamos en Drupal 11: recipes, hooks como clases y Symfony 7.
WordPress y WooCommerce
WooCommerce está en la serie 10.x, con un ritmo de releases mensuales y correcciones puntuales entre medias. Las líneas de trabajo de los últimos ciclos han ido al rendimiento del storefront, a la maduración del almacenamiento de pedidos en tablas propias (HPOS) en lugar de la tabla de posts, a los bloques de carrito y checkout, y a la compatibilidad con las nuevas versiones de WordPress.
Ese cambio en el almacenamiento de pedidos es más importante de lo que parece: durante años el principal cuello de botella de WooCommerce a volumen alto era guardar pedidos como posts con metadatos. Con HPOS, buena parte de la crítica clásica sobre escalabilidad de WooCommerce ha dejado de ser válida, siempre que la tienda y sus extensiones estén actualizadas.
Qué implica para tu decisión
Si tu web corre hoy sobre Drupal 10, la conversación deja de ser Drupal Commerce contra WooCommerce y pasa a ser cuándo actualizas a Drupal 11. Migrar de CMS y actualizar de versión mayor a la vez es una de las formas más caras de abordar un proyecto. Y si tu tienda WooCommerce sigue con el almacenamiento de pedidos antiguo o con extensiones sin mantenimiento, el problema tampoco es la plataforma: es la deuda técnica acumulada.
WooCommerce: el estándar del mercado
WooCommerce sobre WordPress es la combinación más popular para ecommerce. Su mayor ventaja es el ecosistema gigante de plugins y themes, la facilidad de encontrar desarrolladores, y la documentación abundante. Para un ecommerce estándar (catálogo de productos, carrito, checkout, métodos de pago y envío), WooCommerce lo resuelve rápido y bien.
Dónde está su fuerza real
El argumento decisivo a favor de WooCommerce no es técnico, es económico. Casi cualquier requisito habitual de una tienda —suscripciones sencillas, reservas, cupones, multimoneda, facturación, conexión con una pasarela local, sincronización con un ERP de gama media— ya está resuelto por una extensión existente, con soporte y actualizaciones. Eso convierte semanas de desarrollo en horas de configuración.
A eso se suma que el equipo de marketing o de contenido probablemente ya sabe usar WordPress. La curva de aprendizaje para el cliente final es prácticamente nula, y eso reduce el coste oculto más caro de todos: el de que la plataforma acabe gestionada solo por el proveedor porque nadie más sabe tocarla.
Sus límites
Los problemas de WooCommerce rara vez aparecen el primer año. Aparecen cuando la tienda acumula veinte o treinta extensiones de proveedores distintos y cada actualización obliga a comprobar que nada se rompe. La flexibilidad vía plugins tiene un coste diferido en mantenimiento y en superficie de ataque, y ese coste crece de forma no lineal.
El segundo límite es de modelo de datos. Si tu negocio necesita que el precio dependa de una combinación de cliente, contrato, volumen y fecha, WooCommerce te obligará a resolverlo con desarrollo a medida sobre una estructura que no fue pensada para eso. Se puede hacer, pero deja de ser barato y deja de ser estándar, que era justo la ventaja por la que lo elegiste.
Cuándo es la respuesta obvia
Tienda B2C con catálogo convencional, presupuesto acotado, necesidad de salir al mercado pronto y un equipo interno que quiere autonomía para publicar y cambiar cosas. En ese cuadrante WooCommerce no tiene rival práctico dentro del open source. Si estás en la fase previa a esa decisión, te puede ayudar nuestra guía para elegir plataforma de ecommerce.
Drupal Commerce: potencia para lo complejo
Drupal Commerce brilla en escenarios que WooCommerce maneja con dificultad: modelos de precios complejos (por rol de usuario, por volumen, por fecha, por combinación de productos), flujos de checkout altamente personalizados, gestión de suscripciones con lógica de negocio elaborada, y sobre todo, cuando el ecommerce es solo una parte de un proyecto web más amplio con contenido editorial complejo.
El sistema de precios
Es probablemente la diferencia técnica más tangible. Drupal Commerce resuelve la resolución de precios mediante un sistema de resolvers encadenados: cada uno puede devolver un precio para un contexto determinado (cliente, cantidad, tienda, momento) y el sistema aplica el primero que responda. Añadir una regla nueva es implementar un servicio, no parchear un flujo existente.
En un B2B con tarifas por contrato, escalados por volumen y promociones que conviven entre sí, eso es la diferencia entre un desarrollo mantenible y una acumulación de excepciones. Es también la razón por la que muchos proyectos de distribución y de venta a profesionales acaban en Drupal Commerce aunque su catálogo sea pequeño.
Checkout y flujos a medida
El checkout de Drupal Commerce está definido como panes configurables dentro de un flujo, y puedes tener varios flujos distintos conviviendo en la misma tienda: uno para particulares, otro para clientes con crédito, otro para pedidos con validación previa. Reordenar, sustituir o condicionar pasos es configuración más código propio, no sobreescritura de plantillas de terceros.
Multi-idioma, multisitio y gobernanza
Drupal trata la traducción como parte del núcleo, no como una capa añadida, y lo mismo ocurre con el sistema de permisos. En proyectos con varios mercados, varios equipos editoriales y flujos de aprobación, esa diferencia se nota desde el primer mes. Si tu escenario es ese, tenemos un análisis específico en estrategias de Drupal multisite.
El precio a pagar
Todo lo anterior exige un equipo que conozca Drupal de verdad. Un proyecto de Drupal Commerce llevado por alguien que aprende sobre la marcha suele terminar con una arquitectura sobredimensionada, lenta y difícil de mantener. La plataforma no perdona la improvisación tanto como WooCommerce.
Gestión de contenido + ecommerce
Si tu proyecto combina un portal de contenido rico (blog, documentación técnica, área de miembros, centro de formación) con ecommerce, Drupal Commerce tiene ventaja. Drupal gestiona contenido estructurado mejor que WordPress, y Drupal Commerce está completamente integrado en el sistema de entidades de Drupal, permitiendo relaciones complejas entre contenido y productos.
Un ejemplo concreto
Imagina un fabricante que vende recambios y además publica manuales, despieces, vídeos de montaje y una zona privada para distribuidores. En Drupal, la ficha de producto puede referenciar directamente el manual, la familia de máquinas compatibles y el nivel de acceso del distribuidor, y las vistas se construyen sobre esas relaciones. En WooCommerce, cada una de esas piezas tiende a resolverse con un plugin distinto y la relación entre ellas hay que sostenerla a mano.
Cuando el contenido es marketing, no estructura
Ojo con el matiz: si el contenido de tu web es un blog de artículos y algunas landings, WordPress lo hace igual de bien o mejor, y más barato. La ventaja de Drupal aparece cuando el contenido tiene estructura, relaciones y reglas de acceso, no cuando simplemente hay mucho.
Rendimiento y escalabilidad
La discusión sobre rendimiento suele plantearse mal. Ninguna de las dos plataformas es lenta por naturaleza: lo que las hace lentas son las decisiones de implementación, el número de consultas por página y la ausencia de una estrategia de caché.
Dónde sufre cada una
WooCommerce sufre históricamente en tiendas con catálogos muy grandes, muchas variaciones y picos de pedidos simultáneos, sobre todo si arrastra extensiones que ejecutan consultas pesadas en cada carga. La migración del almacenamiento de pedidos a tablas propias ha mejorado mucho ese punto, pero sigue siendo determinante mantener el número de plugins bajo control.
Drupal parte con una infraestructura de caché más sofisticada —cache tags, contextos, BigPipe— que permite invalidar exactamente lo que cambia en lugar de tirar la caché entera. La contrapartida es que hay que entenderla: una implementación que ignore los contextos de caché puede acabar sirviendo contenido incorrecto o no cacheando nada. Lo desarrollamos en optimización de rendimiento en Drupal.
El factor que más pesa
En la práctica, el hosting y la arquitectura de caché explican más diferencias de rendimiento que la elección de plataforma. Una tienda WooCommerce bien alojada, con object cache y CDN, rinde mejor que una Drupal Commerce mal configurada, y al revés. Antes de cambiar de plataforma por rendimiento, merece la pena una auditoría técnica que mida dónde se va realmente el tiempo.
Coste y talento disponible
Aquí WooCommerce gana claramente. Encontrar desarrolladores WooCommerce es relativamente fácil y económico. Los desarrolladores Drupal Commerce son más escasos y caros. El ecosistema de módulos contribuidos para Drupal Commerce es mucho menor que el de plugins WooCommerce. Esto impacta directamente en los costes y tiempos de desarrollo.
Coste de arranque frente a coste de propiedad
La comparación honesta no es la del presupuesto inicial, sino la del coste a tres años. WooCommerce arranca más barato casi siempre, pero suma licencias anuales de extensiones, tiempo de compatibilidad en cada actualización y, en tiendas que crecen, desarrollo a medida para cubrir lo que ninguna extensión resuelve. Drupal Commerce arranca más caro y con menos coste recurrente de licencias, pero depende de un perfil de equipo más escaso.
Riesgo de dependencia
El riesgo de proveedor también se reparte distinto. Con WooCommerce dependes de muchos autores de extensiones: si uno abandona su plugin, tienes un problema acotado pero real. Con Drupal Commerce dependes sobre todo de tu equipo o de tu partner: menos piezas de terceros, pero más concentración. Ninguna de las dos situaciones es mejor por sí misma; conviene decidirla a conciencia.
Una regla práctica
Si el desarrollo a medida previsible supera aproximadamente un tercio del proyecto, la ventaja de coste de WooCommerce se diluye y merece la pena evaluar Drupal Commerce en serio. Por debajo de ese umbral, difícilmente compensa. Esta misma frontera la analizamos en desarrollo a medida frente a plataforma de ecommerce.
Seguridad y mantenimiento
Las dos plataformas tienen un historial de seguridad razonable en el núcleo. La diferencia está en la periferia. La inmensa mayoría de incidentes en WooCommerce llegan por plugins desactualizados o abandonados, no por WooCommerce en sí; en Drupal, el equipo de seguridad publica avisos coordinados y los módulos sin mantenimiento se marcan explícitamente como no soportados, lo que hace más difícil arrastrarlos sin enterarte.
Sea cual sea la elección, el factor decisivo es el mismo: un proceso de actualización regular con entorno de pruebas y copias verificadas. Una tienda sin ese proceso acaba comprometida independientemente de la plataforma. Si estás empezando a poner orden en esto, nuestro post sobre por dónde empezar en ciberseguridad de empresa es un buen punto de partida, y para proyectos con requisitos formales conviene mirar la certificación ISO 27001.
En proyectos con exigencias de accesibilidad o de protección de datos, Drupal parte con ventaja por su enfoque de cumplimiento integrado; lo tratamos en accesibilidad web y GDPR en Drupal.
Integraciones y arquitectura headless
Casi ningún ecommerce vive aislado: hay un ERP, un CRM, un sistema logístico, una pasarela de pago y alguna herramienta de analítica. Ese conjunto de integraciones suele condicionar la elección más que las funcionalidades de tienda.
Cómo se resuelve en cada una
WooCommerce expone una API REST completa y tiene conectores comerciales para prácticamente cualquier ERP conocido. Drupal ofrece JSON:API en el núcleo y un modelo de datos más limpio para exponer, lo que facilita integraciones bidireccionales complejas sin capas intermedias. Cuando la integración implica mapear entidades relacionadas y no solo volcar pedidos, la diferencia se nota.
Cuándo tiene sentido desacoplar
Si el plan pasa por un frontend en React o Next.js con el CMS como backend de contenido y catálogo, Drupal está más preparado de serie. Conviene, eso sí, no desacoplar por moda: el coste de mantener dos aplicaciones solo se justifica cuando hay una razón real de producto. Lo argumentamos en cuándo desacoplar el frontend en Drupal y en integraciones API entre ecommerce, ERP, logística y pagos.
Errores frecuentes al elegir
Después de bastantes proyectos, los fallos se repiten con una regularidad sospechosa:
- Elegir por el catálogo de hoy y no por el modelo de negocio de dentro de dos años. El catálogo casi nunca es el problema; las reglas de precio y los flujos sí.
- Comprar potencia que no se va a usar. Montar Drupal Commerce para una tienda de cien referencias con precio único es pagar flexibilidad que nunca se ejercerá.
- Subestimar el mantenimiento en WooCommerce. Treinta extensiones activas son treinta dependencias que hay que vigilar.
- Migrar de plataforma para arreglar un problema de rendimiento que en realidad era de hosting, de caché o de una consulta mal escrita.
- Ignorar quién va a gestionar la tienda. Si el equipo interno no puede tocar nada sin llamar al proveedor, el coste real se dispara con el tiempo.
Si lo que estás valorando es un cambio de plataforma y no un proyecto nuevo, merece la pena revisar antes nuestra guía de migración entre plataformas de ecommerce: la mayoría de los sustos de una migración son de datos y de SEO, no de tecnología.
Nuestra recomendación
Para el 80% de los proyectos ecommerce, WooCommerce es la opción correcta. Elige Drupal Commerce cuando tu proyecto requiera gestión de contenido compleja junto con ecommerce, cuando necesites modelos de negocio no estándar, o cuando ya tengas una inversión significativa en Drupal y quieras añadir capacidades de venta.
Dicho de otra forma: WooCommerce es la opción por defecto y Drupal Commerce es la opción justificada. Si no eres capaz de explicar en una frase por qué tu proyecto necesita Drupal Commerce, probablemente no lo necesite. Y si sí puedes explicarlo —precios por contrato, contenido estructurado que se relaciona con el catálogo, varios mercados con gobernanza distinta—, entonces intentar forzar WooCommerce te saldrá más caro a medio plazo que asumir el coste de talento de Drupal.
Un último apunte de calendario: con Drupal 10 llegando a fin de soporte en diciembre de 2026, cualquier decisión sobre un proyecto Drupal existente debería incluir la actualización a Drupal 11 dentro del mismo plan, no como una fase posterior indefinida.
🚀 ¿Tu proyecto Drupal necesita un impulso?
En Keliam trabajamos con Drupal desde hace años en proyectos de alta exigencia. Si buscas un partner técnico para migraciones, desarrollo de módulos o arquitectura headless, estamos aquí.
- Desarrollo y Mantenimiento Drupal — tu partner Drupal de confianza
- Auditoría Técnica Web — análisis de rendimiento y arquitectura
- Mantenimiento Web — soporte continuo para tu plataforma
Preguntas frecuentes
¿Se puede migrar de WooCommerce a Drupal Commerce sin perder el SEO?
Sí, siempre que se planifique el mapa de redirecciones 301 antes de tocar nada y se conserve la estructura de URLs siempre que sea posible. El riesgo de una migración no está en mover productos y pedidos, sino en perder el histórico de posicionamiento por no mapear rutas antiguas.
¿Drupal Commerce es más seguro que WooCommerce?
El núcleo de ambos es sólido. La diferencia real está en la superficie expuesta: una tienda WooCommerce con muchas extensiones de terceros tiene más puntos de fallo que una implementación Drupal con pocos módulos contribuidos. Con un proceso de actualizaciones serio, ambas se mantienen seguras.
¿Qué pasa si mi tienda está en Drupal 10?
Drupal 10 deja de recibir soporte el 9 de diciembre de 2026. Si tu tienda sigue en esa rama, la prioridad es planificar la actualización a Drupal 11 junto con el salto a Drupal Commerce 3.x, antes que plantearse un cambio de plataforma.
¿Cuál escala mejor para muchos pedidos?
Ambas escalan si la arquitectura acompaña. WooCommerce ha mejorado mucho con el almacenamiento de pedidos en tablas propias, y Drupal parte con un sistema de caché más granular. En la práctica, el hosting, la caché de objetos y la CDN determinan el resultado más que la plataforma.
¿Puedo usar WordPress para el contenido y Drupal Commerce para la tienda?
Técnicamente sí, pero rara vez compensa: mantener dos CMS supone duplicar actualizaciones, entornos y equipo. Solo tiene sentido cuando ya existen ambas plataformas en la organización y hay una razón organizativa clara para mantenerlas separadas.
