Migración de Drupal Multisite a Next.js Monorepo

Por Qué la Arquitectura Drupal Multisite Se Desmorona

Drupal multisite fue una idea inteligente en 2012. Un único código, módulos compartidos, crea un nuevo subsitio para cada departamento, ubicación de franquicia u oficina de agencia. Las universidades ejecutaban 15–30 subsitios de esta manera. Las organizaciones gubernamentales lo llevaron aún más lejos.

Luego llegó la realidad.

Cada actualización de módulo se convierte en un despliegue coordinado en todos los sitios. Un parche de seguridad para un subsitio significa riesgo de inactividad para todos ellos. Tu Escuela de Ingeniería quiere un módulo personalizado que entra en conflicto con el tema de la Escuela de Negocios. Tu franquicia en Denver necesita flujos de trabajo de contenido diferentes a la de Portland, pero comparten una configuración de base de datos que hace que el aislamiento sea casi imposible.

La arquitectura que te ahorró tiempo en el año uno cuesta el triple en el año tres.

Los Puntos Críticos Específicos Que Vemos

• Pesadillas de actualización de módulos: Un solo drush updb se propaga en cada subsitio. Un hook roto desactiva 20 sitios simultáneamente.
• Inconsistencia temática: Los temas base compartidos divergen a medida que cada sitio acumula anulaciones. La sub-marca se convierte en una guerra de trucos de especificidad CSS.
• Acoplamiento de base de datos: Las tablas compartidas significan que una migración mal configurada puede corromper datos en todos los inquilinos. Hemos visto esto suceder en un portal gubernamental estatal que ejecutaba 40+ sitios de agencias.
• Techo de rendimiento: El renderizado PHP del lado del servidor de Drupal alcanza un límite a escala. TTFB de 1.5–2.5 segundos es común en instalaciones multisite bajo carga.
• Escasez de talento: Encontrar desarrolladores de Drupal que entiendan la arquitectura multisite, Paragraphs y referencias de entidades personalizadas se vuelve más difícil cada año. El talento React/Next.js es abundante en comparación.
• Cumplimiento y seguridad: Las bases de código compartidas hacen que las auditorías de seguridad a nivel de sitio sean prácticamente imposibles — un factor decisivo para los requisitos de cumplimiento gubernamental y .edu.

Lo Que Obtienes: Monorepo Next.js con Middleware de Inquilino y RLS de Supabase

La arquitectura objetivo reemplaza tu Drupal multisite completo con una única aplicación Next.js usando el App Router, una estructura monorepo para código compartido y específico del inquilino, middleware para enrutamiento y autenticación, y Supabase con Row Level Security para verdadero aislamiento de datos.

Cómo Funciona el Middleware de Inquilino

El middleware de Next.js intercepta cada solicitud antes de que llegue a tus páginas. Para una universidad, esto se ve así:

/departments/engineering → tenant: engineering
/departments/business → tenant: business
/locations/denver → tenant: denver-franchise

El middleware extrae el slug del inquilino, establece el contexto RLS de Supabase, y la página se renderiza solo con los datos de ese inquilino. Sin consultas de base de datos compartida que se filtren entre departamentos. Sin despliegues separados por sitio.

Tu middleware.ts detecta el inquilino desde la ruta URL o subdominio, establece un parámetro app.current_tenant en la sesión de Supabase, y cada consulta posterior se limita automáticamente a los datos de ese inquilino.

Row Level Security de Supabase: Verdadero Aislamiento de Datos

Cada tabla — programs, faculty, events, news, pages — obtiene una columna tenant_id. Las políticas RLS aplican aislamiento a nivel de base de datos:

CREATE POLICY "tenant_isolation" ON programs
  FOR ALL
  USING (tenant_id = current_setting('app.current_tenant')::uuid);

Esto no es filtrado a nivel de aplicación que un error podría eludir. Es PostgreSQL que garantiza que una consulta desde el departamento de Ingeniería literalmente no puede ver registros del departamento de Negocios. Para sitios gubernamentales que manejan datos sensibles en agencias, ese es exactamente el aislamiento que los auditores quieren ver.

Arquitectura Monorepo

Usando Turborepo, la base de código se organiza en:

• packages/ui: Biblioteca de componentes compartida con sub-marca temática via CSS custom properties
• packages/config: Configuración de inquilino — logos, colores, estructuras de navegación, feature flags
• apps/web: La aplicación Next.js con rutas dinámicas [tenant]
• packages/db: Cliente de Supabase con helpers de consultas conscientes de RLS

Cada ubicación de franquicia o departamento obtiene su propio archivo de configuración, no su propio despliegue. Agrega una nueva ubicación agregando una configuración JSON y una fila en la tabla de inquilinos. Sin cambios de infraestructura.

Nuestro Proceso de Migración

Fase 1: Descubrimiento y Auditoría (1–2 Semanas)

