Drupal 10 llega al fin de vida en diciembre de 2026: plan de acción

En diciembre de 2026, Drupal 10 alcanzará oficialmente su fin de vida. Como suele ocurrir con estas fechas límite, habrá quien ya haya tomado las medidas adecuadas y quien se enterará cuando apenas le quede margen para actuar.

En nuestra experiencia hemos encontrado casos de empresas que ni siquiera sabían que estaban usando ese sistema CMS en su web, pues hace muchos años que lo instalaron y no se ocuparon de actualizarlo hasta que les surgió algún problema y avisaron a un especialista, con frecuencia diferente a quien se lo proporcionó. En otras ocasiones, quienes son conscientes de que su ciclo de vida llega al final, no han encontrado ese hueco tranquilo entre los fuegos del día a día para buscar la alternativa. En ambos casos, están corriendo unos riesgos innecesarios.

La fecha concreta es el 9 de diciembre, según el calendario oficial de Drupal. La web seguirá funcionando después, pero Drupal 10 dejará de recibir soporte oficial y nuevas actualizaciones de seguridad. Un problema que se descubra a partir de entonces puede quedarse sin una corrección para esa versión.

Eso no significa que el fin de soporte provoque de repente cuellos de botella o que la plataforma deje de ser compatible con su entorno. Sí obliga a decidir cómo vas a mantenerla a partir de ese momento. Y cuanto más tardes en revisar su estado, menos margen tendrás para resolver lo que aparezca.

La situación reconocible: ¿en qué punto se encuentra tu organización?

Los equipos técnicos y de negocio pueden llegar al fin de vida de Drupal desde situaciones bastante distintas:

• «Funcionamos en Drupal 10, pero arrastramos módulos custom antiguos». Todo funciona y da miedo tocarlo: quizá un cambio rompa la conexión con el ERP o el CRM. Los módulos propios pueden seguir siendo útiles. Lo que toca averiguar es si necesitan cambios para funcionar en la siguiente versión.
• «Aún no hemos completado el salto desde Drupal 7 o 9». Entonces el soporte oficial ya ha terminado. Hay que estudiar desde esa versión qué pasos requiere la actualización o la migración. No podemos dar por hecho que el trabajo sea comparable al de pasar de Drupal 10 a 11.
• «Dependemos de un proveedor que no propone una ruta clara». No sabemos cuánto costará ni cuánto tardará. Tampoco tenemos documentación técnica y nos sentimos atrapados con ese proveedor.
• «Quien nos instaló Drupal no existe ya». El proveedor contratado para el sistema actual ha cesado en su actividad y no tenemos el control efectivo sobre su desarrollo.

Para revisar esas aplicaciones necesitamos localizar el código y conseguir los accesos con los que preparar una copia de trabajo.

Diagnóstico: antes de aprobar un presupuesto

Empecemos por lo básico. Antes de escribir una sola línea de código o aprobar un presupuesto, es fundamental evaluar la plataforma para elegir la estrategia adecuada y tomar la primera de las decisiones: ¿basta con actualizar o hay algo más que debemos resolver?

La transición de Drupal 10 a Drupal 11 tiene una ruta de actualización prevista. Para saber cuánto trabajo va a llevar, necesitamos ver qué extensiones utiliza tu web y qué se ha programado a medida. También qué versiones de PHP y de la base de datos tiene instaladas. Sin revisar eso, estaríamos presupuestando con información incompleta.

1. Empezaríamos por los módulos, tanto los de la comunidad como los propios, el tema y los parches. ¿Cuáles funcionan ya con Drupal 11? ¿Cuáles hay que adaptar? ¿Hay alguno que haya dejado de mantenerse? Upgrade Status nos ayuda a encontrar incompatibilidades. Después tendremos que probar la aplicación y comprobar que sigue comunicándose correctamente con los otros sistemas.
2. Y aquí conviene decidir hasta dónde queremos llegar. Si un módulo impide actualizar y hay que sustituirlo, tendremos que hacerlo. Cambiar el diseño o reorganizar todos los contenidos es otra decisión. Puede interesarnos aprovechar el proyecto para hacerlo, pero necesitaremos tiempo para decidir esos cambios y probarlos. Antes de incluirlos en el presupuesto, habrá que valorar si merece la pena hacerlos ahora.

Aprendizajes reales: el caso de Labdoo.org

En Natiboo participamos en la migración y modernización de la plataforma global de Labdoo.org.

• La petición inicial: pasar de Drupal 7 a Drupal 10.
• La propuesta tras el análisis: replantear su arquitectura, preservando el conocimiento acumulado sobre el funcionamiento de la organización.

El proyecto acabó teniendo un alcance mucho mayor que el previsto inicialmente. Lo contamos en el caso de éxito de Labdoo.

Ese ejemplo necesita un matiz aquí: actualizar Drupal 10 no implica acometer una transformación como la de Labdoo. La decisión de reconstruir una plataforma debe justificarse por sus problemas y necesidades. El cambio de versión, por sí solo, no es motivo suficiente.

Plan de acción Drupal 2026: qué debería quedar resuelto en cada fase

Fase 1. Diagnóstico

• Primero revisamos el código a medida, sus dependencias y las integraciones. Necesitas saber qué impide actualizar y qué opciones tenemos para resolverlo.
• Con eso podemos delimitar el presupuesto. Si todavía hay algo que no sabemos, tendrá que quedar indicado en la estimación.

Fase 2. Preparación y pruebas

• Trabajamos sobre una copia representativa de la aplicación, en un entorno aislado.
• Probamos que el pedido llegue al ERP, que el editor pueda publicar una traducción y que cada usuario conserve los permisos que le corresponden.

Si el proyecto incluye una migración de datos, hay otras dificultades que conviene revisar. En nuestra experiencia, un foco habitual de problemas son los datos anidados, que requieren algoritmos de extracción más complejos. Otro son los recursos externos: ficheros o fotografías que no están accesibles en el momento de sincronizarlos. Son comprobaciones específicas de una migración de datos; no todas las actualizaciones de Drupal 10 a 11 necesitan ese proceso.

Fase 3. Validación con quienes usan la plataforma

En una migración de Drupal, los problemas suelen venir de requisitos no declarados y que no son fácilmente identificables revisando el código. Quienes usan la aplicación deben probarla y dar el visto bueno antes de publicar los cambios.

Fase 4. Despliegue y revisión

• Antes de publicar, acordamos con quienes se encarguen del despliegue si hace falta interrumpir el servicio, qué pasará con los datos generados durante el cambio y cómo volver atrás.
• Las copias deben poder restaurarse. También debe quedar decidido quién valida el resultado y quién revisa la web después.

El compromiso de Natiboo: colaboración y documentación

Colaboramos con tu equipo o nos encargamos si no dispones de uno. Dejamos documentados los cambios, las decisiones y lo que quede pendiente.

¿Tu plataforma depende de Drupal 10?

Si necesitas ayuda con la actualización, podemos revisar tu plataforma y concretar un diagnóstico para estimar el trabajo.

Cuéntanos en qué punto se encuentra tu plataforma.