Salir de Drupal multisite: elegir un camino tras Drupal 7 y migrar los sitios en orden

Una guía práctica para equipos con muchos sitios en Drupal multisite: las tres opciones reales tras el fin de vida de Drupal 7, cómo auditar tipos de contenido, vistas y módulos por sitio, una hoja de puntuación para saber qué sitios justifican Drupal y un plan de cambio que conserva las URL y los registros.

Drupal multisite suele vivir en universidades, organismos públicos y grandes asociaciones, donde un equipo competente lo configuró para servir decenas de sitios departamentales desde un mismo código base. Desde entonces el equipo ha cambiado, los sitios se han multiplicado y muchas redes siguen en Drupal 7, cuyo soporte de seguridad comunitario terminó el 5 January 2025. Sea lo que sea lo que te trajo aquí, la pregunta es la misma: ¿cuáles de estos sitios necesitan de verdad Drupal y cuál es la forma menos arriesgada de mover el resto? Esta guía recorre esa decisión y después la migración en sí.

Cómo está montado Drupal multisite

La documentación de Drupal describe multisite como la ejecución de sitios separados e independientes desde un mismo código base, cada uno con su propia base de datos, configuración, archivos y dominio. En disco, cada sitio tiene su propia carpeta dentro del directorio sites, que contiene al menos sus archivos y a veces sus propios módulos y temas. Dos consecuencias marcan cualquier migración:

Código compartido, datos separados. Una actualización del núcleo o de un módulo llega a todos los sitios a la vez, que es el atractivo original y el principal riesgo. Un módulo del que depende un sitio no se puede quitar sin revisar todos los demás.
Cada sitio es su propia migración. Como cada sitio tiene su propia base de datos y configuración, no existe una única "exportación de la red". Planificas, mueves y pruebas sitio por sitio.

Tus tres opciones, comparadas con honestidad

Opción	Qué implica	Ideal para	Costo principal
Pasar a Drupal actual	Crear sitios nuevos en Drupal actual y traer el contenido con la Migrate API de Drupal. Desde Drupal 7 esto es una reconstrucción y migración, no una actualización en el sitio.	Sitios con modelos de contenido complejos, uso intensivo de Views, módulos a medida, integraciones o un equipo que conoce bien Drupal	Tiempo de desarrollo por sitio y mantenimiento continuo de Drupal
Soporte extendido de pago para Drupal 7	Seguir con Drupal 7 con parches de seguridad de un proveedor del Extended Security Support Provider Program de la Drupal Association (actualmente HeroDevs y Tag1 Consulting)	Ganar tiempo mientras se planifica y financia una migración	Una cuota recurrente, y la migración sigue pendiente
Pasar a otra plataforma	Reconstruir los sitios en otro CMS o creador de sitios web	Sitios institucionales, informativos, de eventos y departamentales con contenido sencillo	Reconstruir cada sitio; perder funciones propias de Drupal que sí usabas

La mayoría de las redes grandes terminan con una mezcla: unos pocos sitios complejos se quedan en Drupal, la larga cola pasa a algo más simple y algunos se retiran. El trabajo consiste en decidir qué sitio va adónde.

Audita el modelo de contenido de cada sitio

Los sitios Drupal se diferencian entre sí mucho más de lo que suelen hacerlo los de WordPress, porque los tipos de contenido, campos y vistas se crean por sitio. Antes de puntuar nada, registra lo que cada sitio usa realmente. Un desarrollador de Drupal puede obtener casi todo esto desde las pantallas de administración o con Drush; lo importante es reunirlo en una sola hoja.

Elemento	Qué registrar	Por qué importa
Tipos de contenido	Cada tipo, número de elementos, último elemento creado	Muchos tipos con pocos elementos sugieren sobreconstrucción; un tipo con 5,000 elementos necesita una migración con scripts
Campos	Campos de referencia, field collections o paragraphs, campos de archivo	Las relaciones estructuradas son lo más difícil de trasladar a una plataforma más simple
Taxonomías	Vocabularios y cómo guían la navegación o el filtrado	Los listados filtrados necesitan un equivalente en la nueva plataforma
Vistas	Cada vista, dónde aparece, si muestra filtros a los usuarios	Los filtros expuestos (un directorio de personal, un buscador de cursos) suelen ser la razón de ser de un sitio
Formularios	Webforms, sus envíos, necesidades de conservación	Los envíos pueden ser registros que debes conservar
Usuarios y roles	Editores, miembros, cualquier cuenta pública	Por lo general, las contraseñas no se pueden llevar a otra plataforma
Módulos a medida y contribuidos	Qué hace cada uno en este sitio	Cada uno es una función que reconstruir o una dependencia que eliminar
Integraciones	Inicio de sesión único, sistemas de estudiantes o miembros, pagos, búsqueda	Suelen decidir si un sitio puede dejar Drupal
Tráfico y enlaces	Visitas de 12 meses, principales páginas de entrada, páginas con enlaces externos	Define el trabajo de redirecciones

