Ocho meses: Drupal acorta el soporte y tu web ya no puede esperar un año

Estos días estoy migrando varias webs de Drupal 10 a Drupal 11. Ninguna es especialmente complicada, pero todas llevan su tiempo. Y en medio de eso me encuentro con el PSA-2026-11-02, en el que el equipo de seguridad de Drupal anuncia que va a recortar el soporte de cada versión menor.

Leído así puede parecer un cambio técnico más, de esos que solo interesan a quien sigue el issue queue. Pero afecta directamente a cuánto tiempo puedes tener una web sin tocar antes de quedarte sin parches de seguridad, y ese tiempo acaba de bajar bastante.

De doce meses a ocho

Desde Drupal 8.6, allá por 2018, cada versión menor de core tenía 12 meses de soporte de seguridad. Como sale una menor nueva cada seis meses, eso te daba medio año de margen para pasar de una a la siguiente. Cómodo. Tan cómodo que mucha gente se acostumbró a actualizar una vez al año, o cuando se acordaba.

A partir de 2027 pasan a ser 8 meses: seis de corrección de bugs y dos más solo de seguridad. El calendario queda así:

Si haces las cuentas, la conclusión es sencilla. Cuando sale una menor nueva, la anterior solo tiene dos meses de vida por delante. Dos meses para probar, actualizar y desplegar. Si en ese tiempo no lo has hecho, estás fuera de soporte.

Lo que no cambia es el compromiso con las versiones mayores: cada una sigue teniendo al menos cuatro años de soporte. Drupal 11 llega hasta diciembre de 2028 y Drupal 12 hasta diciembre de 2030. Pero dentro de cada mayor, el ritmo ahora es mucho más exigente.

Por qué lo hacen

El motivo que da el equipo de seguridad es la IA. Hablan literalmente de un "tsunami" de reportes de seguridad generados con herramientas de IA, que con la financiación actual no pueden absorber. Cada versión que mantienen con soporte es una rama más a la que hay que hacer backport de cada parche, y recortar la ventana les ahorra, según sus cálculos, un 30 % de ese trabajo. De paso, el calendario encaja mejor con el de Symfony.

El propio aviso reconoce el riesgo para quienes tenemos webs: que los parches tarden más en salir, justo cuando los atacantes también usan LLMs para buscar fallos.

No es algo exclusivo de Drupal. Ya escribí hace unos días sobre cómo cada miércoles se ha convertido en un pequeño Drupalgeddon, y lo mismo está pasando con PHP, con el kernel de Linux y con prácticamente cualquier software que tenga cierta superficie de ataque. Este PSA es la otra cara de esa moneda. Hay tantos fallos encontrándose a la vez que los equipos de seguridad tienen que elegir qué pueden mantener, y la respuesta es: menos versiones, durante menos tiempo.

Y Drupal 10 se acaba el 9 de diciembre

Por si faltaba algo, Drupal 10 llega al final de su vida el 9 de diciembre de 2026. A partir de ahí no habrá más releases, tampoco de seguridad. Esa misma semana sale Drupal 12, que además pide PHP 8.5 como mínimo.

Si tienes una web en Drupal 10, el salto que toca ahora es a Drupal 11, que tiene soporte hasta finales de 2028. Y te lo digo desde lo que estoy haciendo estos días: no es una migración difícil, nada que ver con lo que fue salir de Drupal 7. Pero lleva tiempo, y cuánto depende casi por completo de cómo se ha mantenido la web hasta ahora.

Lo que más tiempo me está llevando no es core. Es todo lo que hay alrededor:

• Código custom que sigue usando APIs deprecadas desde hace dos o tres versiones y que nadie actualizó porque "funcionaba".
• Módulos contribuidos que se quedaron en una versión antigua y ahora hay que subir varias de golpe, con sus cambios de configuración y sus update hooks.
• Algún módulo que no tiene versión compatible con Drupal 11, o que directamente está abandonado, y hay que decidir si se parchea, se sustituye o se reescribe.
• Parches en el composer.json que ya no aplican contra la versión nueva.
• El salto de PHP en el servidor, que en algunos hostings no es tan inmediato como debería.

Upgrade Status y Drupal Rector ayudan mucho, pero no hacen milagros. Una web que se ha ido manteniendo al día llega a la migración con la mitad del trabajo hecho. Una que lleva dos años sin tocar llega con todo acumulado.

Una web también necesita mantenimiento

Siempre digo que una web es casi un ser vivo. Si no le das un poco de cariño de forma regular, acaba dando problemas. Aunque quizá la comparación más justa es con cualquier infraestructura: nadie espera que una carretera o una vía de tren aguanten veinte años sin que nadie las revise.

Quien viva en España sabe de qué hablo, porque este año lo hemos visto con los trenes. Entre los accidentes de enero en Adamuz y en Rodalies y los retrasos que en muchas líneas se han vuelto rutina, el mantenimiento de la red ferroviaria ha estado en todas las conversaciones. Las causas concretas las dirán las investigaciones, pero hay un dato que da que pensar: según Eurostat, en 2024 España dedicó al mantenimiento el 15,8 % de su inversión ferroviaria, el porcentaje más bajo desde 2016.

No quiero frivolizar con algo en lo que ha muerto gente, y una web caída no se puede comparar con eso. Pero el mecanismo de fondo es parecido. El mantenimiento no se ve ni sale en ninguna foto. Recortar ahí durante un tiempo no tiene consecuencias visibles, y por eso es tan tentador. El problema es que el deterioro se va acumulando en silencio, y cuando por fin se nota, arreglarlo cuesta mucho más que haberlo mantenido.

Con una web pasa lo mismo, a otra escala. Cuanto menos inviertes en mantenimiento, más probabilidades hay de que un día tengas un problema serio: una vulnerabilidad que no parcheaste porque estabas fuera de soporte, una actualización que hay que hacer con prisas y rompe media web, o una migración que se convierte en un proyecto de meses.

Qué debería entrar en el presupuesto

Si tienes una web en Drupal, o estás pensando en hacerte una, el mantenimiento tiene que estar en el presupuesto desde el principio. No como algo que se hace "si sobra", sino como un coste fijo, igual que el hosting.

Con el nuevo calendario, ese mantenimiento debería cubrir como mínimo:

• Actualizaciones de core en cuanto salen, y el salto de versión menor dentro de esos dos meses de margen. Dos veces al año, sin excusas.
• Actualizaciones de módulos contribuidos, que también publican avisos de seguridad cada semana y que, si se dejan atrás, son los que más duelen después.
• El código custom al día, quitando deprecaciones a medida que aparecen. Es lo que hace que el salto a la siguiente versión mayor sea cuestión de días y no de meses.
• El servidor: versión de PHP, base de datos y sistema operativo. De poco sirve tener Drupal al día sobre un PHP sin soporte.

Nada de esto es especialmente caro si se hace con regularidad. Lo caro es hacerlo todo de golpe cada tres años, normalmente con prisas porque se acaba el soporte o porque ha salido una vulnerabilidad crítica.

Si alguien duda de si hace falta pagar mantenimiento cada mes para una web que "ya está hecha", yo le daría la vuelta a la pregunta: ¿cuánto te costaría tener la web parada una semana, o rehacerla porque se ha quedado tan atrás que actualizarla ya no compensa?

Y si tu web sigue en Drupal 10, ya no hay mucho que pensar. Quedan cinco semanas.