Migrar de Drupal 7 a Drupal 11: qué se conserva y qué se rehace

Drupal 7 dejó de recibir actualizaciones de seguridad oficiales en enero de 2025, después de casi quince años en producción. Miles de sitios siguen funcionando sobre esa base, muchos de ellos institucionales, y la pregunta que llega siempre es la misma: ¿cuánto cuesta actualizarlo?

La respuesta empieza por corregir el verbo. No se actualiza. Se migra. Y la diferencia entre esas dos palabras es la diferencia entre un proyecto de dos semanas y uno de cuatro meses.

Por qué no es una actualización

Entre Drupal 7 y Drupal 8 hubo una reescritura completa de la plataforma: Drupal 8 se construyó sobre Symfony, con otro sistema de configuración, otra capa de entidades, otro motor de plantillas y otra forma de escribir módulos. Nada del código de un sitio Drupal 7 funciona sobre uno moderno.

De la 8 en adelante, en cambio, el camino es continuo: un sitio en 10 pasa a 11 sin migrar nada. Por eso Drupal 7 es el único caso donde todavía hay que hacer trabajo real.

El destino: Drupal 11, no Drupal 12

Drupal 12 sale la semana del 7 de diciembre de 2026, pero no es el destino correcto para una migración que empieza hoy. No existe un camino directo desde Drupal 7 hacia 12: hay que pasar por 11 de todas formas. Y poner un sitio recién migrado sobre una versión mayor con días de vida, cuando el ecosistema de módulos contribuidos todavía no la acompañó, agrega riesgo sin beneficio.

Drupal 11 salió en agosto de 2024, está probado y tiene el ecosistema maduro. El salto posterior de 11 a 12, cuando corresponda, es un trámite.

Las tres decisiones que definen el presupuesto

1. Qué contenido no se migra

Esta es la decisión que más plata ahorra y la que casi nadie toma a tiempo. Un sitio de quince años acumula tipos de contenido que se usaron dos veces en 2013, secciones que nadie mantiene y miles de nodos que no recibieron una visita en años.

Antes de escribir una línea de migración conviene sacar el inventario real:

# cantidad de nodos por tipo de contenido, en el sitio viejo
drush sql:query "SELECT type, COUNT(*) AS total \
  FROM node GROUP BY type ORDER BY total DESC;"

Cruzá esa lista con las visitas de los últimos doce meses. Casi siempre aparece que el 70% del tráfico se concentra en dos o tres tipos de contenido. Todo lo demás es candidato a archivarse en lugar de migrarse, y cada tipo que se descarta son días menos de trabajo y de pruebas.

La pregunta correcta no es "¿cómo migramos todo?" sino "¿qué de todo esto sigue teniendo valor?".

2. Qué hacer con el diseño

El theme se rehace sí o sí, porque el motor de plantillas cambió. La decisión real es si se replica el diseño actual lo más fiel posible o se aprovecha para hacer uno nuevo.

Replicar suele ser más barato y mucho más rápido de aprobar, porque no hay que discutir nada con nadie. Rediseñar tiene sentido si el sitio es de 2011 y se nota, pero conviene entender que eso ya no es un proyecto de migración: son dos proyectos, con dos presupuestos y dos plazos. Mezclarlos es la causa más frecuente de migraciones que nunca terminan.

3. Qué pasa con los módulos propios

Todo módulo custom se reescribe. No hay atajo. Pero antes de reescribir vale la pena revisar si lo que hacía ese módulo en 2014 hoy ya está en el core o en un módulo contribuido mantenido. En quince años, buena parte de lo que había que programar a mano pasó a estar resuelto.

De cada módulo propio hay tres salidas posibles: reemplazarlo por algo existente, reescribirlo, o descartarlo porque la funcionalidad ya no se usa. La tercera es más común de lo que uno espera y siempre es la más barata.

Cómo se hace, en la práctica

Drupal trae en el core una Migrate API pensada exactamente para esto, con soporte para leer directamente de una base de datos Drupal 7. El flujo habitual es:

1. Se levanta el sitio nuevo en Drupal 11, limpio, con los tipos de contenido y los campos ya definidos.
2. Se conecta la base de datos vieja como fuente secundaria, en modo lectura.
3. Se escribe una migración por cada tipo de contenido, mapeando campo por campo.
4. Se corre, se revisa lo que salió mal, se ajusta el mapeo y se vuelve a correr. Muchas veces.
5. Se migran los alias de URL y se generan las redirecciones que hagan falta.

Los módulos que hacen el trabajo son migrate (core), más Migrate Plus, Migrate Tools y Migrate Upgrade.

El paso que más se subestima: las redirecciones

Si el sitio tiene posicionamiento en buscadores, perder las URLs es perder años de trabajo. Todo alias que cambie necesita una redirección 301 desde la dirección vieja hacia la nueva.

La forma de no equivocarse es sacar el listado completo de URLs del sitio viejo antes de empezar, guardarlo, y al final verificar una por una que respondan. Con el módulo Redirect se cargan las que haga falta.

# exportar todos los alias del sitio viejo antes de tocar nada
drush sql:query "SELECT source, alias FROM url_alias;" \
  > alias-drupal7.txt

Guardá ese archivo aunque no lo uses en el momento. El día que alguien reporte que un enlace de hace ocho años dejó de andar, va a ser lo único que te salve.

Cuánto lleva y cuánto cuesta

Rangos reales, contando desarrollo, migración de contenido, pruebas y salida a producción:

Lo que estira los plazos casi nunca es el código. Es la validación: alguien del lado del cliente tiene que revisar que el contenido migrado esté completo y correcto, y eso es trabajo humano que compite con las tareas del día a día de esa persona. Cuando se arma el cronograma, conviene reservarle tiempo explícitamente.

La alternativa: sostener Drupal 7 un tiempo más

Si no hay presupuesto ahora, no migrar de apuro es una decisión legítima. Existen proveedores comerciales de soporte extendido para Drupal 7 que siguen publicando parches de seguridad después del fin de vida oficial. Es una solución paga y temporal, pero permite ganar un año con el sitio cubierto.

Lo que no es una opción razonable es la tercera vía, la que elige casi todo el mundo por omisión: dejar el sitio andando sin parches y sin plan, esperando que no pase nada. Un Drupal 7 sin soporte no se rompe solo; se rompe cuando alguien encuentra la vulnerabilidad, y para entonces la conversación ya no es sobre presupuesto.

Por dónde empezar esta semana

1. Sacar el inventario de tipos de contenido con la consulta de más arriba.
2. Exportar el listado de alias de URL y guardarlo.
3. Listar los módulos propios y anotar, al lado de cada uno, qué resuelve y si se sigue usando.
4. Cruzar los tipos de contenido con las visitas del último año.

Con esas cuatro cosas cualquier desarrollador puede darte un presupuesto realista en vez de un rango de humo. Y vos vas a entender el proyecto lo suficiente como para saber si te lo están cotizando bien.