Puntúa qué sitios justifican Drupal

Da a cada sitio un punto por cada "sí" de la lista. El umbral lo fijas tú, pero en la práctica los sitios con tres o más puntos suelen pertenecer a Drupal actual u otro CMS completo, y los que tienen cero o uno son buenos candidatos para un creador más sencillo.

Tiene contenido estructurado que otras páginas consultan (un directorio, un catálogo, un buscador de cursos o de personal).
Tiene filtros o búsqueda para usuarios más allá de la búsqueda básica del sitio.
Depende de un módulo a medida que hace trabajo real.
Se integra con un sistema interno de registro.
Tiene usuarios con sesión iniciada además de los editores.
Tiene un equipo editorial que necesita varios roles y revisión por etapas.
Tiene más de unos cientos de páginas que se mantienen activamente.

Puntúa los sitios con sus responsables presentes. Los responsables suelen saber que la elaborada vista de su página de inicio no la mira nadie desde hace años, y con la misma frecuencia conocen una dependencia que nadie más recuerda.

Mover los sitios que se van

Contenido

Para los sitios sencillos, la vía más rápida suele ser una copia estructurada: rastrea el sitio en vivo para obtener cada página y su URL, y luego reconstruye página por página, reescribiendo sobre la marcha. Para sitios con cientos de elementos del mismo tipo (noticias, eventos), expórtalos como CSV o JSON, con ayuda de un desarrollador o mediante la exportación de datos de Views, e impórtalos donde la nueva plataforma lo permita, o decide que solo se migran los dos últimos años y el resto se archiva.

Archivos

Copia la carpeta de archivos de cada sitio. Revisa si hay archivos privados (Drupal puede servir archivos fuera de la carpeta pública), que a menudo contienen documentos que deben seguir restringidos; requieren una decisión deliberada, no una subida masiva a un sitio público.

Registros

Los organismos públicos y las universidades suelen tener obligaciones de conservación de registros para el contenido web y los envíos de formularios. Antes de apagar nada, exporta lo que debes conservar, guárdalo en tu sistema de registros y anota adónde fue. Una copia de archivo estática del sitio antiguo, guardada fuera de línea, es un seguro barato.

Direcciones

Crea un mapa de redirecciones por sitio: ruta antigua, dirección nueva, redirección permanente. Los sitios Drupal suelen tener una ruta de sistema (node/123) y un alias; incluye ambos para las páginas que reciben tráfico. Si los sitios pasan a dominios nuevos, mantén los dominios antiguos y las redirecciones durante muchos meses.

Un orden de cambio que limita los daños

Fase	Sitios	Objetivo
1. Retirar	Sin responsable, sin tráfico	Archivar, redirigir, eliminar. Reduce de inmediato la red y la superficie de ataque.
2. Piloto	Dos o tres sitios sencillos con responsables implicados	Probar el proceso, las plantillas y el método de redirección.
3. Larga cola	Los sitios restantes con puntuación baja, por oleadas según responsable	Mover el grueso mientras el proceso está fresco.
4. Complejos	Sitios con puntuación alta	Migrar a Drupal actual u otro CMS completo con el tiempo de desarrollo adecuado.
5. Apagar	La instalación antigua	Solo cuando nada dependa de ella, incluidas las redirecciones.

Retirar primero parece ir al revés, pero funciona: cada sitio que sale de la red antigua es un sitio menos expuesto mientras avanzas con el resto.

Gobierno del nuevo entorno

La red antigua probablemente tenía un único guardián técnico. El nuevo entorno no debería recrear ese cuello de botella, pero tampoco dar a cada departamento un botón de publicar sin revisión. Antes de mover el primer sitio, decide quién es responsable de cada sitio, quién puede publicar, qué sitios necesitan aprobación antes de publicarse y quién puede añadir funciones como formularios o una tienda. Nuestra plantilla de política de gobierno web y la guía de flujo de aprobación de contenido tratan este tema.

