Migración de Drupal University a Next.js

Harvard ejecuta Drupal. También Yale, Princeton, Stanford y Duke. También tu universidad. Conoces el ciclo de actualización: D7 a D8 fue una reconstrucción completa. D8 a D9 requirió trabajo significativo. D9 a D10 rompió módulos contribuidos. D10 a D11 llegará a finales de 2026 con Symfony 7 y Twig 4. Por el costo de una migración más de Drupal, tu universidad puede pasar a Next.js + Supabase y nunca enfrentar otra migración forzada de CMS.

Esta es nuestra guía de migración específica para educación. Para una descripción general, consulta nuestra página de migración de Drupal. Esta página cubre lo que hace que las instalaciones de Drupal universitarias sean únicamente complejas — y cómo manejamos cada aspecto.

El ecosistema educativo de Drupal

Las instalaciones de Drupal universitarias no son como los sitios corporativos. Son sistemas dispersos y multiaccionarios — tipos de contenido específicos de educación, taxonomías profundamente anidadas, subsitios departamentales con editores independientes, integraciones con sistemas de información estudiantil. Un enfoque genérico de migración fracasará.

Tipos de contenido específicos de educación

Tu instancia de Drupal probablemente tiene 10+ tipos de contenido personalizado construidos para educación superior:

• Program — información de grado, certificado y curso con horas de crédito, matrícula, modalidad de entrega, resultados profesionales
• Faculty — perfiles con intereses de investigación, publicaciones, cursos impartidos, horas de oficina
• Department — estructura jerárquica (Escuela de Ingeniería → Departamento de CS → Laboratorio de IA)
• Event — calendario académico, eventos públicos, ceremonia de graduación, eventos específicos de departamento
• News — noticias universitarias, noticias departamentales, anuncios de investigación, comunicados de prensa
• Page — cientos de páginas de contenido básico (acerca de, admisiones, ayuda financiera)
• Publication — artículos de investigación, informes, documentos de política con enlaces DOI
• Job Posting — posiciones de facultad, posiciones de personal, empleo estudiantil
• Profile — entradas de directorios de personal para empleados no docentes
• Testimonial — historias de éxito de estudiantes y antiguos alumnos

Cada uno se asigna a una tabla de Supabase con diseño relacional apropiado. Los programas obtienen degree_level, subject_area_id, delivery_mode, tuition y career_outcomes como JSONB. El personal docente obtiene una clave externa department_id, publications como JSONB y research_areas como array. Los departamentos usan parent_id para jerarquía autorreferencial.

Esto no es una exportación de contenido plano. Es un esquema relacional adecuado que hace que tus datos sean consultables de formas que Drupal Views nunca pudo.

Drupal Views → Componentes de servidor Next.js

Los sitios universitarios dependen mucho de Drupal Views para listados filtrables. Cada uno de estos se convierte en una página Next.js más rápida y flexible:

• Program Finder — Drupal View filtrando por tema, nivel de grado, campus → página Next.js /programs con consulta de Supabase + estado de filtro basado en URL. Los estudiantes prospectivos filtran por área de interés y obtienen resultados instantáneos.
• Faculty Directory — Drupal View filtrando por departamento, área de investigación → página Next.js /faculty con búsqueda de texto completo y filtrado de departamentos contra Supabase.
• Event Calendar — Drupal View filtrando por fecha, departamento, tipo → página Next.js /events con filtrado de rango de fecha y exportación iCal.
• News Feed — Drupal View filtrando por departamento, categoría → página Next.js /news con ISR para que los nuevos artículos aparezcan dentro de 60 segundos de la publicación.
• Job Board — Drupal View filtrando por departamento, tipo de empleo → página Next.js /careers extrayendo de Supabase con lógica de fecha de cierre.

La diferencia: Drupal Views genera cargas de página completa en cada cambio de filtro. Los componentes de servidor Next.js con Supabase devuelven resultados filtrados en menos de 100ms sin recarga de página completa.

Taxonomía de Drupal → Relaciones de Supabase

Los vocabularios de taxonomía de Drupal se asignan a tablas relacionales apropiadas:

• Vocabulario Subject Areas → tabla subject_areas, programs.subject_area_id FK
• Vocabulario Departments → tabla departments con parent_id para jerarquía
• Vocabulario Campus Locations → tabla campuses, programs.campus_id FK
• Vocabulario Research Areas → tabla research_areas + tabla de unión faculty_research_areas
• Vocabulario Event Types → columna enum event_type o tabla de búsqueda

