Migración a Drupal 10: estrategia, herramientas y plazos para no quedarse atrás

Drupal 10: por qué la migración ya no puede esperar

Con el fin de vida de Drupal 9 en noviembre de 2023 y Drupal 10 consolidado como la versión estable con soporte activo, las organizaciones que aún operan sobre Drupal 7 o 9 necesitan planificar su migración cuanto antes. Cada mes que pasa sin actualizar acumula deuda técnica y riesgo de seguridad que después es más costosa de remediar.

En Keliam hemos gestionado migraciones complejas para clientes de diferentes sectores, incluyendo proyectos como los que realizamos para Grupo Damm, donde la continuidad del servicio y la integridad de los datos eran requisitos no negociables. Nuestra experiencia en desarrollo y mantenimiento Drupal nos permite abordar estas migraciones con un enfoque metódico y probado.

Actualización (julio 2026): el mapa de versiones ha cambiado

Este artículo se publicó cuando Drupal 10 era el destino natural de toda migración. Un año después, conviene poner las fechas sobre la mesa: Drupal 7 llegó a su fin de vida definitivo el 5 de enero de 2025 (solo quedan programas de soporte extendido de pago a través de proveedores certificados como HeroDevs o Tag1), la rama Drupal 10.5 dejó de recibir soporte en junio de 2026 y Drupal 10 al completo alcanzará su fin de vida en diciembre de 2026, con la 10.6 como última parada. Mientras tanto, Drupal 11.4 es la versión actual y Drupal 12 tiene su lanzamiento previsto para agosto de 2026, con ventana alternativa en diciembre.

La consecuencia práctica es directa: si hoy sigues en Drupal 7 o 9, el destino recomendado ya no es Drupal 10 sino Drupal 11, estable y maduro desde hace tiempo. Y si estás en Drupal 10, tienes hasta diciembre de 2026 para dar el salto a 11 sin quedarte sin parches de seguridad. Todo lo que explicamos a continuación sobre estrategia y herramientas sigue siendo válido: la mecánica de migración desde Drupal 7 es idéntica tanto si el destino es 10 como si es 11.

Qué trae Drupal 10 a nivel técnico

Drupal 10 se construye sobre Symfony 6, PHP 8.1+ y CKEditor 5. Estas actualizaciones de dependencias no son solo cosméticas: el rendimiento mejora significativamente, la experiencia de edición con CKEditor 5 es más moderna e intuitiva, y las herramientas de desarrollo (Drush 12, Composer 2) agilizan el flujo de trabajo del equipo técnico.

El nuevo tema de administración Claro y el tema frontend Olivero también representan una mejora notable en la experiencia de usuario fuera de la caja. Para proyectos que necesitan un frontend personalizado, Drupal 10 ofrece mejor soporte para arquitecturas desacopladas con JSON:API y GraphQL como módulos del core o contribuidos bien mantenidos.

Estrategia de migración: de Drupal 7 a Drupal 10

La migración desde Drupal 7 es el escenario más complejo. No existe un path de actualización directa — se trata de una migración de datos a una instalación nueva. El módulo Migrate y sus complementos (migrate_drupal, migrate_plus, migrate_tools) permiten definir pipelines de migración para contenido, usuarios, taxonomías y configuraciones.

El proceso que seguimos es: auditar el sitio actual (tipos de contenido, módulos contribuidos, personalizaciones), diseñar la nueva arquitectura en Drupal 10, implementar los migrate scripts personalizados, ejecutar migraciones iterativas de prueba, validar datos y funcionalidades, y finalmente hacer el cutover a producción con downtime mínimo.

De Drupal 9 a 10: más sencillo pero con matices

Si ya estás en Drupal 9, la migración a 10 es mucho más directa. En la mayoría de casos se trata de actualizar dependencias de Composer, corregir código deprecado y verificar que los módulos contribuidos tienen versión compatible. Herramientas como Upgrade Status y phpstan con el ruleset de Drupal te indican exactamente qué necesita cambios.

