El fin de soporte de seguridad para Drupal 10 es el 9 de diciembre de 2026, y eso obliga a planificar una actualización con tiempo, no a correrla en las últimas semanas.
Fechas que marcan el cambio
Cuando una versión mayor de Drupal llega al fin de soporte de seguridad, deja de recibir parches oficiales para nuevas vulnerabilidades. El sitio puede seguir funcionando, pero cualquier fallo descubierto después ya no tendrá corrección desde core. Para sitios con formularios, cuentas de usuario o integraciones con terceros, ese hecho pasa de ser una mejora a una tarea obligatoria.
Según la política de ciclos de lanzamiento de Drupal.org, el soporte de seguridad de Drupal 10 finaliza el 9 de diciembre de 2026. Ese dato es el que debe guiar la planificación, no una fecha tentativa.
Ese mismo periodo trae otro hito: Drupal 12.0.0 está previsto para la semana del 7 de diciembre de 2026, junto a Drupal 11.5.0, según el seguimiento de lanzamientos de TheDropTimes. Con ese lanzamiento, Drupal 12 exigirá PHP 8.5 y Symfony 8.1. La cercanía entre ambas fechas es la razón para no dejarlo todo para noviembre: hay apenas dos días entre el fin de soporte de Drupal 10 y la llegada de las nuevas versiones, y el entorno puede necesitar ajustes antes de poder dar el salto.
Decidir entre Drupal 11 y Drupal 12
No existe un camino único. La decisión debe basarse en el estado real del proyecto, no en cuál es la versión más nueva.
Si el sitio ya está en Drupal 10.4.x y la gran mayoría de los módulos contribuidos son compatibles con Drupal 11, migrar a Drupal 11.5.0 suele ser el camino más predecible. Permite estabilizar en una versión con soporte activo y con margen para evaluar el paso a Drupal 12 cuando sea más conveniente. En cambio, si el inventario muestra muchas dependencias que van a desaparecer o requerir reemplazos con los cambios de Drupal 12, conviene revisar módulo por módulo qué se elimina o se sustituye antes de escoger destino.
Antes de cualquier salto mayor, lo más práctico es actualizar a la última versión de Drupal 10 (10.4.x). Ese paso intermedio permite resolver muchas advertencias de obsolescencia con las herramientas de actualización, sin pasar aún entre versiones mayores. Corregir esas advertencias ahí reduce sorpresas cuando llegue el momento de pasar a Drupal 11 o a Drupal 12.
Auditoría obligatoria antes de diciembre
Planificar con margen significa auditar, no adivinar. Hay tres frentes que conviene revisar desde hoy, con un inventario que pueda marcarse como resuelto o como bloqueante.
Entorno del servidor
Verificar la versión exacta de PHP que usa el servidor es el primer punto. Si hoy está en PHP 8.1 o 8.2, habrá que presupuestar la subida a PHP 8.5 para poder ejecutar Drupal 12. En muchos casos eso implica ajustes en el proveedor de hosting o en el servidor, no solo cambios en el código del sitio. Detectar ese requisito con tiempo evita tener que coordinarlo a la vez que toda la migración.
Módulos core, contribuidos y personalizados
Hay que listar todos los módulos activos: core, contribuidos y personalizados. Para los módulos contribuidos, conviene revisar si ya tienen una release compatible con Drupal 11 o si hay indicios de que quedarán obsoletos en Drupal 12. Los módulos personalizados suelen ser los que más tiempo toman, ya que requieren revisar hooks, servicios, plugins y dependencias directamente en el código. También vale la pena revisar las listas públicas de módulos afectados por los cambios entre versiones para tener una idea de qué puede desaparecer o necesitar reemplazo.
Datos, configuraciones e integraciones
Validar las actualizaciones de configuración, rutas personalizadas, plantillas y cualquier integración con APIs. Muchas migraciones fallan por detalles de configuración, no por la actualización de Drupal en sí. Hacer esas revisiones en un entorno de staging, y registrar bloqueantes con tareas asignadas, es lo que permite avanzar sin presión cuando falten pocas semanas para el fin de soporte.
El costo de postergar
Postergar hasta noviembre o diciembre multiplica la presión: los mismos bloqueantes aparecen al mismo tiempo, pero con menos tiempo para probar en staging. Si el servidor necesita actualizarse a PHP 8.5, ese cambio suele ser el que más coordinación requiere, especialmente para pymes colombianas con hosting compartido o con poca flexibilidad sobre el entorno. Además, con menos margen hay mayor probabilidad de tener que tomar decisiones apresuradas sobre qué corregir, qué reemplazar o qué posponer.
El siguiente paso es concreto: crear un entorno de staging, actualizar el sitio a la última versión de Drupal 10.4.x, generar un inventario de módulos con su estado de compatibilidad y revisar la versión de PHP del servidor. Con esos cuatro puntos resueltos se tiene una hoja de ruta real para decidir entre Drupal 11.5.0 o Drupal 12.0.0 sin tener que decidir bajo presión.
Preguntas frecuentes
¿Puedo seguir usando Drupal 10 después del 9 de diciembre de 2026?
Sí se puede mantener encendido, pero ya no recibirá actualizaciones de seguridad oficiales de Drupal core. Si hay vulnerabilidades nuevas, el sitio quedará expuesto sin parche desde core. Para cualquier sitio con datos o acceso de usuarios, eso no es recomendable.
¿Es obligatorio pasar por Drupal 11 para llegar a Drupal 12?
No es estrictamente obligatorio desde el punto de vista del ciclo, pero sí es el camino más común. Algunos sitios pueden intentar ir directo, pero la mayoría gana tiempo haciendo la auditoría y las correcciones primero. Lo que sí es obligatorio es cumplir con los requisitos de Drupal 12: PHP 8.5 y Symfony 8.1.
¿Por qué actualizar a Drupal 10.4.x primero y no ir directo?
Actualizar a la última rama de Drupal 10 permite que las herramientas de actualización muestren las advertencias de obsolescencia que ya existen. Esas advertencias corresponden, en gran parte, a lo que tendrá que cambiar para Drupal 11 y para Drupal 12. Corregirlas ahí evita repetir el trabajo después.
¿Los módulos personalizados son los que más demoran?
En la mayoría de los casos sí. Los módulos contribuidos pueden reemplazarse o tener actualizaciones, pero un módulo personalizado necesita revisión línea por línea: servicios, plugins, hooks y cualquier integración propia. Ahí es donde conviene invertir el tiempo de auditoría con mayor prioridad.
¿Qué pasa si mi servidor no soporta PHP 8.5?
Si el hosting no permite actualizar a PHP 8.5, no se podrá ejecutar Drupal 12. En ese caso hay que planificar el cambio de entorno primero, o bien migrar a Drupal 11.5.0 mientras se gestiona ese cambio. Ese es un bloqueante real y conviene detectarlo desde hoy para tener margen en la planificación.
