Cómo actualizar de Drupal 9 a Drupal 10 sin perder funcionalidad
Cómo actualizar de Drupal 9 a Drupal 10 sin perder funcionalidad
Si gestionas un portal corporativo, un ecommerce o una intranet construida sobre Drupal 9, hay una fecha que probablemente ya conoces: noviembre de 2023. Ese mes Drupal 9 llegó a su fin de vida (end of life). Desde entonces no recibe parches de seguridad oficiales del proyecto, lo que significa que cada nueva vulnerabilidad descubierta queda sin cubrir. Para una empresa española sujeta al RGPD y, en muchos casos, a auditorías de seguridad de clientes o proveedores, mantener una web en una versión sin soporte no es un detalle menor: es una exposición real.
La buena noticia es que pasar de Drupal 9 a Drupal 10 no se parece en nada a las migraciones traumáticas que muchos recordamos de épocas anteriores. Bien planificada, es una actualización controlada en la que no tienes por qué perder funcionalidad, contenido ni configuración. La mala noticia es que "bien planificada" implica trabajo previo: auditar el estado del sitio, revisar la compatibilidad de los módulos contribuidos y del tema, sustituir CKEditor 4 por CKEditor 5 y limpiar el código deprecado. Vamos a verlo paso a paso, con el detalle técnico que necesita un equipo que quiere hacerlo bien a la primera.
Por qué actualizar ya: seguridad y soporte
El argumento principal es la seguridad. Cuando una versión de Drupal deja de tener soporte, el Drupal Security Team deja de publicar Security Advisories para ella. Eso no quiere decir que el software deje de funcionar de un día para otro, pero sí que cualquier fallo crítico que aparezca en el core o en módulos ampliamente usados se convierte en una puerta abierta. Un portal de una administración pública, un ecommerce con datos de pago o una web que recoge formularios con datos personales no se puede permitir ese riesgo.
Hay un segundo motivo, más estratégico: la deuda técnica. Cuanto más tiempo te quedes en Drupal 9, más se aleja tu base de código del ecosistema actual. Los módulos contribuidos van abandonando el soporte para versiones antiguas, los desarrolladores se acostumbran a las nuevas APIs y, llegado Drupal 11, saltar desde una versión obsoleta es mucho más caro que mantener el ritmo. Actualizar a tiempo es, en realidad, la opción barata.
Y un tercer motivo es funcional. Drupal 10 trae un editor más moderno, dependencias actualizadas y un rendimiento mejor afinado. No actualizas solo para "estar al día"; actualizas para que tu plataforma siga siendo mantenible y para que el equipo que la cuida pueda seguir encontrando soluciones y soporte en la comunidad.
La diferencia clave: D9 → D10 no es una migración
Aquí conviene aclarar un malentendido muy extendido. Mucha gente equipara "actualizar Drupal" con "migrar Drupal", y son cosas distintas.
Pasar de Drupal 7 a Drupal 8, 9 o 10 sí es una migración en el sentido fuerte: la arquitectura cambió radicalmente entre D7 y D8, hay que reconstruir el sitio sobre una base nueva, exportar y mapear el contenido con el sistema de Migrate, rehacer el tema desde cero y, a menudo, buscar equivalentes para módulos que ya no existen. Es un proyecto de semanas o meses.
En cambio, pasar de Drupal 9 a Drupal 10 es una actualización. La arquitectura es la misma: el contenido, la configuración, las vistas, los tipos de contenido y los datos siguen su curso. No reconstruyes nada desde cero. El trabajo se concentra en tres frentes muy concretos: subir las dependencias del sistema (PHP, base de datos), garantizar que los módulos contribuidos y el tema tienen versión compatible con D10, y eliminar el código deprecado que D10 ya no admite. Si tu sitio está razonablemente al día, es perfectamente realista completar la actualización en pocos días de trabajo efectivo.
Esta distinción importa porque condiciona presupuesto, plazos y expectativas. Una empresa que viene de Drupal 7 debe asumir un proyecto de migración; una que está en Drupal 9 afronta una actualización ordenada y, con método, sin sobresaltos.
Requisitos técnicos de Drupal 10
Antes de tocar nada, comprueba que tu infraestructura cumple lo que Drupal 10 exige. Estos son los puntos que más suelen frenar una actualización:
| Componente | Drupal 9 | Drupal 10 |
|---|---|---|
| PHP | 7.3+ | 8.1 como mínimo (recomendado 8.2/8.3) |
| Symfony | 4 | Symfony 6 |
| Editor enriquecido | CKEditor 4 | CKEditor 5 |
| MySQL / MariaDB | MySQL 5.7 / MariaDB 10.3 | MySQL 5.7.8+ / MariaDB 10.3.7+ (mejor versiones recientes) |
| Drush | 10/11 | Drush 12 |
| Composer | 1/2 | Composer 2 |
El salto de PHP suele ser el que más planificación requiere. Si tu hosting o servidor está en PHP 7.4, hay que subir a 8.1 o superior, y ese cambio puede afectar a código personalizado del tema o de módulos a medida. Symfony 6 viene de la mano del core, así que no lo gestionas directamente, pero sí condiciona la compatibilidad de algunos módulos contribuidos. Y CKEditor 5 es, probablemente, el cambio más visible para los usuarios editores, porque CKEditor 4 quedó completamente fuera de Drupal 10.
Auditoría previa con Upgrade Status
No se actualiza a ciegas. El primer paso real, una vez confirmados los requisitos del servidor, es instalar el módulo Upgrade Status en tu Drupal 9. Esta herramienta escanea el sitio completo y te genera un informe con el estado de cada módulo contribuido y de tu código personalizado de cara a Drupal 10.
El informe te clasifica los módulos en varios grupos: los que ya tienen versión compatible con D10, los que tienen una versión compatible disponible pero no instalada, los que usan código deprecado y necesitan parches, y los que directamente no tienen camino hacia D10. Este último grupo es el que exige decisiones: ¿hay un módulo alternativo que cubra la misma funcionalidad?, ¿se puede prescindir de él?, ¿merece la pena patrocinar o aportar la actualización del módulo en drupal.org?
Upgrade Status también analiza tu código personalizado —el del tema a medida y el de cualquier módulo propio— y te señala las APIs deprecadas que tendrás que corregir. Ese informe es la columna vertebral de toda la planificación: te dice exactamente dónde está el trabajo y te permite estimar esfuerzo con datos en lugar de con intuiciones.
Compatibilidad de módulos contrib y temas
Con el informe en la mano, revisa módulo a módulo. Para los contribuidos, lo habitual es que baste con actualizar a una versión más reciente que declare compatibilidad con Drupal 10 en su archivo .info.yml (la línea core_version_requirement). Para muchos módulos populares esto ya está resuelto desde hace tiempo.
El tema merece atención aparte. Si usas un tema a medida basado en Stable o Classy, ten en cuenta que Drupal 10 dejó de incluir el tema base Stable original y otros componentes que se daban por hechos en D9. Conviene revisar las plantillas Twig, las librerías de assets y cualquier dependencia de temas base que hayan cambiado. Si el front se construyó sobre un tema base externo, asegúrate de que ese tema tiene release para D10 antes de seguir.
Eliminar código deprecado con drupal-rector
Para el código personalizado, la herramienta que te ahorra horas es drupal-rector. Es una utilidad que aplica transformaciones automáticas sobre tu código para sustituir las llamadas a APIs deprecadas por su equivalente compatible con Drupal 10. No lo arregla todo —algunos casos necesitan intervención manual—, pero resuelve buena parte del trabajo mecánico y repetitivo.
El flujo es sencillo: instalas drupal-rector vía Composer en el entorno de desarrollo, lo ejecutas sobre los directorios de tus módulos y tema a medida, revisas el diff que propone y validas los cambios. Después vuelves a pasar Upgrade Status para confirmar que el número de avisos de código deprecado baja hasta cero o hasta un puñado de casos que resolverás a mano. Nunca apliques estos cambios directamente en producción: trabaja siempre sobre el repositorio y con control de versiones.
De CKEditor 4 a CKEditor 5
Este es el cambio que más conviene preparar con cariño, porque afecta a la experiencia diaria de quienes publican contenido. Drupal 10 monta CKEditor 5 como editor por defecto y retira por completo CKEditor 4.
La transición no es automática al cien por cien. CKEditor 5 tiene una arquitectura distinta, y no todos los plugins y botones de CKEditor 4 tienen un equivalente directo. Antes de actualizar, en tu Drupal 9 todavía con CKEditor 4, instala el módulo de migración correspondiente y revisa cada uno de tus formatos de texto y sus configuraciones de editor. Comprueba que los botones que usan tus editores —enlaces, medios incrustados, tablas, estilos personalizados— tienen su contrapartida en CKEditor 5.
Presta especial atención a configuraciones avanzadas: filtros HTML permitidos, plugins de terceros, integraciones con el módulo Media o con bibliotecas de imágenes. Es frecuente que un formato de texto muy personalizado necesite un ajuste manual tras la migración del editor. La recomendación práctica es preparar la conversión a CKEditor 5 mientras aún estás en Drupal 9, dejarlo validado por el equipo editorial y solo entonces dar el salto de versión. Así separas un cambio de otro y evitas diagnosticar dos problemas a la vez.
El proceso paso a paso con Composer
Llegamos a la parte operativa. Drupal moderno se gestiona con Composer, y la actualización se orquesta desde ahí. Este es el orden de trabajo que recomendamos, siempre fuera de producción primero.
- Levanta un entorno de staging que replique producción: misma versión de PHP objetivo (8.1+), misma configuración de servidor web y una copia reciente de la base de datos y de los archivos. Sin un staging fiel, las pruebas no valen.
- Haz copia de seguridad completa: volcado de base de datos y copia del directorio de archivos (
sites/default/files) y del código. Esta copia es tu seguro y la base de tu plan de rollback. - Asegúrate de estar en la última versión de Drupal 9 (la rama 9.5.x) antes de saltar. Las versiones finales de D9 son las que mejor preparan el terreno para D10.
- Actualiza primero los módulos contribuidos y el tema a las versiones compatibles con Drupal 10 que ya hayas identificado en la auditoría, todavía en D9. Que un módulo declare compatibilidad con D9 y D10 a la vez es lo ideal para escalonar.
- Aplica los cambios de drupal-rector sobre el código personalizado y resuelve a mano lo que quede.
- Eleva el core a Drupal 10 ajustando las restricciones de versión en
composer.json(por ejemplo,drupal/core-recommended:^10) y ejecutandocomposer updatecon las dependencias del core. Composer resolverá el árbol de paquetes; si protesta, casi siempre es por un módulo que aún no tiene versión D10 y que habías pasado por alto. - Lanza las actualizaciones de base de datos con
drush updatedb(o desde/update.php) y exporta/importa la configuración según tu flujo (drush config:export). - Limpia cachés y revisa el informe de estado del sitio en busca de avisos.
Trabajar con Composer y un repositorio Git te da trazabilidad total: cada paso queda registrado y puedes volver atrás si algo no encaja.
Pruebas, QA y validación
Actualizar el código es la mitad del trabajo; la otra mitad es comprobar que todo sigue funcionando como antes. Aquí es donde se evita de verdad "perder funcionalidad".
Define un guion de pruebas que cubra los flujos críticos del sitio: alta y edición de contenido con CKEditor 5, formularios de contacto y de captación, búsquedas, vistas (Views) que alimentan listados y bloques, integraciones con CRM o pasarelas de pago, multilingüe si lo usas, y los permisos por rol. Repasa también el front en distintos navegadores y en móvil, porque un cambio en el tema base puede haber alterado estilos.
Si tu proyecto tiene tests automatizados (PHPUnit, Behat), este es el momento de pasarlos en el staging actualizado. Y si no los tiene, una actualización mayor es una buena excusa para introducir al menos una batería mínima de pruebas funcionales que te protejan en futuros saltos de versión. Revisa los logs de Drupal y de PHP en busca de errores o deprecaciones que se hayan colado.
Plan de rollback: tu red de seguridad
Por muy bien preparado que esté todo, una actualización en producción siempre necesita un plan de marcha atrás claro y ensayado. El rollback se apoya en las copias de seguridad que hiciste antes de empezar.
Define de antemano: cómo restauras la base de datos desde el volcado, cómo recuperas la versión anterior del código (idealmente con un simple git checkout de la rama estable o un despliegue de la release previa), y cómo devuelves el directorio de archivos a su estado original si hizo falta tocarlo. Acota una ventana de mantenimiento —fuera de horario de mayor tráfico para una empresa española, típicamente a primera hora o por la noche— y comunica al cliente o a los equipos internos que el sitio puede no estar disponible durante el despliegue.
La clave es que el rollback no sea una idea, sino un procedimiento escrito que ya has probado en staging. Si has ensayado el despliegue completo fuera de producción, el salto real será predecible y el plan de contingencia, una formalidad que probablemente no necesites usar.
Checklist resumido de la actualización
| Fase | Acción | Estado |
|---|---|---|
| 1 | Verificar PHP 8.1+, Composer 2, base de datos compatible | ☐ |
| 2 | Instalar Upgrade Status y generar informe | ☐ |
| 3 | Resolver módulos contrib y tema sin versión D10 | ☐ |
| 4 | Ejecutar drupal-rector sobre código a medida | ☐ |
| 5 | Migrar formatos de texto a CKEditor 5 (en D9) | ☐ |
| 6 | Subir a la última 9.5.x | ☐ |
| 7 | Backup completo de BD, archivos y código | ☐ |
| 8 | Elevar core a D10 con Composer en staging | ☐ |
| 9 | Ejecutar updatedb y validar configuración | ☐ |
| 10 | QA de flujos críticos y revisión de logs | ☐ |
| 11 | Despliegue en producción con ventana y rollback listos | ☐ |
Conclusión: una actualización, no un salto al vacío
Actualizar de Drupal 9 a Drupal 10 sin perder funcionalidad es perfectamente alcanzable cuando se hace con método. El secreto no está en un comando mágico, sino en el trabajo previo: auditar con Upgrade Status, resolver la compatibilidad de módulos y tema, limpiar el código deprecado con drupal-rector, preparar CKEditor 5 antes del salto y ensayarlo todo en un entorno de staging fiel. Hecho así, el día del despliegue en producción es la parte aburrida y previsible del proceso, que es justo como debe ser.
Con Drupal 9 ya sin soporte desde noviembre de 2023, posponer la actualización solo aumenta el riesgo y el coste. Si quieres que un equipo con experiencia real en proyectos Drupal audite tu sitio y planifique la actualización a Drupal 10 con garantías, puedes contar con nuestro equipo de consultoría Drupal para hacerlo sin sobresaltos y sin perder nada por el camino.