Drupal 10 pierde el soporte el 9 de diciembre de 2026: migra a Drupal 11.4 con Composer y update.php, sin saltarse todavía a Drupal 12.
Qué cambia el 9 de diciembre de 2026
La serie 10.6 es el último minor de Drupal 10 y el 9 de diciembre de 2026 deja de recibir correcciones de seguridad: cualquier vulnerabilidad reportada después queda sin parche oficial. Esa ventana coincide con la liberación prevista de Drupal 12.0.0 y Drupal 11.5.0, este último como rama de soporte largo, y la 11.3 deja de soportarse en paralelo.
Ese Drupal 12.0.0 todavía está en alpha (la alpha 1 salió el 2 de septiembre de 2026), así que no es opción de producción hoy. La ruta corta es 11.4: se publicó el 1 de julio de 2026 y recibe soporte de seguridad hasta junio de 2027. Instalar la rama soportada ahora compra casi un año de parches y hace que el salto a 12 sea un proyecto con un solo minor de por medio.
Las fechas están en el calendario oficial de ciclos de Drupal y en el anuncio de Drupal 11.4.0. Conviene tenerlos como referencia permanente, no como un pendiente para diciembre.
El punto de partida tiene dos requisitos duros: el sitio debe estar en Drupal 10.3.0 o superior, porque todas las actualizaciones anteriores a 10.3.0 se eliminaron en Drupal 11, y debe correr con PHP 8.3 o superior. Si el hosting sigue en PHP 8.1 u 8.2, eso se resuelve antes de tocar el código, no durante la migración.
Inventario previo: lo que define la duración del proyecto
Antes de cambiar una restricción en composer.json hay que saber qué hay adentro. Este inventario convierte "actualizar el sitio" en algo cotizable y no en una sorpresa.
Lista real de dependencias
El primer paso no es un comando de actualización, es una lectura:
composer show --direct
composer outdated "drupal/*"
Con esa salida arma una hoja de trabajo en un archivo del repositorio: módulo o tema, versión instalada, si tiene release para Drupal 11 y quién lo usa en el sitio. Los contributed son el riesgo principal de la migración, no el core.
Módulos contributed sin versión para Drupal 11
Para cada dependencia directa, revisa la pestaña de versiones compatibles de su proyecto en drupal.org. Si no hay release para Drupal 11, hay tres salidas, y cada módulo debe quedar con una decisión escrita:
- Hay maintainer activo y hay un parche abierto: se prueba en desarrollo, con el riesgo acotado.
- No hay release ni parche: se reemplaza. Suele pasar con proyectos viejos o de un solo autor. Se busca sustituto o se reescribe la funcionalidad en código propio pequeño, cotizado aparte.
- El módulo no se usa en el sitio: se desinstala, pero primero se verifica que ningún template, content type o vista lo use. Desinstalar a la fuerza deja configuración y tablas que después hay que limpiar a mano.
Además, Drupal 11 movió a contrib varios módulos del core, entre ellos Tour, Statistics, Book y Forum. La recomendación oficial es instalar la versión contrib antes de actualizar, no desinstalar después, porque desinstalar elimina la configuración del módulo.
El módulo Upgrade Status automatiza buena parte de esta revisión y marca en el reporte de estado lo que quedó obsoleto. Se instala con composer require drupal/upgrade_status en el entorno de desarrollo.
Código propio y parches
Los parches en patches/ son la fuente clásica de problemas al cambiar de rama: muchos aplican sobre el diff del core y se rompen al pasar de la 10 a la 11. Revísalos uno a uno contra el core nuevo.
git -C /var/www/drupal log --oneline -- patches
git -C /var/www/drupal status
Si un parche ya no aplica, se reescribe. Si el código que parchea era un workaround de una versión vieja, muchas veces la respuesta correcta es borrarlo.
Los pasos de la actualización, de 10.6 a 11.4
1. Respaldo verificado
Copia de base de datos y de archivos, más un smoke test de cinco URLs críticas: home, un content type, el formulario de contacto y un nodo de prueba. Un respaldo que nunca se restauró no es un respaldo.
drush archive:dump
2. Última 10.x con parches de seguridad
Lleva el sitio al último patch de la 10.6 antes de cambiar de major. Si algo falla aquí, la causa está en la 10 y es más barato diagnosticarla.
composer update "drupal/core-*" --with-all-dependencies
drush updatedb
drush cache:rebuild
3. Salto a Drupal 11 con Composer
La guía oficial de actualización de Drupal 10 a 11 pide cambiar las restricciones de los paquetes del core, no solo las de drupal/core:
composer require 'drupal/core-recommended:^11' \
'drupal/core-composer-scaffold:^11' \
'drupal/core-project-message:^11' --no-update
La 11.4 agrega symfony/runtime como dependencia, y es un plugin de Composer que hay que autorizar explícitamente:
composer config allow-plugins.symfony/runtime true
composer require drush/drush --no-update
composer update "drupal/core-*" --with-all-dependencies
Si drupal/core está declarado explícitamente en el composer.json, hay que quitarlo antes: composer remove drupal/core --no-update.
4. Base de datos, caché y configuración
El core sí actualiza el código con Composer, pero las actualizaciones de base de datos que requieren migración las dispara update.php, y no se deben saltar. Se puede correr por Drush o desde el navegador en https://sitio/update.php (o /core/update.php si no hay URLs limpias).
drush updatedb:status
drush updatedb
drush cache:rebuild
drush config:status
Si config:status reporta cambios esperados, revísalos uno a uno antes de importarlos. En producción lo recomendable es copiar el composer.json y el composer.lock desde desarrollo y correr composer install --no-dev, no composer update.
Cuánto tiempo toma según el tipo de sitio
Estos son los rangos que se sostienen en la práctica, por tipo de proyecto:
- Sitio corporativo o brochure: 2 a 3 semanas. Pocos módulos, mucho contenido estático, tema basado en contrib. Lo típico es una semana de desarrollo y una de pruebas.
- Sitio con contenido dinámico, varias vistas y varios editores: 3 a 4 semanas. El tiempo se lo comen los módulos de edición, los de SEO y los temas que dependen de deprecations del core.
- E-commerce, portal con formularios o integraciones: 4 a 6 semanas. Aquí el cronómetro lo definen los parches: cada uno que hay que reescribir suma días.
- Multisitio: seis semanas o más. Cada sitio es un caso, aunque compartan el core.
La variable que más mueve la aguja no es el core, sino la cantidad de parches propios y de módulos contributed sin release para Drupal 11.
Verificación final y siguiente salto
Lista corta para el día del corte, siempre en el mismo orden:
- Ingreso al admin y permisos. Los cambios de roles son los que más se olvidan y los que más duelen.
- Formularios de envío. Un contacto que no llega es un fallo silencioso: pruébalo con un envío real.
- Correo saliente (SMTP). Confirma que sale y que llega.
- Buscador. Si usas Search API o Solr, reindexa:
drush search-api:reindex. - Reglas de reescritura de URLs. Los nodos renumerados a veces rompen direcciones antiguas.
- Editor de contenido. Que bloques de texto, imágenes y tablas se guarden bien.
- Consola del navegador y
drush watchdog tail. Recorre las páginas clave y revisa errores nuevos. - Cron.
drush cron:runy confirmar que el scheduler sigue levantando tareas. - Respaldo automático activo sobre la base ya migrada.
Un sitio que entra a la 11 debe quedar con el proceso de actualizaciones menores montado desde el día uno: el soporte de la rama 11 termina en 2028 y las minors intermedias también caducan. Automatiza un chequeo mensual con composer outdated "drupal/*" y no aplaces una minor más de un trimestre. El módulo de actualizaciones de seguridad avisa cuando hay releases, pero eso no sustituye un plan.
En Saibher hacemos esta migración en clientes que siguen en Drupal 10: el inventario y la validación en desarrollo son la parte que evita la sorpresa. Si tu proyecto está en 10.6 y no sabés por dónde empezar, escribinos y lo revisamos.
Preguntas frecuentes
¿Puedo saltar de Drupal 10.3 directo a 11.4 sin pasar por 10.6? Composer resuelve las dependencias entre minors, así que técnicamente sí. Lo que cambia es el orden en que aparecen los errores: pasar por 10.6 primero deja una base estable y convierte los problemas de la 11 en problemas de la 10, más fáciles de diagnosticar. En sitios simples funciona igual de bien el salto directo; en sitios con parches propios, el paso intermedio vale la pena.
¿Qué pasa si un módulo no tiene versión para Drupal 11? Ese módulo no tiene soporte oficial ni parches de seguridad, y no es un caso de "instalar y probar". Hay que decidir por módulo: reemplazar, reescribir la funcionalidad en código propio pequeño, o desinstalar si no se usa. Lo que no es opción es forzar la instalación con --ignore-platform-reqs: deja código de la 10 corriendo sobre un core que ya no lo soporta.
¿Puedo hacer la actualización directamente en producción? No. La migración se hace en desarrollo, se valida con la lista de verificación y después se aplica en producción con ventana de mantenimiento y respaldo inmediato antes de empezar. Si alguien te ofrece hacerlo "en vivo, es rápido", esa es la señal de que el proyecto no se ha inventariado.
¿Los cuatro años de soporte de Drupal 10 se pueden extender? No. Las ramas de Drupal tienen fecha de fin de vida fija y la comunidad no las extiende. Se puede contratar soporte comercial para que un proveedor aplique parches, pero el 9 de diciembre de 2026 ese proveedor tampoco tendrá un parche oficial que aplicar.
¿Vale la pena esperar a Drupal 12? El 12.0.0 y el 11.5.0 llegan en la misma ventana de diciembre de 2026, y el 11.5 es la rama de soporte largo. La decisión práctica: si el sitio ya está en 10.6 y con inventario hecho, migrar a 11.4 ahora y saltar a 12 con calma; si está en una versión muy vieja de la 8 o la 9, el salto directo no es una opción.
