Drupal Multisite to Next.js Monorepo Migration

Drupal multisite was a clever idea in 2012. One codebase, shared modules, spin up a new subsite for each department, franchise location, or agency office. Universities ran 15–30 subsites this way. Government orgs pushed it even further.

Then reality set in.

Every module update becomes a coordinated deployment across all sites. A security patch for one subsite means downtime risk for all of them. Your School of Engineering wants a custom module that conflicts with the School of Business's theme. Your franchise in Denver needs different content workflows than the one in Portland, but they share a database configuration that makes isolation nearly impossible.

The architecture that saved you time in year one costs triple by year three.

The Specific Pain Points We See

• Module update nightmares: A single drush updb cascades across every subsite. One broken hook takes down 20 sites simultaneously.
• Theming inconsistency: Shared base themes drift apart as each site piles on overrides. Sub-branding turns into a war of CSS specificity hacks.
• Database coupling: Shared tables mean one misconfigured migration can corrupt data across tenants. We've seen this happen to a state government portal running 40+ agency sites.
• Performance ceiling: Drupal's server-side PHP rendering hits a wall at scale. TTFB of 1.5–2.5 seconds is common on multisite installs under load.
• Talent scarcity: Finding Drupal developers who understand multisite architecture, Paragraphs, and custom entity references gets harder every year. React/Next.js talent is abundant by comparison.
• Compliance and security: Shared codebases make site-level security audits nearly impossible — a dealbreaker for government and .edu compliance requirements.

What You Get: Next.js Monorepo with Tenant Middleware and Supabase RLS

The target architecture replaces your entire Drupal multisite with a single Next.js application using the App Router, a monorepo structure for shared and tenant-specific code, middleware for routing and authentication, and Supabase with Row Level Security for real data isolation.

How Tenant Middleware Works

Next.js middleware intercepts every request before it hits your pages. For a university, that looks like this:

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

The middleware extracts the tenant slug, sets the Supabase RLS context, and the page renders with only that tenant's data. No shared database queries leaking across departments. No separate deployments per site.

Your middleware.ts detects the tenant from the URL path or subdomain, sets an app.current_tenant parameter in the Supabase session, and every subsequent query automatically scopes to that tenant's data.

Supabase Row Level Security: Real Data Isolation

Every table — programs, faculty, events, news, pages — gets a tenant_id column. RLS policies enforce isolation at the database level:

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

This isn't application-level filtering that a bug could bypass. It's PostgreSQL enforcing that a query from the Engineering department literally cannot see Business department records. For government sites handling sensitive data across agencies, that's exactly the isolation auditors want to see.

Monorepo Architecture

Using Turborepo, the codebase organizes into:

• packages/ui: Shared component library with sub-brand theming via CSS custom properties
• packages/config: Tenant configuration — logos, colors, navigation structures, feature flags
• apps/web: The Next.js application with dynamic [tenant] routes
• packages/db: Supabase client with RLS-aware query helpers

Each franchise location or department gets its own configuration file, not its own deployment. Add a new location by adding a JSON config and a row in the tenants table. No infrastructure changes.

Our Migration Process

Phase 1: Discovery and Audit (1–2 Weeks)

We map every Drupal subsite — content types, taxonomies, menus, URL aliases, media assets, user roles, and integrations. For universities, that means cataloging SIS connections, SAML SSO configurations, and CRM webhooks. For franchises, it's location finders, local SEO schemas, and booking integrations.

We enable Drupal's JSON:API and run paginated exports to understand the full data shape: /jsonapi/node/program?page[limit]=50&include=field_department,field_faculty.

For Drupal 7 sites (still common in government), we query MySQL directly since JSON:API isn't available:

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';

Phase 2: Data Architecture and Supabase Setup (1–2 Weeks)

We design the Supabase schema with proper normalization and tenant isolation baked in from the start. Drupal's entity-attribute-value storage gets flattened into clean relational tables. RLS policies are written and tested before any data lands.

Tenant configuration goes into a tenants table with columns for branding, feature flags, navigation, and integration credentials.

Phase 3: Next.js Application Build (3–8 Weeks)

This is where the bulk of development happens. We build:

• Dynamic tenant routes: app/[tenant]/page.tsx, app/[tenant]/programs/[slug]/page.tsx
• Middleware: Tenant detection, authentication, redirect mapping, locale handling
• Shared components: Program finders with faceted search, faculty directories, event calendars, news feeds — all RLS-scoped
• Admin interfaces: Tenant-scoped dashboards where department admins manage only their content
• ISR configuration: revalidatePath for content updates without full rebuilds
• SAML SSO integration: Critical for universities and government portals

We use AI-assisted development (Claude Code, Cursor) to accelerate Drupal Paragraphs-to-React component conversion, which typically handles 70–80% of straightforward content type mappings.

Phase 4: SEO Preservation and Redirects (1 Week)

This is non-negotiable. Universities accumulate thousands of backlinks over decades. Government sites have regulatory URLs that must stay functional.

SEO Preservation Strategy

We export every URL alias from Drupal — including /node/1234 paths that external sites inevitably link to. These get loaded into a redirect map that Next.js middleware processes on every request.

The middleware handles:

• Path-based redirects: /school-of-business/mba-program → /departments/business/programs/mba
• Node ID redirects: /node/4521 → /departments/engineering/faculty/smith
• Subdomain consolidation: business.university.edu → university.edu/departments/business
• Canonical URL enforcement: Preventing duplicate content across tenant routes
• Structured data injection: Department-specific JSON-LD schemas, LocalBusiness markup for franchise locations

We verify every redirect with automated crawls before go-live. Search Console gets submitted with the updated sitemap immediately. For .edu sites, organic traffic typically stabilizes within 2–3 weeks and improves within 6–8 weeks as Core Web Vitals gains take effect.

Timeline and Pricing

Scope	Timeline	Investment
Small (1–5 subsites, franchise)	4–8 weeks	$50K–$100K
Medium (10–15 subsites, university)	8–12 weeks	$150K–$300K
Enterprise (20–40+ subsites, government)	12–16 weeks	$300K–$600K

Drupal 7 sites add ~20% due to MySQL extraction work. SAML SSO and SIS/CRM integrations add complexity on the upper end. Ongoing hosting on Vercel + Supabase typically runs $200–$500/month — a fraction of what you're paying for Drupal hosting infrastructure spread across multiple subsites.

The Bottom Line

Drupal multisite solved a real problem in its era. But maintaining 20 subsites on shared PHP infrastructure, with a shrinking talent pool and mounting compliance concerns, isn't a long-term plan. A Next.js monorepo with Supabase RLS gives you true tenant isolation, sub-second page loads, a developer experience people actually enjoy, and an architecture that scales by editing a config file instead of spinning up infrastructure.

One app. One deployment. Every tenant isolated at the database level. That's the migration worth making.