Actualización — Julio 2026: este artículo se ha revisado y ampliado. Drupal 7 lleva sin soporte desde el 5 de enero de 2025, Drupal 10 alcanza su fin de vida el 9 de diciembre de 2026 y Drupal 12 se publicará la semana del 7 de diciembre de 2026. Hoy el destino recomendado de cualquier migración desde Drupal 7 es la rama Drupal 11.4, con soporte hasta junio de 2027 y ruta de actualización directa a las siguientes versiones.
Miles de sitios web siguen funcionando sobre Drupal 7 en 2026, muchos de ellos de empresas e instituciones que dependen de ellos a diario. Si el tuyo es uno de esos, esta guía es para ti: explica por qué migrar de Drupal 7 a Drupal 11 ya no admite más aplazamientos, qué herramientas existen hoy para hacerlo con garantías, cuánto cuesta y cuánto se tarda de forma realista, y cómo ejecutar el proyecto sin perder el posicionamiento que tu web ha acumulado durante años.
Drupal 7 End of Life: enero 2025
Drupal 7 alcanzó su fin de vida oficial en enero de 2025. Esto significa no más actualizaciones de seguridad, no más parches y un ecosistema de módulos que dejará de mantenerse. Si aún tienes un sitio en Drupal 7, la migración a Drupal 10 o 11 es urgente.
Por qué no es una simple actualización
Al igual que ocurrió con Magento 1 a 2, Drupal 7 a Drupal 10/11 no es una actualización, es una reconstrucción. La arquitectura cambió radicalmente con Drupal 8: se adoptó Symfony como framework base, Twig como motor de plantillas, y un sistema de configuración completamente nuevo. Los módulos de Drupal 7 no funcionan en Drupal 10/11.
Herramientas de migración disponibles
Drupal proporciona un módulo de migración (Migrate) incluido en el core que permite transferir contenido, usuarios, taxonomías, archivos y configuraciones básicas desde Drupal 7. También existe Migrate Upgrade para migraciones más completas y Migrate Plus para transformaciones de datos avanzadas. Para módulos contribuidos populares (Views, Panels, etc.), existen paths de migración documentados.
Estrategia recomendada
La estrategia más segura es construir el nuevo sitio en paralelo: instalar Drupal 11 fresco, diseñar la arquitectura de contenido (puede ser el momento de simplificar y mejorar), desarrollar el theme y funcionalidades custom, y luego ejecutar la migración de datos como paso final. Esto permite que el sitio Drupal 7 siga operativo durante todo el proceso.
Módulos sin equivalente
Algunos módulos de Drupal 7 no tienen equivalente directo en Drupal 10/11. Panels y Page Manager han sido reemplazados por Layout Builder (incluido en el core). Features ha sido sustituido por el sistema de Configuration Management nativo. Para módulos muy específicos sin equivalente, puede ser necesario desarrollo custom o buscar alternativas funcionales.
Oportunidad de mejora
Una migración forzada es también una oportunidad para mejorar: modernizar el diseño, mejorar la arquitectura de información, implementar mejores prácticas de accesibilidad y rendimiento, e incluso evaluar si Drupal sigue siendo la mejor opción para tu proyecto o si otra plataforma se adapta mejor a tus necesidades actuales.
¿A qué versión migrar en 2026: Drupal 10, Drupal 11… o esperar a la 12?
Cuando escribimos la primera versión de este artículo, la duda razonable era migrar a Drupal 10 o dar el salto a un Drupal 11 recién llegado. En julio de 2026 esa duda ya no existe: Drupal 10 alcanza su fin de vida el 9 de diciembre de 2026 (la 10.6 es su última versión menor), de modo que migrar hoy a Drupal 10 significaría encadenar dos proyectos de actualización en pocos meses. El destino correcto es Drupal 11, cuya rama 11.4 es la actual y tiene soporte hasta junio de 2027, con actualizaciones menores dentro de la misma major que ya no se parecen en nada al salto traumático desde Drupal 7.
¿Y esperar a Drupal 12, que llega la semana del 7 de diciembre de 2026 junto a Drupal 11.5? No tiene sentido si partes de Drupal 7: cada mes extra en una plataforma sin parches es riesgo acumulado, y el paso de Drupal 11 a 12 será una actualización ordinaria, no una migración. Lo explicamos en detalle en nuestro análisis de Drupal 11, Recipes y Symfony 7 y en la guía de migración a Drupal 10, cuyo checklist de auditoría previa sigue siendo válido cambiando el destino a la 11.
Además, el ecosistema de 2026 juega a favor: Drupal CMS (el producto salido de la iniciativa Starshot) empaqueta el core con Recipes preconfiguradas, y el editor visual Canvas viene activado por defecto desde Drupal CMS 2.0. Para muchos sitios que llevan una década en Drupal 7, arrancar desde Drupal CMS reduce semanas de configuración inicial.
El proceso completo, fase a fase
La estrategia de sitio en paralelo que recomendábamos arriba se concreta en cinco fases. La primera es una auditoría de partida: inventario de módulos instalados (en sitios Drupal 7 veteranos es habitual que un tercio ya no se use), tipos de contenido reales, funcionalidades custom y volumen de datos. De esa auditoría sale la decisión más rentable del proyecto: qué NO se migra.
La segunda fase es la arquitectura en Drupal 11: instalación limpia, definición de tipos de contenido y taxonomías, y aplicación de Recipes para las piezas estándar. La tercera, theme y funcionalidades: Twig y Layout Builder sustituyen a PHPTemplate y Panels, y solo se desarrolla custom aquello sin equivalente contribuido. La cuarta es la migración de datos con Migrate, Migrate Upgrade y Migrate Plus, con migraciones incrementales que se pueden re-ejecutar hasta afinar el resultado. Y la quinta, QA, SEO y puesta en marcha: validación de contenido, redirecciones 301, pruebas de rendimiento y corte de DNS.
En proyectos de alta exigencia — como los que hemos hecho para Alfil Logistics (Grupo Damm) — trabajamos por sprints con entregas revisables: el cliente ve el sitio nuevo crecer mientras el antiguo sigue en producción.
Herramientas que acortan la migración en 2026
Más allá del trío Migrate del core, el ecosistema actual ofrece herramientas que no existían (o estaban verdes) cuando Drupal 7 dominaba el parque instalado:
Upgrade Status analiza el sitio origen y genera el informe de compatibilidad de módulos: qué tiene versión para Drupal 11, qué está abandonado y qué requiere alternativa. Rector (drupal-rector) automatiza buena parte de la conversión de código custom, refactorizando APIs obsoletas; combinado con PHPStan detecta llamadas a APIs eliminadas antes de que revienten en producción. Retrofit permite ejecutar ciertos módulos legacy de Drupal 7 dentro de un Drupal moderno como medida puente — útil para ganar tiempo, no como solución definitiva. Y el Project Update Bot mantiene un flujo constante de parches de compatibilidad en los módulos contribuidos.
Para el contenido, los paths de migración de Views, campos y entidades están maduros tras una década de uso. El esfuerzo real se concentra casi siempre en dos sitios: el theme (que se rehace, no se migra) y el código custom sin tests.
Los riesgos reales de seguir en Drupal 7 en 2026
Año y medio después del fin de vida, seguir en Drupal 7 no es solo deuda técnica: es exposición directa. Sin parches del equipo de seguridad de Drupal, cada vulnerabilidad nueva en core o en módulos contribuidos queda sin corregir para siempre — y los atacantes escanean masivamente buscando exactamente eso, como ya ocurrió con Drupalgeddon. A eso se suman versiones de PHP antiguas que los hostings van retirando, y módulos cuyos mantenedores desaparecieron hace años.
Hay además una capa de cumplimiento que en 2026 pesa cada vez más: mantener una plataforma sin soporte casa mal con el RGPD (que exige medidas técnicas adecuadas al riesgo) y con marcos como la ISO 27001, donde la gestión de vulnerabilidades y del ciclo de vida del software es un control básico. Si tu empresa está profesionalizando su seguridad, nuestra guía de seguridad informática para pymes desde cero explica por dónde empezar; y si necesitas evidencia objetiva del estado de tu plataforma, un pentesting sobre un Drupal 7 suele ser el argumento definitivo ante dirección.
Migrar sin perder SEO
El miedo a perder posicionamiento es el freno más citado para retrasar la migración, y es un miedo gestionable. Las reglas son conocidas: mapear todas las URLs del sitio antiguo, mantener las que funcionan (Pathauto permite replicar patrones) y crear redirecciones 301 para todo lo que cambie; conservar títulos, metadescripciones y datos estructurados; regenerar el sitemap XML y enviarlo a Search Console el día del corte; y vigilar los errores 404 las semanas posteriores.
Bien ejecutada, una migración a Drupal 11 suele mejorar el SEO: el rendimiento del core moderno con BigPipe y el sistema de caché — lo contamos en optimización de rendimiento en Drupal — se traduce en mejores Core Web Vitals, y la base técnica moderna facilita cumplir la normativa de accesibilidad y RGPD que Google valora cada vez más.
Costes y plazos orientativos
Cada sitio es un mundo, pero tras muchas migraciones los rangos son consistentes. Un sitio corporativo de tamaño medio (decenas de tipos de contenido no, unos pocos; miles de nodos; theme a medida) se mueve en 2-4 meses de proyecto. Portales complejos con integraciones, multiidioma o multisite pueden irse a 6 meses o más. Los factores que más encarecen: código custom sin documentar, módulos sin equivalente, contenido sucio (HTML embebido en el body, ficheros huérfanos) y la ausencia de entorno de staging.
La partida que nunca hay que recortar es la de QA y redirecciones: es barata comparada con el coste de recuperar posicionamiento perdido. Y si el proyecto lo justifica, es el momento natural de plantear decisiones de arquitectura como el frontend desacoplado — aunque nuestra recomendación honesta es no mezclar dos revoluciones en un mismo proyecto salvo motivo claro.
Usuarios, ficheros, multiidioma: los datos que dan guerra
El contenido editorial suele migrar bien; lo que da guerra son los datos de segundo nivel. Los usuarios migran con sus roles, pero las contraseñas se rehashean y conviene planificar una comunicación de restablecimiento si el sitio tiene área privada. Los ficheros arrastran años de duplicados y huérfanos: migrar la carpeta files entera sin limpiar es trasladar el desorden a la casa nueva, y el sistema de Media de Drupal moderno (que en Drupal 7 ni existía) pide decidir cómo se catalogan imágenes y documentos. El multiidioma es el caso más delicado: la arquitectura de traducción de Drupal 7 (content translation con nodos duplicados) no se parece a la actual (entity translation nativa), y el mapeo de traducciones merece su propia migración con pruebas específicas.
También conviene inventariar las integraciones: webhooks, feeds, conexiones con CRM o ERP y scripts cron que alguien montó hace años. En Drupal moderno se resuelven con APIs de primera clase — lo contamos en integraciones en Drupal: APIs, CRMs y sistemas externos — pero hay que descubrirlas antes del corte, no después, cuando el departamento que dependía de ese feed llama preguntando por qué no llegan los datos.
Después de migrar: mantenimiento y el nuevo ciclo de versiones
La mejor noticia del salto es que no volverá a haber otra migración como esta. Desde Drupal 8, las majors se suceden con rutas de actualización ordinarias: el código que funciona en Drupal 11 sin APIs deprecadas funcionará en Drupal 12. La contrapartida es que el modelo exige constancia: actualizaciones menores periódicas, parches de seguridad aplicados en días (no en meses) y limpieza de deprecaciones a cada minor. Es un cambio de mentalidad respecto a la era Drupal 7, donde un sitio podía «congelarse» una década — justo lo que ha llevado a miles de sitios a la situación actual.
Por eso el final natural de una migración es un plan de mantenimiento: monitorización, actualizaciones del core y contribuidos, backups verificados y revisión de rendimiento. El coste mensual de mantener un Drupal moderno al día es una fracción del coste de rescatar un Drupal abandonado — y esa diferencia es exactamente la historia que cuenta este artículo.
Errores comunes que vemos en auditorías
1. Intentar migrar el theme. El theming de Drupal 7 (PHPTemplate) no tiene camino a Twig: se rehace. Presupuestarlo como «adaptación» acaba en sobrecostes.
2. Migrar toda la basura. Diez años de contenido incluyen borradores, páginas huérfanas y tipos de contenido que nadie usa. Migrar sin limpiar duplica el esfuerzo y ensucia el sitio nuevo.
3. Dejar las redirecciones para el final. El mapeo de URLs debe existir desde la fase de arquitectura, no improvisarse la semana del lanzamiento.
4. No congelar contenido antes del corte. Sin una ventana de congelación (o migraciones incrementales bien planificadas), el sitio nuevo nace desactualizado.
5. Tratarlo como proyecto puramente técnico. Es la oportunidad de replantear arquitectura de información, accesibilidad y medición. Si solo se replica lo que había, se pierde la mitad del valor.
Preguntas frecuentes
¿Existe un botón de «actualizar» de Drupal 7 a Drupal 11?
No. Drupal 7 y Drupal 11 son arquitecturas distintas. La ruta es una instalación nueva de Drupal 11 y la migración de contenido y datos con las herramientas Migrate del core.
¿Cuánto tarda una migración típica?
Entre 2 y 4 meses para un sitio corporativo medio; más si hay integraciones, multiidioma, multisite o mucho código custom. La auditoría inicial permite dar un plazo realista en una o dos semanas.
¿Perderé posicionamiento en Google?
No, si se planifican redirecciones 301, se preservan metadatos y se monitorizan los 404 tras el corte. Es habitual incluso mejorar gracias al mejor rendimiento del core moderno.
Tengo WAF y backups, ¿no es suficiente para quedarme en Drupal 7?
No. Un WAF mitiga, pero no corrige vulnerabilidades sin parche, y los módulos abandonados son puerta de entrada permanente. Además, una plataforma sin soporte complica el cumplimiento del RGPD y de marcos como la ISO 27001.
¿Migro ahora a Drupal 11 o espero a Drupal 12 en diciembre?
Migra ahora a la rama 11.4. El paso posterior de la 11 a la 12 será una actualización ordinaria, mientras que cada mes en Drupal 7 es riesgo sin cobertura.
Conclusión
La migración desde Drupal 7 dejó de ser un proyecto aplazable en enero de 2025; en 2026, con Drupal 10 también camino de su fin de vida, la única jugada con sentido es una migración bien planificada a Drupal 11. Las herramientas actuales — Upgrade Status, Migrate, Rector, Recipes — han abaratado el camino, y una ejecución cuidadosa convierte la obligación en mejora real de rendimiento, seguridad y SEO. Cuanto antes se haga la auditoría inicial, antes deja de correr el reloj del riesgo.
🚀 ¿Tu proyecto Drupal necesita un impulso?
En Keliam trabajamos con Drupal desde hace años en proyectos de alta exigencia. Si buscas un partner técnico para migraciones, desarrollo de módulos o arquitectura headless, estamos aquí.
- Desarrollo y Mantenimiento Drupal — tu partner Drupal de confianza
- Auditoría Técnica Web — análisis de rendimiento y arquitectura
- Mantenimiento Web — soporte continuo para tu plataforma
