Migración Drupal 7 a 11: guía completa 2026

Drupal 7 alcanzó su End of Life oficial en enero de 2025. La Drupal Security Team ya no publica parches y el ecosistema de módulos contrib está paralizado. Si tu portal corporativo sigue en Drupal 7 — o incluso en Drupal 8 o 9, que también están EOL — cada mes que pasa aumenta el coste y el riesgo de la migración. Pero migrar de Drupal 7 a Drupal 10 u 11 no es un upgrade: es una reescritura de buena parte de la pila técnica.

Esta guía es la hoja de ruta que aplicamos en migraciones reales para clientes corporativos.

¿Drupal 10 o Drupal 11?

Drupal 11 salió en agosto de 2024. Cuando migres desde D7 directamente, apunta a D11 salvo que tengas un módulo contrib crítico que aún no soporte D11 (cada vez menos). Migrar a D10 para luego pasar a D11 es trabajo doble.

Excepción: si tu equipo de sistemas no puede dar PHP 8.3 a corto plazo, D10 admite PHP 8.1 mínimo y te da más margen.

Fase 1 — Auditoría del Drupal 7 actual

Antes de tocar nada, inventariamos:

• Módulos contrib instalados (con drush pm-list) y su estado de port a D10/D11
• Módulos custom con cuentas de líneas de código y APIs usadas
• Volumen de contenidos: nodos por tipo, taxonomías, usuarios, comentarios, ficheros
• Theme custom: ¿PHPTemplate? ¿Twig parcial? ¿panels?
• Integraciones externas: APIs, webhooks, jobs, ESBs
• URL aliases activos y volumen de tráfico orgánico por sección
• Hooks alterados (hook_form_alter, hook_node_view, etc.) — todos van a EventSubscriber Symfony

El entregable de esta fase es un informe con clasificación por colores:

Color	Significado
🟢 Verde	Tiene port directo a D11 (módulo o equivalente core)
🟡 Amarillo	Requiere reescritura o módulo equivalente con migración de datos
🔴 Rojo	Sin equivalente — decisión: descartar funcionalidad o reescribir desde cero

Fase 2 — Diseño de la migración

Drupal 10/11 incluye Migrate API en core. Para D7→D11 hay tres vías:

1. Migrate Drupal (core): migración automática de tipos de contenido, taxonomías, usuarios y campos básicos.
2. Migraciones custom: para tipos de contenido complejos, paragraphs, media entities, relaciones específicas o transformaciones de datos.
3. ETL externo (Migrate Tools + Migrate Plus + scripts): para casos donde el origen no es un D7 limpio sino una mezcla de D6, D7 y bases legacy.

Una pieza crítica: redirects 1:1 desde URLs antiguas. Generamos un archivo de mapeo con todas las URL aliases de D7 → URLs nuevas de D11, y lo cargamos con el módulo Redirect. Sin esto pierdes autoridad SEO acumulada.

Fase 3 — Theme y frontend

PHPTemplate → Twig. PHP en templates → controllers o preprocess. Este es el bloque que más se subestima en presupuestos.

Recomendamos:

• Mantener la UX del D7 actual salvo que el cliente quiera rediseño. Si redises mientras migras, multiplicas el riesgo del go-live.
• Si hay rediseño, planear dos fases: migración a D11 con theme idéntico al actual + rediseño separado después. Dos despliegues, dos planes de rollback.
• Sistema de diseño con design tokens en CSS variables. Twig + Tailwind o Bootstrap según preferencia del equipo.

Fase 4 — Testing y staging

Staging tiene que ser idéntico a producción: mismo PHP, mismo MySQL/MariaDB, misma RAM, mismo Redis. El gotcha clásico es validar en una VM local y al desplegar en infra real explotan timeouts o memory limits que no existían en local.

Suite de tests sugerida:

• PHPUnit kernel tests para módulos custom críticos
• Behat o Cypress para flujos editoriales (crear nodo, publicar, traducir)
• Crawler de URLs que valida que las 200 URLs con más tráfico devuelven 200 OK con cabeceras SEO correctas
• PageSpeed comparativo D7 actual vs. D11 staging

Fase 5 — Cutover

El switch a producción se hace en ventana corta y reversible:

1. Modo mantenimiento en D7
2. Última sincronización de contenido pendiente
3. Última pasada de la migración ETL en producción nueva
4. Validación manual de 10 URLs clave + formulario de contacto
5. DNS switch + invalidación CDN
6. Monitorización activa primeras 24h

Si algo va mal: revertir DNS (TTL bajo a 60s durante el cutover) y hacer post-mortem antes de reintentar.

Coste y plazo realista

Para un portal corporativo medio (500-2.000 nodos, 20-30 tipos de contenido, integraciones con CRM y ERP), un plazo razonable son 3-5 meses desde kick-off hasta go-live. Presupuestos entre 25k€ y 80k€ según volumen de módulos custom y complejidad del theme.

Huye de presupuestos por debajo de los 15k€ para migraciones D7→D11 reales. Suelen ser cotizaciones que asumen migración automática completa y acaban en sprints fuera de alcance.

Qué nunca debe pasar en una migración

• Pérdida de tráfico orgánico > 5% sostenida a los 3 meses → mapeo de URLs mal hecho
• Cambios de contenido visible sin firma editorial — la migración técnica no es excusa para reescribir copy
• Plazos sin staging completo — el “lo validamos en producción” es la causa #1 de migraciones caídas

---

¿Estás en D7 o D9 y necesitas plan de migración? Pídenos una auditoría — entregable en 2 semanas con alcance, plazos y precio cerrado por sprints.