Drupal 10 deja de tener soporte en diciembre de 2026

Si administrás un sitio en Drupal 10, la fecha que importa es el 9 de diciembre de 2026. Ese día termina el soporte de seguridad de la rama 10, coincidiendo con la salida de Drupal 12. A partir de ahí, cualquier vulnerabilidad que se descubra en core o en los módulos contribuidos que ya no acompañen la versión queda sin parche oficial.

Conviene decirlo sin dramatismo: faltan poco más de tres meses y el trabajo que hay por delante no se parece en nada a la migración de Drupal 7. Pero también conviene no dejarlo para noviembre, porque el problema no es el esfuerzo técnico sino la agenda de quien lo haga.

Por qué el destino es Drupal 11 y no Drupal 12

Parece contraintuitivo saltar a la versión que ya está por ser reemplazada, pero es lo correcto por dos motivos.

El primero es que no existe un camino directo desde versiones viejas hacia Drupal 12. El modelo de actualización de Drupal es incremental: cada versión mayor se construye sobre la anterior y no se puede saltear un escalón. Un sitio en 10 tiene que pasar por 11 igual, así que el trabajo es exactamente el mismo se apunte a donde se apunte.

El segundo es de sentido común operativo. Drupal 12.0.0 va a ser una .0 recién salida el día que aparezca. El ecosistema de módulos contribuidos tarda meses en ponerse al día con una versión mayor nueva, y poner un sitio en producción sobre una release de días es exponerse a problemas que nadie reportó todavía. Drupal 11 lleva dos años en la calle, está probado y tiene el ecosistema maduro.

Una vez en Drupal 11, el salto posterior a 12 es un trámite. Ese es justamente el punto del ciclo de dos años: las versiones mayores modernas quitan código ya marcado como obsoleto y suben dependencias, no reescriben la plataforma.

Qué implica realmente el salto de 10 a 11

La diferencia con la migración desde Drupal 7 es de otra escala. Acá no se migran contenidos, no se reconstruye el modelo de datos y no se rehace el theme. La base de datos es la misma. Lo que se hace es:

• Subir el sitio a la última versión menor de la rama 10 disponible (10.6.x) antes de tocar nada más.
• Resolver las dependencias de PHP y de la infraestructura.
• Reemplazar todo el código propio que use APIs marcadas como obsoletas.
• Actualizar o reemplazar los módulos contribuidos que no tengan versión compatible.
• Correr las actualizaciones de base de datos y la importación de configuración.

El primer punto es más importante de lo que parece. Un sitio en 10.6.x salta a 11 con mucho menos fricción que uno que quedó clavado en 10.1, porque el camino de actualización continuo asume que venís desde la última menor.

Dónde aparecen los problemas de verdad

En mi experiencia, el 80% del tiempo de una actualización 10 → 11 se va en dos lugares, y ninguno es el core.

Los módulos contribuidos huérfanos. Siempre hay dos o tres módulos que resolvieron algo puntual hace años, que nadie mantiene, y que no tienen versión para 11. Ahí hay que decidir: adoptar el mantenimiento, reemplazarlo por otro, o resolver esa funcionalidad de otra forma. Es una decisión de negocio disfrazada de decisión técnica, y por eso conviene tomarla temprano y no la semana antes de salir.

El código propio. Los módulos custom que escribió la agencia que construyó el sitio suelen usar APIs que quedaron obsoletas en 10 y desaparecen en 11. Detectarlo es fácil con herramientas; arreglarlo es trabajo manual proporcional a cuánto código propio tenga el sitio.

Cómo saber en qué estado está tu sitio, hoy

Si tenés acceso por consola, tres comandos te dan el panorama completo:

# versión exacta de core
drush status --field=drupal-version

# módulos instalados y sus versiones
drush pm:list --status=enabled --type=module

# actualizaciones pendientes, incluidas las de seguridad
drush pm:security

Si no tenés consola, la misma información está en /admin/reports/status y /admin/modules/update dentro del panel de administración.

Para el análisis de compatibilidad propiamente dicho, el módulo Upgrade Status genera un informe con todo lo que va a romperse, separado entre lo que resuelven los mantenedores de cada módulo y lo que te toca a vos. Es la herramienta que uso para armar cualquier presupuesto de actualización.

Cuánto tiempo hay que reservar

Rangos honestos, para un sitio que ya está en 10.6.x y con entorno de staging disponible:

Esos números incluyen pruebas y despliegue, no solo el trabajo de código. Y asumen que alguien del lado del cliente está disponible para validar que el sitio funciona: esa suele ser la parte que estira los plazos, no la técnica.

Qué pasa si no llegás a diciembre

No se cae el sitio. No se apaga nada. Lo que ocurre es que quedás fuera del circuito de parches: si en enero aparece un aviso de seguridad crítico en core, no va a haber una versión 10.7 que lo arregle.

Cuánto riesgo representa eso depende de tu sitio. Un sitio informativo sin usuarios registrados y detrás de un WAF puede convivir con esa situación algunas semanas mientras se termina la actualización. Un sitio con formularios, cuentas de usuario, pagos o datos personales, no.

Si sabés desde ya que no vas a llegar, la decisión razonable no es apurar la actualización mal hecha en noviembre. Es planificarla para el primer trimestre de 2027 con presupuesto y tiempo, y mientras tanto reducir superficie de exposición: revisar permisos, desactivar módulos que no se usan, poner el panel de administración detrás de una restricción de IP y tener backups verificados.

El orden en que yo lo haría

1. Esta semana: averiguar la versión exacta de core y correr Upgrade Status. Son dos horas y te dice si tu caso es simple o complicado.
2. Septiembre: decidir qué hacer con cada módulo sin versión compatible. Esta es la conversación larga, la que tiene que empezar antes.
3. Octubre: subir a 10.6.x en producción. Es un paso chico y de bajo riesgo que simplifica todo lo que viene después.
4. Octubre y noviembre: hacer la actualización a 11 en staging, con el código propio corregido, y probar de verdad.
5. Antes de diciembre: desplegar y quedarse tranquilo mientras el resto corre.

Y una recomendación que vale para cualquier actualización mayor: no la aproveches para meter funcionalidad nueva. La tentación siempre está —"ya que lo tocamos, cambiemos también el buscador"— y es la forma más segura de que un proyecto de tres semanas termine en tres meses y sin fecha de salida clara.

Si tu sitio todavía está en Drupal 7 o 8

Es otra conversación, bastante más larga. Drupal 7 dejó de recibir soporte oficial en enero de 2025 y el camino hacia una versión moderna es una migración de contenido real, no una actualización. Lo cuento en detalle en la nota sobre migrar de Drupal 7 a Drupal 11.