Actualizar Drupal 10 a 11 con el tráfico en vivo, sin ventana de caída

En corto: se trata la actualización como una entrega más del mismo sitio. Se construye y se prueba lejos de producción, se ensaya sobre una copia llenada desde producción hasta que la configuración quede limpia, y luego sale como sale cualquier cambio: una imagen de contenedor probada, un solo comando de despliegue, una verificación de salud y un respaldo tomado justo antes. Nada de eso exige apagar la página. Lo que exige es un sitio que se pueda reconstruir desde el código y una forma de devolverse escrita antes de empezar. Aquí van los pasos de drupal.org, lo que les sumamos y las trampas que ya nos costaron.

¿Se cae la página mientras se actualiza?

No hay una caída planeada: nada de una noche con aviso de mantenimiento mientras alguien actualiza a mano. El sitio sigue sirviendo la versión actual mientras la nueva se construye y se prueba en otra parte. El cambio en sí es reemplazar un contenedor y correr drush deploy.

Eso no quiere decir que nada pueda fallar en ese momento. Una de nuestras propias cicatrices, más abajo, son cuatro solicitudes que fallaron en los segundos entre el arranque del contenedor nuevo y el final del despliegue. Lo corregimos. Lo importante es saber dónde están esos segundos.

Nuestro fundador dirigió el paso de Drupal 9 a 11 de una red de unos 400 sitios del sector salud, con datos reales de producción, donde ninguna de las organizaciones podía aceptar una ventana de caída (2023–2026). Es su trayectoria antes de Tecnocratica. Nuestros propios sitios nacieron en Drupal 11.3 en abril de 2026, así que ninguno ha hecho el salto de 10 a 11. Sí han pasado por una actualización menor (de 11.3 a 11.4, en julio de 2026) y luego por dos versiones de seguridad y una de corrección de errores. El método de abajo salió de esas entregas: la verificación de salud llegó en julio de 2026, y las pruebas obligatorias y el ensayo, en octubre.

¿Cuáles son los pasos oficiales para actualizar Drupal 10 a 11?

La guía de drupal.org (actualizada el 21 de agosto de 2026), en corto:

1. Estar en Drupal 10.3.0 o posterior (en la práctica, la última 10.6.x), con PHP 8.3 o posterior.
2. Reemplazar por su versión contribuida, o dejar de usar, los módulos que Drupal 11 sacó del núcleo: Actions UI, Activity Tracker, Book, Forum, Statistics y Tour.
3. Encontrar lo que no está listo con Upgrade Status, y corregir el código obsoleto con Drupal Rector.
4. Pedir Drupal 11 con Composer (drupal/core-recommended:^11, con sus paquetes de scaffold y project-message), actualizar Drush y permitir el plugin de Composer symfony/runtime, que el núcleo agregó como dependencia en 11.4.
5. Correr composer update y luego drush updatedb.
6. Desplegar, revisar los registros y correr cron.

La guía recomienda hacerlo primero en local con DDEV y después desplegar al servidor. No dice nada de respaldos, modo de mantenimiento ni caídas. Lo que sigue es cómo se ve ese "después desplegar" en un sitio que no se puede apagar.

Paso 1: ¿el sitio se puede reconstruir desde el código?

Antes de cualquier actualización, el código y la configuración tienen que estar en git, la configuración exportada (config/sync) tiene que coincidir con producción, y el build tiene que armar el sitio desde el archivo de bloqueo de Composer. Si producción tiene configuración que git no tiene, la actualización la va a pisar o se va a tropezar con ella.

Nuestros sitios nacen de nuestra plantilla pública, así que esto se cumple desde el primer commit. En un sitio que recibimos de otro proveedor, llegar ahí es el primer trabajo.

Paso 2: ensayar sobre una copia de producción

Las pruebas instalan un sitio limpio, así que nunca ven la base de datos de producción. El ensayo sí:

1. Llenar una copia local desde producción, base de datos y archivos. Va en un solo sentido: el contenido nunca viaja de la copia local a producción.
2. Poner el código de Drupal 11 sobre esa copia y correr drush deploy tal como lo correrá producción: actualizaciones de base de datos, importación de configuración y reconstrucción de caché.
3. Correr drush config:status. Tiene que decir que no hay diferencias.

Se repite hasta que lo diga. En nuestra plataforma este ensayo es obligatorio para cualquier entrega que agregue, quite o reemplace un módulo, y toda actualización de 10 a 11 lo hace. Dos de las trampas de abajo aparecieron ahí y en ningún otro lugar antes de producción.

