De Drupal 10 a Drupal 11 sin dramas: la guía que me habría gustado tener antes de empezar

Si tienes un sitio en Drupal 10 funcionando y te preguntas cómo actualizar de Drupal 10 a Drupal 11 sin que se te caiga producción un viernes por la tarde, te cuento lo que aprendí haciéndolo. Aviso desde ya: esto no se parece en nada al trauma de migrar de Drupal 7 a Drupal 9. Aquello era reconstruir el sitio entero; esto es, en la mayoría de los casos, una actualización menor bien planificada. Pero "menor" no significa "a ciegas", así que vamos por partes.

Por qué deberías moverte (y no dejarlo para el último mes de soporte)

El argumento más seco es el del ciclo de vida. Drupal 10 tiene fecha de caducidad de soporte ligada a sus dependencias, sobre todo Symfony 6. Cuando esa base llega a su End of Life, dejas de recibir parches de seguridad para el core. Y un Drupal sin parches de seguridad en un sitio público es exactamente el tipo de cosa que termina en una llamada a las 3 de la mañana.

Más allá del miedo, Drupal 11 trae cosas que se agradecen en el día a día:

• Menos deuda heredada: el core arranca limpio de código deprecado que arrastraba D10, lo que significa menos sorpresas y un núcleo más mantenible.
• Recipes estabilizándose como forma de empaquetar configuración reutilizable, que a medio plazo va a cambiar cómo montamos sitios nuevos.
• Mejoras en la experiencia de edición y avances hacia un editor más moderno.
• Dependencias al día: PHP 8.3, Symfony 7, y un stack que tu equipo de sistemas no va a mirar con cara de pena.

Si vienes del mundo D7, esto te va a sonar raro: aquí no hay una "gran migración". El esfuerzo está en limpiar deprecaciones, no en rehacer.

El factor coste y riesgo

Cuanto más esperas, más módulos contribuidos se quedan sin mantenedor para tu versión, más se acumula la diferencia y más caro sale el salto. Actualizar pronto, cuando todavía estás en una D10 reciente, es la jugada barata. Dejarlo para cuando ya estás en EOL es la jugada cara.

Lo que tu plataforma necesita antes de empezar

Aquí no hay margen para el optimismo. Si tu servidor no cumple, Composer te va a parar en seco. Los requisitos de plataforma de Drupal 11 son:

• PHP 8.3 o superior. Esto es lo que más gente pilla de improviso. Muchos hostings en España siguen sirviendo PHP 8.1 o 8.2 por defecto. Comprueba tu versión y la disponibilidad del 8.3 con tu proveedor antes de tocar nada.
• Symfony 7 por debajo, que es transparente para ti pero condiciona el resto.
• Base de datos con versiones recientes: MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+ o SQLite 3.45+ según el motor. Los números concretos conviene verificarlos en la documentación oficial vigente antes de migrar, porque las versiones mínimas se van ajustando entre releases.
• Drush 13 para la parte de línea de comandos.

Un consejo de quien se ha comido el problema: levanta primero la versión de PHP en tu entorno de desarrollo y deja que el sitio en Drupal 10 corra sobre PHP 8.3 unos días. Si algo se rompe ahí, lo arreglas mientras sigues en terreno conocido, no en mitad del upgrade.

Estar en la última D10 antes de saltar

Regla de oro: no se salta a D11 desde una D10 vieja. Primero actualizas a la última versión de la rama 10 (10.3 / 10.4 según toque), aplicas las actualizaciones de base de datos, y desde ahí das el paso. El motivo es práctico: el camino de actualización del core está pensado para ir de la última D10 a D11, y muchas deprecaciones se documentan y avisan precisamente en esas últimas versiones de la 10.

Detectar el código que se va a romper: Upgrade Status y Rector

Esta es la fase donde se decide si tu upgrade es de una tarde o de tres semanas. La buena noticia es que el ecosistema te da herramientas serias para no ir adivinando.