Aun así, hay que prestar atención a los módulos contribuidos que aún no tienen versión estable para Drupal 10 y a las personalizaciones que usen APIs internas deprecadas. Un entorno de staging completo es imprescindible para validar que todo funciona antes de ir a producción.

Drupal 11 en el horizonte

Drupal 11 dejó de ser horizonte hace tiempo: es la versión actual (rama 11.4 desde julio de 2026). La buena noticia es que la comunidad Drupal aprendió del salto traumático de Drupal 7 a 8: las transiciones entre versiones mayores ahora son incrementales y mantienen compatibilidad hacia atrás. Quien invirtió en Drupal 10 en su momento tiene hoy una actualización suave a Drupal 11; quien todavía no ha salido de 7 o 9 puede saltar directamente a la versión actual.

Si tu organización necesita planificar o ejecutar una migración a Drupal 10, en Keliam podemos ayudarte en cualquier fase del proceso, desde la auditoría inicial hasta la puesta en producción.

¿Drupal 10 u 11? Qué versión elegir en 2026

Es la primera pregunta que nos hacen los clientes que arrancan ahora su proyecto de migración, y la respuesta corta es: Drupal 11 salvo excepciones muy concretas. Con Drupal 10 a meses de su fin de vida, montar hoy una instalación nueva sobre la rama 10 solo tiene sentido si dependes de algún módulo contribuido crítico que aún no tenga versión estable para 11 — un escenario cada vez más raro, porque el grueso del ecosistema contribuido ya completó la transición.

Drupal 11 se apoya en Symfony 7, PHP 8.3 y trae mejoras que van más allá de las dependencias: Recipes para componer funcionalidad reutilizable, hooks como clases orientadas a objetos y un rendimiento general superior. Además, la propia comunidad ha reforzado la puerta de entrada con Drupal CMS (el producto surgido de la iniciativa Starshot), pensado para que los site builders monten sitios completos sin escribir código. Para el detalle técnico de la versión, tienes nuestro análisis de Drupal 11: Recipes, hooks como clases y Symfony 7.

¿Y Drupal 12? Su llegada en agosto de 2026 no debe frenarte: como toda versión mayor moderna de Drupal, 12.0 será esencialmente «Drupal 11 sin las APIs deprecadas». Migrar hoy a 11 escribiendo código limpio de deprecaciones es la mejor preparación posible para 12.

Herramientas que hacen la migración más predecible

El ecosistema de tooling ha madurado mucho desde los tiempos del salto de Drupal 7 a 8, y hoy permite convertir buena parte del trabajo en un proceso sistemático:

Upgrade Status sigue siendo el punto de partida: escanea módulos contribuidos y código propio e indica qué está listo para la versión de destino y qué necesita trabajo. Drupal Rector automatiza la corrección de una parte sustancial del código deprecado — en proyectos con muchos módulos custom puede ahorrar semanas de trabajo mecánico. PHPStan con las reglas de Drupal completa el análisis estático detectando usos de APIs internas que Rector no cubre.

Para el contenido, la suite Migrate del core (con migrate_plus y migrate_tools) sigue siendo la vía canónica desde Drupal 7: pipelines declarativos en YAML, ejecución incremental, rollback y trazabilidad por fila migrada. Y para casos donde reescribir todos los módulos custom de golpe no es viable, existe Retrofit, una capa de compatibilidad que permite ejecutar código de Drupal 7 sobre Drupal 10/11 como medida puente — útil para ganar tiempo, aunque no la recomendamos como estado final.

Checklist de auditoría previa: qué inventariar antes de mover una sola línea

La calidad de la auditoría inicial determina la calidad de todo el proyecto. Antes de escribir el primer pipeline de migración, conviene tener respuesta documentada a estas preguntas:

