La pregunta que llega a las mesas de arquitectura este año casi siempre viene formulada como una elección entre dos caminos: migrar ahora a Drupal 11, o aguantar el portal como está y saltar directo a Drupal 12 cuando salga. Es una pregunta razonable y ahorra, en apariencia, un proyecto completo.
El calendario publicado por la Drupal Association cierra esa puerta. Drupal 12 se libera la semana del 7 de diciembre de 2026 y para llegar ahí hay un requisito técnico explícito: un sitio debe estar en Drupal 11.4 o superior antes de actualizar, con la recomendación fuerte de estar en 11.5. No existe una ruta soportada que vaya de Drupal 10 a Drupal 12 saltándose el escalón intermedio. Quien decide esperar a Drupal 12 hace exactamente el mismo trabajo de migración, solo que más tarde y con la ventana de soporte ya cerrada.
Eso reordena la conversación. Las tres razones que siguen son las consecuencias operativas de un calendario que ya está fijado y que corre con independencia de la planeación interna de cada organización.
Razón 1. El 9 de diciembre de 2026 los parches de seguridad de Drupal 10 se detienen
Drupal 10 se liberó el 15 de diciembre de 2022 y llega a fin de vida el 9 de diciembre de 2026. La versión 10.6 es la última minor de esa rama. Después de esa fecha no hay más releases: una vulnerabilidad reportada en el core en enero de 2027 sobre un portal en Drupal 10 no tiene parche oficial, y la organización queda con tres opciones, todas costosas. Parchar por cuenta propia, contratar soporte extendido si existe para su caso, o migrar bajo presión de incidente.
Para un portal universitario con pasarela de pagos de matrícula, o para el portal de una institución de salud que expone agendamiento y datos de paciente, esa tercera opción es la que termina ocurriendo. Y una migración ejecutada durante un incidente de seguridad se hace sin ventana de pruebas, sin plan de regresión y con el equipo respondiendo a comunicaciones en paralelo.
La fecha importa por una razón práctica que suele pasarse por alto en la discusión técnica: los ciclos presupuestales de las instituciones enterprise en la región se cierran entre septiembre y noviembre. Un portal que no tenga la migración dentro del presupuesto aprobado para 2027 va a pasar los primeros meses del año sin soporte de core y sin partida para resolverlo. La decisión presupuestal vence antes que la fecha técnica.
Vale la pena separar dos cosas que se confunden. El fin de soporte no apaga nada: un portal en Drupal 10 sigue funcionando el 10 de diciembre exactamente igual que el día anterior. Lo que cambia es que la comunidad deja de producir el parche, y el riesgo pasa de estar distribuido en el proyecto a estar concentrado en el equipo que opera ese portal.
Razón 2. Drupal 11 es el escalón de la ruta hacia Drupal 12
Este es el punto que más cambia los planes cuando aparece en una sesión de arquitectura.
El proceso de deprecación de Drupal core funciona por acumulación. Cuando se agrega una API nueva, la anterior queda marcada como deprecada y programada para eliminarse en una versión mayor posterior. El resultado es una ruta de actualización continua entre majors, con la condición de estar al día en la rama actual antes de saltar a la siguiente. Para Drupal 12 esa condición está escrita: los sitios en 11.3 o anteriores deben actualizar primero a 11.4 o superior, porque todo el código de actualización previo a esa versión fue removido.
La lectura para un portal que hoy corre Drupal 10 es directa. La migración a Drupal 11 es trabajo que hay que hacer en cualquier escenario, y el único grado de libertad real es si se hace con calendario propio o contra la fecha de diciembre.
Hay una diferencia de naturaleza entre los dos saltos que conviene tener presente al estimar. Pasar de Drupal 10 a Drupal 11 implica revisar el estado de cada módulo contribuido, retirar el código deprecado del perfil propio y subir la versión de PHP. Drupal 11 arranca en PHP 8.3, mientras que Drupal 10 todavía admite instalaciones en 8.1, así que en muchos portales heredados la actualización de plataforma es parte del alcance y no un prerrequisito resuelto. En los portales enterprise que hemos acompañado, ese componente de infraestructura suele ser el que más sorprende en la estimación inicial, sobre todo cuando el hosting es propio y la ventana de mantenimiento hay que negociarla con varias áreas.
Razón 3. Lo que compra la migración es que el siguiente salto deje de ser un proyecto
La tercera razón es la que sostiene el caso de negocio más allá de 2026, y depende de una decisión de la comunidad que pasó bastante desapercibida.
Las deprecaciones disruptivas introducidas desde Drupal 11.3 quedaron programadas para removerse en Drupal 13, y no en Drupal 12. La intención fue darle aire al ecosistema de módulos contribuidos, para que un mantenedor pueda soportar la próxima versión mayor y las minors vigentes con la misma base de código. El efecto lateral para quien opera un portal es más concreto: el salto de Drupal 11 a Drupal 12 conserva compatibilidad hacia atrás en las APIs importantes y se parece mucho más a una actualización de rutina que a una migración.
Un portal que llegue a diciembre de 2026 sobre Drupal 11.5 tiene por delante una actualización de core que su equipo puede ejecutar dentro de una ventana de mantenimiento normal. Un portal que llegue sobre Drupal 10 tiene por delante un proyecto con discovery, presupuesto, pruebas de regresión y comité de cambios.
Ahí está el argumento que funciona frente a un comité financiero, y conviene plantearlo en esos términos: la migración de 2026 se amortiza en el ciclo de 2027, porque convierte un gasto recurrente de proyecto en una tarea de operación. En instituciones que corren varios portales sobre una misma plataforma, ese cambio se multiplica por el número de sitios. Un multisite con doce portales que hoy exige coordinar doce planes de migración pasa a exigir una sola ventana de actualización coordinada.
La razón para esperar
Hay un caso en el que arrancar la migración este trimestre es la decisión equivocada, y aparece con más frecuencia de lo que sugiere el calendario.
Si el portal depende de un módulo contribuido crítico que todavía no tiene versión compatible con Drupal 11, y ese módulo sostiene una función de negocio sin sustituto, la fecha que gobierna el plan la pone el mantenedor de ese módulo. Arrancar la migración sin esa dependencia resuelta produce un resultado predecible: el equipo llega al final del proyecto con el core actualizado y una funcionalidad de negocio apagada, y la institución termina sosteniendo un fork propio del módulo por tiempo indefinido.
La secuencia correcta en ese escenario empieza por el inventario de dependencias y deja el core para después. Vale la pena hacerlo esta semana, porque es rápido y define todo lo demás:
- Listar los módulos contribuidos que el portal tiene habilitados en producción, separando los que son de conveniencia de los que sostienen una función de negocio.
- Revisar en drupal.org el estado de compatibilidad con Drupal 11 de cada uno del segundo grupo, y la fecha del último commit del mantenedor.
- Para los que no tengan versión compatible, decidir entre tres caminos con nombre y responsable: contribuir el parche de compatibilidad, reemplazar la funcionalidad con capacidades del core, o retirarla del alcance.
El resultado de ese inventario define si la migración es un proyecto de tres meses o de ocho, y es lo que permite entrar al comité de presupuesto con una cifra defendible. En los portales enterprise donde hemos hecho este ejercicio, la lista de módulos verdaderamente críticos casi siempre es más corta de lo que el equipo esperaba, y buena parte de lo que parecía bloqueante resulta ser funcionalidad que el core ya absorbió en alguna de las minors de Drupal 10.
Conviene también nombrar un caso que suele presentarse como razón para esperar. Un rediseño pendiente del portal se sostiene mejor como proyecto aparte: son dos trabajos con dependencias distintas, y acoplarlos suele producir un alcance que no cierra ninguno de los dos. La ruta que mejor ha funcionado es migrar primero sobre el diseño vigente y abrir el rediseño después, ya sobre Drupal 11, donde las capacidades de armado visual de la plataforma cambian el punto de partida de esa conversación.
Cómo se ve un plan que llega a diciembre
Quedan poco menos de tres meses de calendario útil, descontando las semanas de cierre de año en las que la mayoría de instituciones congela cambios en producción. Es tiempo suficiente para un portal de complejidad media cuyo inventario de módulos salga limpio, y es ajustado para un multisite.
La distribución que hemos visto funcionar reparte ese tiempo en tres bloques desiguales. El inventario y la resolución de dependencias se lleva la primera parte y es donde se decide el éxito del resto. La actualización de PHP y de la plataforma de hosting corre en paralelo, porque depende de terceros y tiene sus propios tiempos de aprobación. La migración de core y las pruebas de regresión ocupan el último tramo, y ahí el factor que más pesa es la cobertura de pruebas automatizadas que el portal ya tuviera antes de arrancar.
Ese último punto merece una advertencia. Un portal sin pruebas automatizadas puede migrarse, pero el costo se traslada a QA manual, y el equipo funcional que debe ejecutarlo suele ser el mismo que está cerrando el año. Si el portal no tiene esa cobertura, es mejor saberlo en septiembre que en noviembre.
Para instituciones que corren su plataforma sobre proveedores del ecosistema, vale la pena sumar una conversación temprana con ellos. Tanto Acquia como Dropsolid tienen sus propios calendarios de certificación de versiones y ventanas de actualización de los entornos gestionados, y esos tiempos rara vez coinciden con los de la organización. Preguntar en septiembre por la fecha en que su plataforma soporta Drupal 11.5 evita descubrir en noviembre que la ventana disponible es distinta a la planeada.
Lo que viene después de diciembre
Drupal 12 estrena el ritmo de versiones mayores más corto que la comunidad adoptó en los últimos años, y eso tiene una consecuencia que todavía no está incorporada en la mayoría de los planes de plataforma de la región. La actualización de versión mayor deja de ser un evento cada cuatro o cinco años y pasa a ser una rutina de calendario, del orden de lo que hoy es una actualización de minor.
Las organizaciones que lleguen a 2027 con esa rutina instalada van a operar con una ventaja que se acumula: van a estar recibiendo las capacidades de IA que entran al core de Drupal en el ciclo en que se liberan, mientras el resto las evalúa en la versión siguiente. Para 2028, tener el portal en la versión mayor vigente va a ser el estado normal de un portal enterprise, y la excepción va a ser el portal que se quedó atrás. Esa es la diferencia real que compra una migración ejecutada con calendario propio.
El patrón se repite en los más de 40 portales enterprise que sostenemos en producción en LATAM, varios en multisite y algunos con más de ocho años de operación continua sobre la misma plataforma: las migraciones que llegan a tiempo son las que dedicaron las primeras semanas al inventario de dependencias, y las que se desbordan son las que arrancaron fijando la fecha de salida a producción y acomodaron el alcance después. Son 16 años viendo el mismo orden de causas, con Drupal Certified Partner Platinum y Acquia Elite Partner en la región como el marco desde el que acompañamos estas migraciones.
Si quieres el detalle de lo que Drupal 11 trae a nivel de funcionalidad antes de armar el caso interno, lo desarrollamos en Innovaciones de Drupal 11. Y si la conversación en tu organización todavía está un paso antes, en si la plataforma debe ser un DXP o basta un CMS, ese marco está en ¿Qué es un DXP y su empresa realmente necesita uno?. Para el criterio de selección de plataforma desde la silla del CIO, está Qué decide en realidad un CIO cuando elige CMS.