Upgrade Status, tu radar de compatibilidad

El módulo Upgrade Status escanea tu sitio entero (core, módulos contribuidos y tu código custom) y te dice qué está listo para Drupal 11 y qué no. Te genera un informe por proyecto: módulos verdes que pasan tal cual, módulos que necesitan una versión más nueva y módulos que usan API deprecada.

Lo instalas como dependencia de desarrollo, lo ejecutas y lees el informe con calma. Yo lo trato como la lista de la compra del upgrade: hasta que no está todo en verde o con un plan claro para cada rojo, no me muevo.

Rector para automatizar lo aburrido

Para tu código custom, muchas deprecaciones son cambios mecánicos: una función que ahora se llama distinto, un servicio que cambia de firma, un patrón que se sustituye por otro. Drupal Rector automatiza buena parte de esas correcciones. No hace magia con la lógica de negocio, pero sí con el 70-80% del trabajo repetitivo de actualizar llamadas deprecadas.

El flujo es: Rector te aplica los cambios automáticos, tú revisas el diff con ojo crítico (porque a veces se pasa o se queda corto), y lo que quede lo arreglas a mano. Lo que Rector no toca suele ser justo lo que necesita criterio humano.

Módulos contribuidos y custom: el punto donde la mayoría se atasca

El core de Drupal 11 lo actualizas casi sin pestañear. Donde aparece el trabajo real es en todo lo demás.

Módulos contribuidos: revisa en su página de proyecto si tienen una release compatible con D11. La mayoría de los módulos populares ya la tienen, pero siempre hay alguno de nicho que va por detrás o directamente está abandonado. Para esos casos tienes tres salidas: buscar un módulo alternativo mantenido, asumir su mantenimiento tú aplicando los parches de compatibilidad, o replantear si esa funcionalidad la necesitas de verdad.

Módulos custom: aquí mandas tú. Con Upgrade Status sabes qué API deprecada usas, con Rector limpias lo automatizable, y el resto es revisión manual. Si tu código custom estaba bien hecho y al día con D10, el salto suele ser cómodo. Si arrastra parches viejos y API que ya estaba deprecada en D10, te tocará pagar esa deuda ahora.

Una nota sobre temas

No te olvides del frontend. Si usas un tema custom basado en Olivero o Stable, revisa plantillas Twig y librerías. Suele ser el componente más tranquilo, pero los *.libraries.yml y algún cambio en el sistema de renderizado pueden darte trabajo menor.

El proceso paso a paso, en orden

Así es como lo abordo yo, y por qué este orden importa.

1. Backup completo. Base de datos y ficheros. Antes de tocar absolutamente nada. Si usas un entorno gestionado, haz también un snapshot.
2. Entorno de pruebas idéntico a producción. Nunca, jamás, el primer upgrade en producción. Clona el sitio en local o en un staging que replique versión de PHP, base de datos y configuración.
3. Actualiza a la última D10 y ejecuta las actualizaciones de base de datos.
4. Pasa Upgrade Status y Rector, deja todo compatible, commitea esos cambios.
5. Actualiza el core a D11 con Composer y los módulos a sus versiones compatibles.
6. Ejecuta las actualizaciones con Drush y reconstruye la caché.
7. Revisión post-update: comprueba el log de Watchdog, recorre las rutas críticas, valida formularios, permisos, vistas y cualquier integración externa.
8. Repite en staging hasta que el procedimiento salga limpio y documentado. Solo entonces lo aplicas a producción.

Comandos de ejemplo

Aquí tienes el esqueleto de comandos. Adáptalo a tu setup, no lo copies a ciegas en producción.

# 1. Backup de base de datos antes de nada
drush sql-dump --gzip --result-file=../backups/pre-upgrade.sql

# 2. Asegúrate de estar en la última Drupal 10 y aplica updates
composer update "drupal/core-*" --with-all-dependencies
drush updatedb -y
drush cache:rebuild