Contenido: cuántos tipos de contenido existen y cuántos se usan de verdad; cuántos nodos hay por tipo y cuántos se han editado en los últimos dos años; qué taxonomías siguen vivas; qué campos están vacíos en más del 90% de los nodos (candidatos a desaparecer). En la mayoría de sitios veteranos, entre un 20% y un 40% del modelo de contenidos puede eliminarse sin que nadie lo eche de menos.

Módulos: lista completa de contribuidos con su equivalente en Drupal 10/11 (muchos módulos de Drupal 7 pasaron al core: Views, Media, Layout Builder cubren lo que antes exigían varios contribuidos); lista de módulos custom con su propósito real y un veredicto por cada uno — reescribir, sustituir o eliminar.

Theme y frontend: qué plantillas tienen lógica de negocio incrustada (el clásico agujero de tiempo), qué librerías JavaScript ya no se mantienen y si el rediseño visual entra o no en el alcance del proyecto.

Integraciones y entorno: servicios externos conectados (CRM, ERP, analítica, SSO, pasarelas), credenciales y responsables de cada uno, versión de PHP y base de datos del hosting actual, y si el proveedor soporta los requisitos de Drupal 11 (PHP 8.3+). Este inventario es exactamente el tipo de trabajo que cubrimos en nuestra auditoría técnica cuando un cliente llega con un sitio heredado.

Plazos y costes orientativos: qué esperar según tu escenario

Cada proyecto es un mundo, pero tras años ejecutando migraciones podemos dar rangos razonables. Una migración desde Drupal 9/10 a 11 en un sitio corporativo estándar (sin módulos custom complejos) suele resolverse en 2-4 semanas de trabajo técnico: actualización de dependencias, corrección de deprecaciones, pruebas en staging y despliegue. Si hay módulos custom extensos o integraciones delicadas, el rango sube a 4-8 semanas.

Una migración desde Drupal 7 es otro deporte: al ser una reconstrucción sobre instalación nueva, hablamos de 2 a 6 meses según volumen de contenido, número de tipos de contenido, módulos sin equivalente moderno y personalizaciones de theme. La parte positiva: es la oportunidad perfecta para sanear la arquitectura, eliminar funcionalidad muerta y repensar el modelo de contenidos en lugar de arrastrar quince años de decisiones acumuladas.

En cuanto a presupuesto, el factor que más mueve la aguja no es el volumen de contenido (los pipelines de Migrate escalan bien) sino la lógica de negocio custom: cada módulo propio hay que auditarlo, decidir si se reescribe, se sustituye por un contribuido moderno o se elimina. Por eso la auditoría inicial es la fase que más retorno tiene de todo el proyecto.

Seguridad, SEO y rendimiento: los tres frentes que no pueden quedar para el final

Una migración es también una ventana de riesgo. Seguir operando un Drupal 7 sin parches es una exposición directa — las vulnerabilidades conocidas post-EOL no se corrigen — y el propio proceso de migración introduce riesgos si no se gestiona con método. Nuestra recomendación es tratar la migración como un proyecto con tres frentes transversales:

Seguridad: revisar permisos y roles al reconstruir, no arrastrar usuarios zombis, y aprovechar para aplicar las prácticas básicas que repasamos en ciberseguridad para tu empresa: por dónde empezar. Si tu organización maneja información sensible o trabaja con clientes que lo exigen, el salto de versión es buen momento para alinear el proyecto con un marco como el de la certificación ISO 27001, y una auditoría de seguridad con pentesting tras el cutover valida que la nueva plataforma no ha abierto puertas.

SEO: inventariar URLs antes de migrar, definir redirecciones 301 para toda ruta que cambie, preservar metadatos y verificar en staging con crawling completo. Un cutover sin plan de redirecciones puede tirar por la borda años de posicionamiento.

Rendimiento: la instalación nueva es el momento de configurar bien caché, BigPipe y agregación de assets desde el primer día. Tenemos una guía completa de optimización de rendimiento en Drupal con caché, BigPipe y Varnish que aplica íntegramente a Drupal 10 y 11.