Los campos de Entidad de referencia de Drupal se convierten en claves externas apropiadas. Las relaciones de muchos a muchos (facultad ↔ áreas de investigación) obtienen tablas de unión. El modelo de datos se vuelve explícito en lugar de ocultarse detrás de la API de entidades de Drupal.

Paragraphs + Layout Builder → Bloques de componentes

Los Paragraphs de Drupal son el mayor punto de dolor en las migraciones universitarias. Tus editores han construido páginas usando docenas de tipos de párrafo: banners hero, secciones de estadísticas, destacados de facultad, grillas de tarjetas de programas, acordeones de preguntas frecuentes, videos incrustados, bloques de llamada a la acción.

Los almacenamos como JSONB en la columna pages.blocks de Supabase:

[
  {"type": "hero", "title": "...", "subtitle": "...", "image": "...", "cta_url": "..."},
  {"type": "stats", "items": [{"number": "15:1", "label": "Relación estudiante-facultad"}]},
  {"type": "program_cards", "program_ids": [12, 45, 78]},
  {"type": "faculty_spotlight", "faculty_id": 234}
]

Un registro de componentes Next.js renderiza cada tipo de bloque. Los editores administran bloques a través de Payload CMS o una interfaz de administración personalizada. La misma flexibilidad que Paragraphs, renderizado más rápido y sin espera de reconstrucción de caché de Drupal.

Subsitios de departamentos multisitio

Las universidades grandes ejecutan 15–30 subsitios de Drupal — Escuela de Negocios, Escuela de Ingeniería, Facultad de Artes y Ciencias — cada uno en instalaciones de Drupal separadas o Drupal multisitio. Esto es una pesadilla operativa: actualizaciones de módulos en 20 sitios, temas inconsistentes, infraestructura duplicada.

Consolidamos todo en una aplicación Next.js con rutas /departments/[slug]. Cada departamento obtiene su propia sección con identidad de submarca (colores de acento personalizados dentro del sistema de diseño de la universidad). Páginas, noticias, eventos y facultad del departamento se limitan a su departamento.

La clave: Row Level Security (RLS) de Supabase. Los editores de departamentos solo ven y editan contenido donde department_id coincide con su departamento asignado. El editor web de la Escuela de Negocios no puede editar accidentalmente contenido de Ingeniería. RLS lo refuerza en el nivel de base de datos — no en código de aplicación, no en permisos de CMS. Es estructural.

Portal de estudiantes e integración SSO

Tu sitio actual de Drupal autentica estudiantes a través de CAS o Shibboleth, conectándose a tu proveedor de identidad (ADFS, Okta o un IdP de Shibboleth administrado por la universidad). Los estudiantes ven contenido personalizado: sus requisitos de programa, información del asesor, recursos específicos del departamento.

Supabase Auth admite SAML 2.0 nativamente. Configuramos el proveedor de identidad de tu universidad como un proveedor SAML en Supabase. El flujo:

1. El estudiante hace clic en "Iniciar sesión" en el sitio Next.js
2. Redirección al IdP de la universidad (Shibboleth/ADFS/Okta)
3. El estudiante se autentica con las credenciales de la universidad
4. El IdP envía la aserción SAML de vuelta a Supabase
5. Supabase emite un JWT con el rol y departamento del estudiante
6. Las políticas RLS controlan qué datos ven

Sin código de autenticación personalizado. Sin dolores de cabeza de gestión de sesiones. El JWT lleva reclamaciones y Supabase RLS las lee.

Migración de rol de usuario

Los roles de Drupal en universidades — Administrador del sitio, Editor web, Editor de departamento, Facultad, Estudiante, Antiguo alumno — se asignan a una tabla user_roles en Supabase con asignaciones de rol por usuario. Las políticas RLS hacen referencia a estos roles:

• Site Admin: lectura/escritura completa en todas las tablas
• Department Editor: lectura/escritura donde department_id = auth.jwt()->department_id
• Faculty: actualizar su propio perfil, agregar publicaciones
• Student: solo lectura en contenido público, datos del panel de control personalizado

La migración educativa de 7 fases