Mapeamos cada subsitio de Drupal — tipos de contenido, taxonomías, menús, alias de URL, activos multimedia, roles de usuario e integraciones. Para universidades, eso significa catalogar conexiones SIS, configuraciones SAML SSO y webhooks de CRM. Para franquicias, es buscadores de ubicaciones, esquemas de SEO local e integraciones de reserva.

Habilitamos JSON:API de Drupal y ejecutamos exportaciones paginadas para entender la forma de datos completa: /jsonapi/node/program?page[limit]=50&include=field_department,field_faculty.

Para sitios Drupal 7 (aún comunes en gobierno), consultamos MySQL directamente ya que JSON:API no está disponible:

SELECT n.nid, n.title, fdb.body_value, fds.field_subtitle_value
FROM node n
JOIN field_data_body fdb ON fdb.entity_id = n.nid
JOIN field_data_field_subtitle fds ON fds.entity_id = n.nid
WHERE n.type = 'program';

Fase 2: Arquitectura de Datos y Configuración de Supabase (1–2 Semanas)

Diseñamos el esquema de Supabase con normalización adecuada e aislamiento de inquilino integrado desde el inicio. El almacenamiento entity-attribute-value de Drupal se aplana en tablas relacionales limpias. Las políticas RLS se escriben y prueban antes de que cualquier dato llegue.

La configuración de inquilino va en una tabla tenants con columnas para marca, feature flags, navegación y credenciales de integración.

Fase 3: Compilación de Aplicación Next.js (3–8 Semanas)

Esta es donde ocurre la mayor parte del desarrollo. Compilamos:

• Rutas de inquilino dinámicas: app/[tenant]/page.tsx, app/[tenant]/programs/[slug]/page.tsx
• Middleware: Detección de inquilino, autenticación, mapeo de redirección, manejo de locale
• Componentes compartidos: Buscadores de programas con búsqueda con facetas, directorios de facultad, calendarios de eventos, feeds de noticias — todos limitados por RLS
• Interfaces de administración: Paneles limitados por inquilino donde administradores de departamento gestionan solo su contenido
• Configuración ISR: revalidatePath para actualizaciones de contenido sin reconstrucciones completas
• Integración SAML SSO: Crítico para universidades y portales gubernamentales

Usamos desarrollo asistido por IA (Claude Code, Cursor) para acelerar la conversión de Paragraphs de Drupal a componentes React, que típicamente maneja 70–80% de asignaciones de tipos de contenido directas.

Fase 4: Preservación de SEO y Redirecciones (1 Semana)

Esto es innegociable. Las universidades acumulan miles de backlinks durante décadas. Los sitios gubernamentales tienen URLs regulatorias que deben permanecer funcionales.

Estrategia de Preservación de SEO

Exportamos cada alias de URL de Drupal — incluyendo rutas /node/1234 a las que los sitios externos inevitablemente enlazan. Estos se cargan en un mapa de redirección que el middleware de Next.js procesa en cada solicitud.

El middleware maneja:

• Redirecciones basadas en rutas: /school-of-business/mba-program → /departments/business/programs/mba
• Redirecciones de ID de nodo: /node/4521 → /departments/engineering/faculty/smith
• Consolidación de subdominio: business.university.edu → university.edu/departments/business
• Aplicación de URL canónica: Previniendo contenido duplicado en rutas de inquilino
• Inyección de datos estructurados: Esquemas JSON-LD específicos de departamento, marcado LocalBusiness para ubicaciones de franquicia

Verificamos cada redirección con rastreos automatizados antes de go-live. Search Console obtiene el mapa del sitio actualizado inmediatamente. Para sitios .edu, el tráfico orgánico típicamente se estabiliza dentro de 2–3 semanas y mejora dentro de 6–8 semanas a medida que las ganancias de Core Web Vitals tienen efecto.

Cronograma y Precios

Alcance	Cronograma	Inversión
Pequeño (1–5 subsitios, franquicia)	4–8 semanas	$50K–$100K
Mediano (10–15 subsitios, universidad)	8–12 semanas	$150K–$300K
Empresa (20–40+ subsitios, gobierno)	12–16 semanas	$300K–$600K

Los sitios Drupal 7 añaden ~20% debido al trabajo de extracción MySQL. SAML SSO e integraciones SIS/CRM añaden complejidad en el extremo superior. El alojamiento continuo en Vercel + Supabase típicamente funciona $200–$500/mes — una fracción de lo que estás pagando por infraestructura de alojamiento Drupal distribuida en múltiples subsitios.

El Resultado Final

Drupal multisite resolvió un problema real en su era. Pero mantener 20 subsitios en infraestructura PHP compartida, con un talento pool menguante y preocupaciones de cumplimiento crecientes, no es un plan a largo plazo. Un monorepo Next.js con RLS de Supabase te da verdadero aislamiento de inquilino, cargas de página sub-segundo, una experiencia de desarrollador que la gente realmente disfruta, y una arquitectura que escala editando un archivo de configuración en lugar de girar infraestructura.

Una app. Un despliegue. Cada inquilino aislado a nivel de base de datos. Esa es la migración que vale la pena hacer.