Este artículo se publicó cuando la iniciativa Starshot era todavía una promesa. Desde entonces ha pasado lo más importante: Starshot dejó de ser un nombre en clave, se lanzó como Drupal CMS el 15 de enero de 2025 y ya va por su segunda versión mayor. Y por delante hay una fecha que ningún responsable de un sitio Drupal debería ignorar: Drupal 10 deja de tener soporte el 9 de diciembre de 2026. Hemos actualizado el texto con el estado real a día de hoy.
Drupal renace con la versión 11 y la iniciativa Starshot
Drupal ha sido históricamente la opción para proyectos web complejos y de gran escala, pero perdió cuota de mercado frente a WordPress en el segmento medio. Con Drupal 11 y la iniciativa Starshot, la comunidad está haciendo un esfuerzo serio por volver a ser relevante para un público más amplio sin perder su potencia enterprise.
Una precisión de nomenclatura, porque genera confusión constante: Starshot era el nombre en clave del proyecto. El producto final se llama Drupal CMS, y conviven dos cosas distintas bajo la misma marca: Drupal core, el framework de siempre, y Drupal CMS, una distribución construida encima y pensada para que alguien sin experiencia técnica levante un sitio desde el navegador.
Dónde está Drupal a finales de 2026
El calendario es la parte con consecuencias prácticas más inmediatas, así que va primero.
Drupal 11 se publicó el 2 de agosto de 2024. Su rama menor más reciente en producción es la 11.4, liberada la semana del 29 de junio de 2026; la 11.5 entró en fase beta en septiembre de 2026, a la vez que la primera beta de Drupal 12.
Drupal 12 está previsto para la semana del 7 de diciembre de 2026. Elevará el mínimo de PHP a la 8.5 y saltará a Symfony 8. En la práctica, y siguiendo el patrón de las últimas versiones, actualizar de la 11 a la 12 debería ser un trámite para un sitio con las dependencias al día, porque el trabajo duro consiste en retirar código marcado como obsoleto antes del salto, no después.
Drupal 10 llega a su fin de vida el 9 de diciembre de 2026, justo cuando aparece la 12. A partir de esa fecha no habrá más parches de seguridad para la rama 10. Si hay un sitio corporativo o de administración pública todavía en Drupal 10, la ventana para planificar la migración con calma se está cerrando: no es una recomendación de estilo, es una exposición de seguridad con fecha.
Starshot: Drupal para el resto del mundo
Drupal Starshot es una distribución oficial que viene preconfigurada con un page builder visual, templates profesionales, y una experiencia de instalación simplificada. El objetivo es que un usuario sin experiencia técnica pueda montar un sitio profesional sin tocar código, algo que hasta ahora era territorio exclusivo de WordPress.
Qué ha pasado con esa promesa
Se cumplió en plazo. Drupal CMS 1.0 salió el 15 de enero de 2025 y la línea ha seguido avanzando: la versión 2.2, publicada el 25 de septiembre de 2026, se centró en las capacidades multilingües, que es precisamente uno de los terrenos donde Drupal siempre ha sido más fuerte que la competencia.
Las piezas que sostienen el producto son cuatro: las Recipes (configuración empaquetada y reproducible), el Project Browser para descubrir e instalar módulos desde el navegador sin pasar por Composer, las actualizaciones automáticas, y el constructor visual de páginas, que nació como Experience Builder y hoy se llama Drupal Canvas. Hay además una iniciativa de IA con su propio recorrido y un marketplace de plantillas de sitio.
La pregunta práctica: ¿cuál de los dos instalar?
Nuestra regla es sencilla. Si el sitio lo va a mantener gente de negocio y el modelo de contenido es razonablemente convencional (páginas, noticias, eventos, casos de éxito), Drupal CMS ahorra semanas de configuración inicial. Si el proyecto tiene un modelo de datos propio, integraciones a medida o una arquitectura headless, Drupal core sigue siendo el punto de partida limpio.
Lo relevante es que la decisión no cierra puertas: comparten núcleo. Se puede empezar por Drupal CMS y añadir código propio cuando aparezca la necesidad, sin migrar de plataforma.
Novedades técnicas de Drupal 11
Drupal 11 trae mejoras importantes: requiere PHP 8.3 mínimo, actualización a Symfony 7, mejor rendimiento de caché, mejoras en el sistema de recetas (Recipes) para compartir configuraciones, y la adopción de componentes de UI modernos basados en Web Components. El sistema de layouts y bloques también se ha simplificado significativamente.
Qué implica en la práctica el salto de PHP
El requisito de PHP 8.3 es, con diferencia, lo que más proyectos bloquea. No por Drupal en sí, sino por los módulos contribuidos antiguos y por el código a medida acumulado durante años, que suele arrastrar construcciones que PHP 8 ya no tolera. Antes de plantear cualquier actualización conviene pasar el análisis estático sobre el código propio: en la mayoría de los casos que hemos visto, el 80% de los problemas están en un puñado de módulos custom que nadie ha tocado en cuatro años. Si el proyecto no tiene ese diagnóstico hecho, una auditoría de código antes de la migración suele salir mucho más barata que la migración a ciegas.
La política de obsolescencia es el verdadero cambio cultural
Desde Drupal 8, el proyecto mantiene una promesa que conviene entender: el código que funciona en la última versión menor de una rama, sin usar APIs marcadas como obsoletas, funciona en la siguiente versión mayor. Eso convierte la actualización mayor en un trabajo de limpieza continuo en lugar de una reconstrucción cada cinco años, que era exactamente el trauma de Drupal 7 a Drupal 8. La contrapartida es que exige disciplina: un sitio que ignora los avisos de obsolescencia durante dos años vuelve a encontrarse con un proyecto grande delante.
Recipes: configuración como código
El sistema de Recipes es una de las innovaciones más interesantes. Permite compartir y aplicar paquetes de configuración de Drupal de forma reproducible. Algo así como los Composer packages pero para configuración del CMS. Esto facilita enormemente la creación de instalaciones estándar para agencias y la replicación de funcionalidades entre proyectos.
Por qué esto importa más de lo que parece
Cualquiera que haya montado varios sitios Drupal reconoce el patrón: las primeras dos semanas de cada proyecto se van en repetir la misma configuración de tipos de contenido, roles, flujos de publicación, formularios de contacto y SEO básico. Una receta convierte ese trabajo en algo que se aplica con un comando y, sobre todo, en algo que se versiona y se revisa como el código.
Hay un matiz que conviene conocer: una receta se aplica una vez y deja de estar «viva». No es un módulo del que el sitio dependa para siempre, sino un punto de partida que después el proyecto puede modificar libremente. Eso evita el problema clásico de las distribuciones de Drupal, que ataban el sitio a decisiones ajenas durante todo su ciclo de vida.
¿Para quién es Drupal en 2026?
Drupal sigue siendo la mejor opción para proyectos con requisitos complejos de contenido: universidades, gobiernos, medios de comunicación, y organizaciones que necesitan gestionar miles de tipos de contenido con workflows de publicación elaborados. Con Starshot, también compite para sitios corporativos de tamaño medio que necesitan más estructura que WordPress.
Las tres señales que a nosotros nos hacen recomendar Drupal
La primera es el modelo de contenido: si el sitio tiene más de diez tipos de contenido relacionados entre sí, con campos que se reutilizan y vistas que los cruzan, Drupal lo resuelve de serie donde otros CMS necesitan capas de plugins.
La segunda son los permisos: cuando hay varias redacciones, revisores, aprobadores y una separación real entre quien escribe y quien publica, el sistema de roles y permisos granulares de Drupal no tiene equivalente directo.
La tercera es el multiidioma. Drupal trata el idioma como una propiedad del contenido y de la configuración desde el núcleo, no como un añadido. En proyectos con cuatro o cinco lenguas y traducciones parciales, la diferencia de esfuerzo es de meses.
Drupal en el sector público: ENS, accesibilidad y licitaciones
Buena parte del peso de Drupal en España está en administraciones y organismos públicos, y ahí las razones para elegirlo no son solo técnicas. Un portal público tiene que cumplir el Esquema Nacional de Seguridad, acreditar accesibilidad y, con frecuencia, salir a concurso. Drupal juega bien en esos tres frentes: es software libre (sin coste de licencia que justificar en un pliego), tiene trazabilidad de versiones y parches de seguridad documentados, y su compromiso con la accesibilidad viene de serie en el núcleo.
Sobre accesibilidad conviene recordar que desde junio de 2025 la Ley Europea de Accesibilidad amplía las obligaciones más allá del sector público, y afecta a bastantes sitios privados que hasta ahora se consideraban al margen: lo desglosamos en la guía sobre accesibilidad web y la EAA. Y si el proyecto va a presentarse a un concurso público, el problema rara vez es el CMS: es la documentación. Lo tratamos en el artículo sobre licitaciones de tecnología para pymes.
Drupal vs WordPress en 2026
La elección entre Drupal y WordPress ya no es tan clara como antes. WordPress con Gutenberg se acerca a las capacidades de edición de Drupal, mientras que Drupal con Starshot se acerca a la facilidad de WordPress. La diferencia clave sigue siendo la gestión de contenido estructurado y los permisos granulares, donde Drupal sigue siendo superior.
Dónde ha quedado cada uno
Los dos proyectos se han movido hacia el centro y siguen sin encontrarse del todo. WordPress ha seguido apostando por la edición visual y, en sus versiones más recientes, por integrar asistencia de IA en el propio escritorio; lo repasamos en la guía de actualización a WordPress 7 para empresas y en el análisis de las novedades de IA de WordPress 7.1. Drupal ha ido por el otro lado: empaquetar su potencia para que no haga falta un desarrollador para arrancar.
El criterio con el que decidimos, cuando un cliente nos lo pregunta sin condicionantes previos, es dónde va a estar el esfuerzo dentro de tres años. Si el sitio va a crecer sobre todo en volumen de contenido publicado por perfiles no técnicos, WordPress sale ganando por ecosistema y por coste de perfiles. Si va a crecer en complejidad de modelo, integraciones y reglas de publicación, cada año que pase Drupal se verá mejor. Y si ya hay un equipo formado en una de las dos, ese factor pesa más que casi cualquier comparativa técnica.
El coste real no está en la licencia
Ninguno de los dos cuesta dinero de licencia y los dos cuestan dinero de mantenimiento. En Drupal el gasto se concentra en menos partidas pero más caras: perfiles con experiencia específica y actualizaciones mayores planificadas. En WordPress se reparte en muchas partidas pequeñas: plugins de pago, revisiones de compatibilidad y una superficie de ataque mayor por la cantidad de extensiones instaladas. Comparar solo el coste de arranque es la forma más habitual de equivocarse.
Drupal headless: cuándo tiene sentido
Drupal expone sus contenidos por JSON:API desde el núcleo, sin módulos adicionales, lo que lo convierte en un backend de contenidos perfectamente razonable para un frontend desacoplado. La pregunta no es si se puede, es si compensa.
Compensa cuando hay varios consumidores del mismo contenido (web, aplicación móvil, pantallas, otro sistema interno), cuando el frontend tiene requisitos de interactividad que no encajan con el renderizado clásico, o cuando el equipo de frontend ya trabaja con un stack propio y separar los ciclos de entrega es una ventaja organizativa.
No compensa cuando el consumidor es un único sitio web bastante convencional: ahí se duplica la infraestructura, se pierde la previsualización cómoda para los editores y se añade un proyecto entero de frontend que hay que mantener. Si el motivo para desacoplar es el rendimiento, casi siempre sale más barato arreglar la caché. Para la parte de elección de frontend, comparamos las opciones en la guía de frameworks frontend.
Cuánto dura y qué cuesta migrar de Drupal 10 a Drupal 11
Es la pregunta que llega siempre después de ver el calendario, y la respuesta honesta es que depende casi por completo de una sola variable: cuánto código a medida tiene el sitio y en qué estado está.
Un sitio construido con módulos contribuidos bien mantenidos, un tema estándar y poco código propio se actualiza en días, no en meses: se suben las dependencias con Composer, se ejecutan las actualizaciones de base de datos y se prueba. El grueso del trabajo es de verificación, no de desarrollo.
Un sitio con quince módulos a medida escritos en épocas distintas, un tema heredado y módulos contribuidos abandonados por sus mantenedores es otra historia. Ahí el trabajo real no es actualizar Drupal: es decidir qué se conserva, qué se reescribe y qué se sustituye por funcionalidad que hoy ya viene en el núcleo. Esa decisión exige inventario previo, y es donde se va la mayor parte del presupuesto.
Los tres pasos que recomendamos antes de pedir presupuesto
Primero, inventario de módulos: cuáles tienen versión compatible con Drupal 11, cuáles están abandonados y cuáles han sido absorbidos por el núcleo (unos cuantos lo han sido, y quitarlos reduce trabajo en lugar de añadirlo).
Segundo, análisis de obsolescencia sobre el código propio, con las herramientas estándar del ecosistema. El resultado es una lista concreta de ficheros y líneas, no una estimación al aire, y convierte la conversación de presupuesto en algo verificable.
Tercero, comprobar el hosting: PHP 8.3 para Drupal 11 y PHP 8.5 para la 12. No es raro que el proveedor sea el cuello de botella real y que nadie lo haya mirado hasta el día de la migración.
Con esas tres cosas hechas, el riesgo del proyecto baja muchísimo. Sin ellas, cualquier plazo que te den es una apuesta.
¿Tu proyecto Drupal necesita un impulso?
En Keliam trabajamos con Drupal desde hace años en proyectos de alta exigencia. Si tienes un sitio en Drupal 10 y diciembre de 2026 se acerca, o 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 — diagnóstico antes de migrar de versión mayor
- Servicios IT — soporte continuo para tu plataforma
Preguntas frecuentes
¿Starshot y Drupal CMS son lo mismo?
Sí. Starshot era el nombre en clave de la iniciativa; el producto se llama Drupal CMS y su versión 1.0 se publicó el 15 de enero de 2025.
¿Cuándo deja de tener soporte Drupal 10?
El 9 de diciembre de 2026, la misma semana en que se publica Drupal 12. A partir de esa fecha no se publican más actualizaciones de seguridad para la rama 10.
¿Se puede saltar de Drupal 10 directamente a Drupal 12?
No. La política del proyecto no permite saltarse versiones mayores: hay que pasar por Drupal 11 y, ya en la última versión menor de esa rama y sin código obsoleto, dar el salto a la 12.
¿Qué versión de PHP hace falta?
Drupal 11 exige PHP 8.3 como mínimo. Drupal 12 subirá ese mínimo a PHP 8.5, así que conviene comprobar qué ofrece el proveedor de hosting antes de planificar el calendario de migración.
¿Merece la pena migrar de WordPress a Drupal?
Rara vez solo por la tecnología. Merece la pena cuando el modelo de contenido o los flujos de publicación se han vuelto ingobernables con plugins, o cuando hay requisitos de multiidioma o de permisos que no se están cubriendo. Migrar un sitio que funciona bien es casi siempre una mala inversión.
Conclusión
La lectura de 2026 es más favorable a Drupal que la de 2025, y no por marketing: la promesa de Starshot se cumplió en forma de producto con versiones reales, el ciclo de actualizaciones mayores ha dejado de ser traumático y las Recipes resuelven un problema concreto que todas las agencias conocían.
Dicho eso, lo urgente ahora mismo no es evaluar si Drupal vuelve a ser relevante, sino mirar en qué versión está tu sitio. Diciembre de 2026 marca a la vez el nacimiento de Drupal 12 y el final del soporte de Drupal 10, y esa segunda fecha es la que trae consecuencias si llega sin un plan detrás.