# 3. Herramientas de análisis (entorno de desarrollo)
composer require --dev drupal/upgrade_status drupal/rector
drush en upgrade_status -y
# Revisa el informe en /admin/reports/upgrade-status

# 4. Aplica correcciones automáticas al código custom
vendor/bin/rector process web/modules/custom

# 5. Salto al core de Drupal 11
composer require "drupal/core-recommended:^11" "drupal/core-composer-scaffold:^11" "drupal/core-project-message:^11" --update-with-all-dependencies

# 6. Actualiza la base de datos y limpia caché
drush updatedb -y
drush cache:rebuild

# 7. Comprueba el estado y los logs
drush status
drush watchdog:show --count=50

Fíjate en que cada paso de actualización va seguido de un updatedb y un cache:rebuild. Saltarte esos dos comandos es la causa número uno de "pues a mí me funcionaba en local".

Red de seguridad: rollback y backup que de verdad funcionen

Un backup que no has probado a restaurar no es un backup, es un deseo. Antes del upgrade, asegúrate de que sabes restaurar tu base de datos y tus ficheros en cuestión de minutos.

Mi plan de contingencia tiene tres niveles:

• Snapshot de infraestructura del servidor o contenedor, para volver al estado exacto previo.
• Dump de base de datos con drush sql-dump, comprimido y fuera del docroot.
• Estado de Composer congelado: commitea tu composer.lock antes de actualizar, para poder volver a la combinación exacta de versiones con un git checkout y un composer install.

Si algo va mal en producción, el rollback debe ser una decisión de un minuto, no una sesión de pánico improvisando. Y un detalle de cumplimiento que en España conviene tener presente: si tu sitio maneja datos personales, esos backups contienen datos sujetos a RGPD. Guárdalos cifrados, con acceso restringido y con una política de retención definida; no los dejes tirados en una carpeta del servidor para siempre.

Por qué esto no es el infierno de D7 a D9

Si tu memoria muscular viene de la migración de Drupal 7, mereces una buena noticia. Aquel salto era una reconstrucción: API completamente nueva, módulos reescritos desde cero, migración de contenido con el módulo Migrate, plantillas rehechas. Proyectos de meses y presupuestos de reconstrucción.

De Drupal 10 a Drupal 11 el modelo es otro. Desde Drupal 8, el proyecto adoptó un esquema de actualizaciones continuas: el core va deprecando API de forma ordenada dentro de cada versión mayor y, cuando llega la siguiente, simplemente retira lo ya deprecado. Por eso, si llegas a D11 desde una D10 limpia y al día, no migras contenido, no rehaces el sitio: actualizas. La diferencia de esfuerzo entre ambos escenarios es de un orden de magnitud.

La trampa está en confiarse. "Es una actualización menor" no significa "hazla en caliente sin pruebas". Significa que, si haces los deberes (estar al día, escanear con Upgrade Status, limpiar con Rector, probar en staging), el riesgo es perfectamente controlable.

Cuándo conviene que te eche una mano un equipo con cicatrices

Hay sitios donde el upgrade es una tarde de trabajo, y otros donde el custom code, las integraciones a medida o un par de módulos huérfanos convierten lo que parecía menor en un proyecto con su planificación, su staging y su ventana de despliegue. Si tu Drupal mueve negocio de verdad y no te apetece descubrir los problemas en producción, en Tangram hemos hecho este salto unas cuantas veces y podemos revisar contigo el estado de tu sitio y trazar un plan realista antes de tocar una sola línea.

Empieza hoy por lo barato: comprueba en qué versión de Drupal 10 estás, levanta PHP 8.3 en un entorno de pruebas y pasa Upgrade Status. Con ese informe en la mano ya sabrás si tu upgrade es de café o de proyecto. Y eso, créeme, vale más que cualquier corazonada.