Fase 1: Descubrimiento y auditoría de contenido (1–2 semanas)

Rastro de Screaming Frog de cada URL. Análisis de tráfico de Google Search Console para identificar tus páginas de mayor valor. Inventario de tipo de contenido en todos los subsitios. Auditoría de integración: ¿qué se conecta a Drupal? ¿Banner? ¿PeopleSoft? ¿Canvas? ¿Slate? Línea de base de accesibilidad con puntuaciones de Lighthouse y cualquier queja de ADA existente.

Fase 2: Diseño de arquitectura y esquema (1 semana)

Esquema de Supabase con tablas, relaciones y políticas RLS. Estructura de rutas Next.js. Jerarquía de navegación. Decisión en la interfaz de administración: Payload CMS para editores no técnicos o un panel de Supabase personalizado. Arquitectura de integración para SSO, extracciones de datos SIS y webhooks de CRM.

Fase 3: Exportación de datos desde Drupal (1–2 semanas)

D8/D9/D10: exportación JSON:API a través de /jsonapi/node/program?page[limit]=50, paginada en cada tipo de contenido. D7: consultas MySQL directo contra tablas de campo de Drupal. Exportación de medios desde sistemas de archivos public:// y private://. Exportaciones de usuario y taxonomía. Extracción de estructura de menú.

Fase 4: Construcción (3–8 semanas)

Aplicación Next.js con todas las plantillas de página. Tablas de Supabase pobladas con datos transformados y políticas RLS activas. Buscador de programas con filtros facetados. Directorio de facultad con búsqueda. Secciones de departamento. Portal de estudiantes con SSO. Interfaz de administración. Todas las integraciones — extracción de datos SIS, webhooks de CRM, reserva de visita al campus.

Fase 5: Importación de contenido y validación (1–2 semanas)

Transformación de exportaciones de Drupal en scripts de inserción de Supabase. Importación de todos los tipos de contenido. Carga de medios a Supabase Storage o Vercel Blob. Reescritura de URLs de medios en contenido. Revisión del 10% de cada tipo de contenido. Prueba de cada filtro, búsqueda y ruta de navegación.

Fase 6: Mapeo de redirección (1 semana)

Esto es crítico para universidades. Tu dominio .edu tiene miles de enlaces de retroceso de otras instituciones educativas, sitios del gobierno y bases de datos de investigación. Perder esos enlaces de retroceso es catastrófico para la autoridad de SEO. Mapeamos cada URL de Drupal — alias, rutas del sistema (/node/1234) y URLs de subsitio — a nuevas rutas de Next.js. Implementadas a través del middleware de Next.js para una capacidad de redirección ilimitada.

Fase 7: Lanzamiento y monitoreo (continuo)

Cambio de DNS. Nueva presentación del mapa del sitio a Google Search Console. Monitoreo diario de 404 durante los primeros 30 días. Capacitación del personal para Payload CMS o administración personalizada. Capacitación de administración del departamento. Capacitación de flujo de autoactualización de facultad. 30 días de hipercare con monitoreo diario y verificaciones semanales con tu equipo web.

Precios

Tipo de institución	Páginas	Alcance	Cronograma	Inversión
Colegio comunitario	Menos de 500	Buscador de programas, directorio básico, noticias	6–8 semanas	$50–80K
Universidad mediana	500–2,000	Buscador de programas, directorio de facultad, secciones de departamento, eventos	8–12 semanas	$80–150K
Universidad grande	2,000+	Múltiples campus, subsitios de departamento, portal de estudiantes, SSO, i18n	10–16 semanas	$120–200K

Por qué ahora: el reloj de D11 está marcando

Drupal 11 llega a finales de 2026 con Symfony 7 y Twig 4. Las universidades en D10 enfrentan la decisión de migración en los próximos 6–12 meses. Una migración de D10 a D11 cuesta mínimo $30–60K — y enfrentarás D12 en otros 3–4 años.

Una migración de Next.js + Supabase cuesta $50–200K dependiendo del alcance, pero el costo total de propiedad de 5 años es más bajo que quedarse con Drupal. Sin actualizaciones forzadas. Sin rotura de módulos contribuidos. Sin avisos de seguridad de Drupal que requieran parches de emergencia. Tu framework se actualiza en tu calendario, no en el de Drupal.

Por el costo de una migración más de Drupal, hazla tu última.