Dónde encaja We.Inc y dónde no

We.Inc es un creador de sitios web de marca blanca para organizaciones que gestionan muchos sitios bajo una sola marca. Encaja con los sitios de puntuación baja de tu hoja, no con los de puntuación alta. No tiene importador de Drupal, ni equivalente a Views con filtros expuestos, ni tipos de contenido a medida; los sitios se reconstruyen con IA a partir de plantillas o de una descripción y luego tu equipo los revisa. Lo que sí ofrece para la larga cola:

Una marca (logo, colores, tipografías) aplicada a todos los sitios, con cada departamento como cliente de esa marca.
Valores predeterminados para toda la marca sobre lo que pueden hacer los sitios, ajustables por sitio, incluida la aprobación en un solo paso antes de que un sitio se publique.
Dominios propios por sitio y reglas de redirección en los ajustes SEO de cada sitio.
Descarga del código como ZIP o exportación a GitHub, para que el contenido que migras nunca quede atrapado.

La marca se define una vez y se aplica a todos los sitios departamentales, en lugar de imponerse mediante un tema compartido.

Interruptores predeterminados de la marca bajo el título Qué pueden hacer tus clientes, sobre una lista del equipo — Los valores predeterminados deciden qué puede hacer cada sitio nuevo, en lugar de activar módulo por módulo.

Una lista Esperando tu aprobación con un sitio y botones para aprobar y publicar o pedir cambios — Aprobación en un solo paso antes de que un sitio se publique, para los departamentos que necesitan una revisión. La solicitud pendiente en esta marca de demostración se preparó para la captura.

Un cuadro Exportar proyecto con pestañas GitHub, ZIP, Vercel y Dominio y una opción de repositorio privado — Cada sitio se puede exportar a un repositorio de GitHub o descargar como ZIP.

La accesibilidad no es automática: las páginas creadas con IA siguen necesitando que tu equipo las pruebe antes del lanzamiento, sobre todo en organismos públicos sujetos al ADA Title II (consulta nuestra guía sobre el plazo del Title II). Si tu hoja de auditoría muestra una larga cola de sitios sencillos, agenda una demo y tráela. Para la comparación general, lee creador de marca blanca frente a CMS empresarial; si parte de tus sitios está en WordPress, consulta salir de WordPress multisite.

Fuentes

Última revisión: 2026-10-25.

Drupal.org, Drupal 7 End of Life (fin del soporte de seguridad, Extended Security Support Provider Program).
Drupal.org, Multisite Drupal.
Drupal.org, Multisite folder structure in Drupal.
Drupal.org, Upgrading Drupal (Migrate API).

Preguntas frecuentes

¿Cuándo llegó Drupal 7 al fin de su vida útil?

Drupal.org indica que el soporte de seguridad de Drupal 7 terminó el 5 January 2025. Hay soporte de seguridad extendido de pago a través de proveedores del Extended Security Support Provider Program de la Drupal Association.

¿Puedo actualizar Drupal 7 multisite en el mismo lugar?

No en el sentido habitual. Pasar de Drupal 7 a una versión actual implica crear sitios nuevos y migrar el contenido, normalmente con la Migrate API de Drupal, sitio por sitio, porque cada sitio tiene su propia base de datos.

¿Qué sitios Drupal deberían quedarse en Drupal?

Los sitios con contenido estructurado que otras páginas consultan, filtros para usuarios, módulos a medida que hacen trabajo real, integraciones con sistemas internos, usuarios con sesión iniciada, equipos editoriales con varios roles o muchas páginas mantenidas activamente. Los sitios informativos sencillos son buenos candidatos para pasar a una plataforma más simple.

¿En qué orden deberían migrarse los sitios?

Retira primero los sitios sin responsable ni tráfico, luego haz un piloto con dos o tres sitios sencillos, mueve la larga cola por oleadas, migra los sitios complejos con el tiempo de desarrollo adecuado y apaga la instalación antigua solo cuando nada dependa de ella.

¿We.Inc puede importar sitios Drupal?

No. No hay importador de Drupal, y We.Inc no tiene tipos de contenido a medida ni listados filtrados al estilo de Views. Encaja con sitios departamentales e informativos sencillos, reconstruidos a partir de plantillas y revisados por tu equipo.