Errores comunes que vemos en migraciones Drupal

Migrar sin auditar primero. Lanzarse a montar pipelines sin haber inventariado tipos de contenido, campos y módulos acaba siempre en sorpresas a mitad de proyecto. La auditoría es barata; descubrirlo en la semana 8, no.

Replicar el sitio viejo tal cual. Si el sitio tiene diez años, parte de su estructura responde a necesidades que ya no existen. Migrar basura es pagar dos veces por ella: al migrarla y al mantenerla.

Subestimar el theme. El salto desde Drupal 7 implica reescribir el theme (Twig sustituyó a PHPTemplate hace años). Es la partida que más se infraestima en presupuestos.

No congelar contenido antes del cutover. Sin una ventana de congelación o una migración incremental final, el contenido creado durante el proyecto se pierde o hay que remigrarlo a mano.

Olvidar las integraciones. CRMs, pasarelas, analítica, SSO: cada integración necesita su prueba end-to-end en staging. En sitios corporativos como los que gestionamos para Alfil Logistics (Grupo Damm), las integraciones son precisamente donde se concentra el riesgo.

Después de migrar: mantenimiento y evolución

La migración no termina con el cutover. Un Drupal moderno con Composer exige un ciclo de mantenimiento regular: actualizaciones de core y contrib (especialmente los avisos del equipo de seguridad de Drupal), monitorización y pruebas de regresión. La cadencia de versiones actual — una minor cada seis meses, una major cada dos años — premia a quien mantiene el sitio al día y castiga con intereses a quien lo deja envejecer.

También es el momento de plantear evoluciones que antes eran inviables: consolidar varios sitios en una sola plataforma multisite, o desacoplar el frontend con una arquitectura headless si el proyecto lo justifica. Si prefieres delegar ese ciclo completo, nuestro servicio de desarrollo y mantenimiento Drupal cubre desde los parches mensuales hasta la evolución funcional.

Preguntas frecuentes

¿Sigue teniendo sentido migrar a Drupal 10 en 2026?

Solo como paso intermedio muy justificado. Drupal 10 alcanza su fin de vida en diciembre de 2026, así que cualquier proyecto que arranque ahora debería apuntar a Drupal 11 directamente. La mecánica de migración desde Drupal 7 es la misma.

¿Qué pasa si me quedo en Drupal 7?

Drupal 7 no recibe parches de seguridad desde enero de 2025. Cada mes en producción aumenta la exposición a vulnerabilidades conocidas y sin corrección pública. Existen programas de soporte extendido de pago (HeroDevs, Tag1), pero son un puente caro, no una solución.

¿Cuánto dura una migración de Drupal 9/10 a 11?

En un sitio corporativo estándar, entre 2 y 4 semanas incluyendo pruebas en staging. Con módulos custom extensos o integraciones complejas, de 4 a 8 semanas.

¿Debo esperar a Drupal 12?

No. Drupal 12 (previsto para agosto de 2026) será esencialmente Drupal 11 sin APIs deprecadas. Migrar hoy a 11 con código limpio te deja a una actualización menor de distancia.

¿Se pierde SEO al migrar?

No debería, si se planifica: inventario de URLs, redirecciones 301, preservación de metadatos y validación con crawling en staging. La pérdida de posicionamiento ocurre cuando el plan de redirecciones se improvisa el día del cutover.

Conclusión

La ventana para migrar con calma se está cerrando: Drupal 7 ya no tiene soporte, Drupal 10 lo pierde en diciembre de 2026 y el ecosistema avanza hacia Drupal 12. La buena noticia es que nunca ha habido mejores herramientas para hacer la transición de forma predecible — Upgrade Status, Rector, la suite Migrate — ni un destino tan sólido como Drupal 11. Si tu organización necesita planificar o ejecutar la migración, en Keliam podemos acompañarte en todo el proceso, desde la auditoría técnica inicial hasta el mantenimiento posterior.