Drupal University Migration to Next.js

Harvard runs Drupal. So does Yale, Princeton, Stanford, and Duke. So does your university. You know the upgrade cycle: D7 to D8 was a complete rebuild. D8 to D9 required significant work. D9 to D10 broke contributed modules. D10 to D11 is coming late 2026 with Symfony 7 and Twig 4. For the cost of one more Drupal migration, your university can move to Next.js + Supabase and never face a forced CMS migration again.

This is our education-specific migration guide. For a general overview, see our Drupal migration page. This page covers what makes university Drupal installations uniquely complex — and how we handle every piece.

The Drupal Higher-Ed Ecosystem

University Drupal installations aren't like corporate sites. They're sprawling, multi-stakeholder systems — education-specific content types, deeply nested taxonomies, department subsites with independent editors, integrations with student information systems. A generic migration approach will fail.

Education-Specific Content Types

Your Drupal instance likely has 10+ custom content types built for higher ed:

• Program — degree, certificate, and course information with credit hours, tuition, delivery mode, career outcomes
• Faculty — profiles with research interests, publications, courses taught, office hours
• Department — hierarchical structure (School of Engineering → CS Department → AI Lab)
• Event — academic calendar, public events, commencement, department-specific events
• News — university news, department news, research announcements, press releases
• Page — hundreds of basic content pages (about, admissions, financial aid)
• Publication — research papers, reports, policy documents with DOI links
• Job Posting — faculty positions, staff positions, student employment
• Profile — staff directory entries for non-faculty employees
• Testimonial — student and alumni success stories

Each maps to a Supabase table with proper relational design. Programs get degree_level, subject_area_id, delivery_mode, tuition, and career_outcomes as JSONB. Faculty get a department_id foreign key, publications as JSONB, and research_areas as an array. Departments use parent_id for self-referential hierarchy.

This isn't a flat content dump. It's a proper relational schema that makes your data queryable in ways Drupal Views never could.

Drupal Views → Next.js Server Components

University sites lean heavily on Drupal Views for filterable listings. Every one of these becomes a faster, more flexible Next.js page:

• Program Finder — Drupal View filtering by subject, degree level, campus → Next.js /programs page with Supabase query + URL-based filter state. Prospective students filter by interest area and get instant results.
• Faculty Directory — Drupal View filtering by department, research area → Next.js /faculty page with full-text search and department filtering against Supabase.
• Event Calendar — Drupal View filtering by date, department, type → Next.js /events page with date range filtering and iCal export.
• News Feed — Drupal View filtering by department, category → Next.js /news page with ISR so new articles appear within 60 seconds of publishing.
• Job Board — Drupal View filtering by department, employment type → Next.js /careers page pulling from Supabase with closing date logic.

The difference: Drupal Views generate full page loads on every filter change. Next.js server components with Supabase return filtered results in under 100ms with no full page reload.

Drupal Taxonomy → Supabase Relations

Drupal taxonomy vocabularies map to proper relational tables:

• Subject Areas vocabulary → subject_areas table, programs.subject_area_id FK
• Departments vocabulary → departments table with parent_id for hierarchy
• Campus Locations vocabulary → campuses table, programs.campus_id FK
• Research Areas vocabulary → research_areas table + faculty_research_areas join table
• Event Types vocabulary → event_type enum column or lookup table

Drupal's Entity Reference fields become proper foreign keys. Many-to-many relationships (faculty ↔ research areas) get join tables. The data model becomes explicit rather than hidden behind Drupal's entity API.

Paragraphs + Layout Builder → Component Blocks

Drupal Paragraphs are the biggest pain point in university migrations. Your editors have built pages using dozens of paragraph types: hero banners, statistics sections, faculty spotlights, program card grids, accordion FAQs, embedded videos, call-to-action blocks.

We store these as JSONB in Supabase's pages.blocks column:

[
  {"type": "hero", "title": "...", "subtitle": "...", "image": "...", "cta_url": "..."},
  {"type": "stats", "items": [{"number": "15:1", "label": "Student-Faculty Ratio"}]},
  {"type": "program_cards", "program_ids": [12, 45, 78]},
  {"type": "faculty_spotlight", "faculty_id": 234}
]

A Next.js component registry renders each block type. Editors manage blocks through Payload CMS or a custom admin interface. Same flexibility as Paragraphs, faster rendering, and no Drupal cache rebuild waiting.

Multi-Site Department Subsites

Large universities run 15–30 Drupal subsites — School of Business, School of Engineering, College of Arts & Sciences — each on separate Drupal installations or Drupal multisite. This is an operational nightmare: module updates across 20 sites, inconsistent theming, duplicated infrastructure.

We consolidate everything into one Next.js application with /departments/[slug] routes. Each department gets its own section with sub-brand identity (custom accent colors within the university design system). Department pages, news, events, and faculty all scope to their department.