Paso 3: sacarla como cualquier otra entrega

En nuestra plataforma, cada entrega pasa por cuatro controles:

• La integración continua corre las pruebas sobre una instalación limpia con MariaDB y revisa las dependencias contra los avisos de seguridad conocidos. Luego construye la imagen de contenedor. Si una prueba falla, no hay imagen, y por lo tanto no hay despliegue.
• El despliegue trae esa imagen, la arranca y corre drush deploy. El proceso nunca toca la base de datos ni los archivos, salvo por las actualizaciones del propio despliegue.
• La verificación de salud pide la página de inicio y exige HTTP 200, al menos 5.000 bytes y ninguna señal de error fatal, con reintentos durante un máximo de dos minutos y medio.
• Detrás de Cloudflare, los visitantes anónimos siguen recibiendo páginas de la caché mientras tanto. Después del despliegue, solo se purgan y se vuelven a pedir las páginas cuyo HTML cambió.

Paso 4: escribir cómo devolverse antes de necesitarlo

Justo antes de actualizar se toma una foto: la imagen que está corriendo y un respaldo de la base de datos tomado en ese momento. Después:

• si el sitio se rompe y el esquema de la base de datos no cambió, se vuelve a arrancar la imagen anterior;
• si drush deploy ya corrió actualizaciones de base de datos, un paso que trae el procedimiento de drupal.org, se restaura también el respaldo. Lo que se haya escrito entre la foto y la devolución se pierde, y por eso la foto se toma justo antes.

¿Qué trampas ya nos costaron?

Cada una está documentada, con su corrección, en el archivo BATTLE_SCARS de nuestra plantilla pública:

• Una actualización de seguridad que parecía aplicada y no lo estaba (§18). Composer ya había escrito las versiones nuevas en el archivo de bloqueo cuando un plugin bloqueado detuvo la instalación. La auditoría decía "limpio" y el código que corría seguía siendo el viejo. Hay que revisar la versión instalada (drush status), no solo el archivo de bloqueo.
• Un build en verde que sirvió un error fatal durante unos tres días y medio (§19). El mismo plugin, permitido con false en vez de true, dejó de generar un archivo que cada solicitud necesita. El sitio roto respondía HTTP 200 con 500 bytes. Por eso nuestra verificación mira el tamaño y no solo el código de respuesta.
• Un módulo retirado en el mismo despliegue que lo desinstala (§41). Para desinstalar se necesita el código del módulo, así que un módulo sale en dos despliegues: primero se desinstala con el código presente, después se quita el código.
• Un sitio con español como idioma principal cuya configuración nunca quedaba limpia (§42). El módulo de traducción reescribe el idioma de la configuración importada, y config:status mostraba decenas de diferencias falsas después de cada despliegue. Hay que exportar desde un sitio que ya corrió la importación.
• Solicitudes atendidas con el código de la versión anterior (§43). Durante unos segundos después de arrancar la imagen nueva, Drupal usó definiciones guardadas de la anterior, y fallaron cuatro solicitudes. Una llave por imagen lo corrigió.
• Una imagen base que su publicador había dejado de construir (§47). Nuestra imagen fijaba una etiqueta de PHP 8.3 que no se actualizaba desde enero de 2026, así que la corrección de seguridad de PHP de octubre de 2026 nunca le llegó. Pasamos a PHP 8.4. Una actualización es buen momento para confirmar que su PHP de verdad está al día.

¿Cuánto se demora y cuánto cuesta?

No damos un plazo antes de leer el código. Depende de cuántos módulos contribuidos usa, cuánto código propio tiene y qué tanto se ha alejado producción de lo que hay en git. Una hora con nuestro fundador cuesta 75 dólares, y es la forma de empezar: usted nos muestra el sitio y le decimos dónde está el trabajo. Hoy el ingeniero es él, así que trabajamos en horario hábil de Colombia (UTC-5), sin guardias 24/7.

¿Y la fecha límite, y Drupal 12?

Drupal 10 deja de tener soporte el 9 de diciembre de 2026 (qué hacer y para cuándo). Drupal 12 está previsto para esa misma semana, exige PHP 8.5 y un sitio que ya esté en Drupal 11.3 o más. Llegar hoy a Drupal 11.4 es el paso que piden las dos cosas.

Para hablar de su actualización, vea lo que ofrecemos, escríbanos o pregúntele al concierge en nuestra página de inicio.