The key: Supabase Row Level Security (RLS). Department editors only see and edit content where department_id matches their assigned department. The School of Business web editor can't accidentally edit Engineering content. RLS enforces this at the database level — not in application code, not in CMS permissions. It's structural.

Student Portal and SSO Integration

Your current Drupal site authenticates students via CAS or Shibboleth, connecting to your identity provider (ADFS, Okta, or a university-managed Shibboleth IdP). Students see personalized content: their program requirements, advisor information, department-specific resources.

Supabase Auth supports SAML 2.0 natively. We configure your university's identity provider as a SAML provider in Supabase. The flow:

1. Student clicks "Sign In" on the Next.js site
2. Redirect to university IdP (Shibboleth/ADFS/Okta)
3. Student authenticates with university credentials
4. IdP sends SAML assertion back to Supabase
5. Supabase issues a JWT with the student's role and department
6. RLS policies control what data they see

No custom authentication code. No session management headaches. The JWT carries claims, and Supabase RLS reads them.

User Role Migration

Drupal roles at universities — Site Admin, Web Editor, Department Editor, Faculty, Student, Alumni — map to a user_roles table in Supabase with per-user role assignments. RLS policies reference these roles:

• Site Admin: full read/write on all tables
• Department Editor: read/write where department_id = auth.jwt()->department_id
• Faculty: update their own profile, add publications
• Student: read-only on public content, personalized dashboard data

The 7-Phase Education Migration

Phase 1: Discovery and Content Audit (1–2 weeks)

Screaming Frog crawl of every URL. Google Search Console traffic analysis to identify your highest-value pages. Content type inventory across all subsites. Integration audit: what connects to Drupal? Banner? PeopleSoft? Canvas? Slate? Accessibility baseline with Lighthouse scores and any existing ADA complaints.

Phase 2: Architecture and Schema Design (1 week)

Supabase schema with tables, relationships, and RLS policies. Next.js route structure. Navigation hierarchy. Decision on admin interface: Payload CMS for non-technical editors or a custom Supabase dashboard. Integration architecture for SSO, SIS data pulls, and CRM webhooks.

Phase 3: Data Export from Drupal (1–2 weeks)

D8/D9/D10: JSON:API export via /jsonapi/node/program?page[limit]=50, paginated through every content type. D7: direct MySQL queries against Drupal's field tables. Media export from public:// and private:// file systems. User and taxonomy exports. Menu structure extraction.

Phase 4: Build (3–8 weeks)

Next.js application with all page templates. Supabase tables populated with transformed data and RLS policies active. Program finder with faceted filters. Faculty directory with search. Department sections. Student portal with SSO. Admin interface. All integrations — SIS data pull, CRM webhooks, campus tour booking.

Phase 5: Content Import and Validation (1–2 weeks)

Transform Drupal exports to Supabase insert scripts. Import all content types. Upload media to Supabase Storage or Vercel Blob. Rewrite media URLs in content. Spot-check 10% of each content type. Test every filter, search, and navigation path.

Phase 6: Redirect Mapping (1 week)

This is critical for universities. Your .edu domain has thousands of backlinks from other educational institutions, government sites, and research databases. Losing those backlinks is catastrophic for SEO authority. We map every Drupal URL — aliases, system paths (/node/1234), and subsite URLs — to new Next.js routes. Implemented via Next.js middleware for unlimited redirect capacity.

Phase 7: Launch and Monitoring (ongoing)

DNS cutover. New sitemap submission to Google Search Console. Daily 404 monitoring for the first 30 days. Staff training for Payload CMS or custom admin. Department admin training. Faculty self-update workflow training. 30-day hypercare with daily monitoring and weekly check-ins with your web team.

Pricing

Institution Type	Pages	Scope	Timeline	Investment
Community College	Under 500	Program finder, basic directory, news	6–8 weeks	$50–80K
Mid-Size University	500–2,000	Program finder, faculty directory, department sections, events	8–12 weeks	$80–150K
Large University	2,000+	Multi-campus, department subsites, student portal, SSO, i18n	10–16 weeks	$120–200K

Why Now: The D11 Clock Is Ticking

Drupal 11 arrives late 2026 with Symfony 7 and Twig 4. Universities on D10 face the migration decision in the next 6–12 months. A D10-to-D11 migration runs $30–60K minimum — and you'll face D12 in another 3–4 years.

A Next.js + Supabase migration runs $50–200K depending on scope, but the 5-year total cost of ownership is lower than staying on Drupal. No forced upgrades. No contributed module breakage. No Drupal security advisories requiring emergency patches. Your framework updates on your schedule, not Drupal's.

For the cost of one more Drupal migration, make it your last one.