Your Drupal 7 multi-site instance runs 23 franchise locations on shared infrastructure that hasn't seen a security patch since February 2025. You're staring at a D7-to-D10 migration that's actually 23 separate rebuilds—each location's custom modules, each theme override, each content type rebuilt by hand. Drupal 9 teams faced this exact rebuild pain moving from D7. Now D10-to-D11 brings another wave of breaking changes, and your network multiplies every compatibility failure by the number of sites you manage. We've pulled multi-site networks off Drupal and onto Next.js + Supabase in under 90 days. The architecture difference explains why teams are making this permanent move—and why going back becomes unthinkable once you see deployment at scale.

I want to be clear upfront: Drupal is not bad software. It powered — and still powers — some of the most important websites on the internet. But multi-site Drupal in 2026 is a fundamentally different proposition than it was in 2015. The ecosystem has shifted, the economics have changed, and the developer talent pool has migrated to JavaScript. If you're an IT team or agency managing a Drupal multi-site network for a university, hospital system, government agency, or multi-location business, this article is for you.

Table of Contents

Drupal Multi-Site Is Dead: What Multi-Location Businesses Use Instead

Why Drupal Multi-Site Is Dying

Drupal multi-site was an elegant idea in 2010. One codebase, one server, multiple sites sharing modules and themes. For universities with 50 department sites or hospital systems with 30 clinic locations, it was the logical choice. You could manage everything from a single admin panel, push updates once, and maintain consistency across the network.

That model has cracked under the weight of Drupal's own evolution.

The core problem isn't any single issue — it's the compounding effect of five simultaneous pressures: upgrade costs, module compatibility, talent scarcity, performance expectations, and hosting economics. Each one alone would be manageable. Together, they make Drupal multi-site untenable for most organizations.

The Upgrade Tax That Breaks Budgets

Drupal 7 reached end-of-life in January 2025. That's not a soft deprecation — it means no more security patches, no more community support, and active vulnerability exposure for every site in your network. If you're still running D7 multi-site, you're carrying real risk.

But here's the part that burns: upgrading from Drupal 7 to Drupal 10 or 11 is not an upgrade. It's a rebuild. Drupal 8 rewrote the entire architecture, moving from a procedural PHP model to Symfony-based object-oriented PHP. Your D7 themes? Gone. Your custom modules? Rewrite them. Your template files? Start over with Twig.

On a single site, that's a painful but manageable project. On a 20-site multi-site network, it's 20 rebuilds. Even if sites share a base theme, each location likely has customizations — custom content types, Views configurations, blocks, and Paragraph type layouts that need individual attention.

The numbers tell the story:

  • D7 to D10 migration for a single site: $30,000–$80,000 depending on complexity
  • D7 to D10 migration for a 20-site network: $200,000–$600,000+ (not a simple multiplier due to shared code, but far from a single-site cost)
  • D10 to D11 upgrade: Less dramatic but still involves breaking changes around Symfony 7 components, PHP 8.3 requirements, and deprecated API removals

And the cycle doesn't stop. Drupal has committed to annual major releases, which means annual breaking changes. Each version bumps the minimum PHP version, deprecates APIs, and requires module authors to update their code. For a multi-site network, this creates a perpetual upgrade treadmill.

I've talked to IT directors who describe their Drupal upgrade budget as "the cost of standing still." They're spending six figures just to maintain feature parity — not to add anything new.

The Module Compatibility Trap

Drupal's power comes from its contributed module ecosystem. A typical multi-site installation might use 40-80 contributed modules — Views, Paragraphs, Webform, Pathauto, Metatag, Media, Layout Builder, and dozens more.

Here's the catch: in a multi-site setup, all sites share the same codebase. That means every module must be compatible with every site simultaneously. When a module author drops support for Drupal 9 (which is already end-of-life as of November 2023) and only supports D10/D11, you can't selectively upgrade modules for one site. You upgrade the module for all sites, or none.

This creates a dependency gridlock. You want to upgrade Module A because it has a critical security patch, but Module A's new version requires Drupal 10.3+, and your codebase is on 10.1 because Module B hasn't released a 10.3-compatible version yet. Multiply this by 60 modules and 20 sites, and you're spending entire sprints on compatibility testing.

The contributed module ecosystem is also shrinking. According to Drupal.org statistics, the number of actively maintained modules has been declining since 2020. Many module maintainers have moved to other platforms or simply stopped updating their modules. The Drupal community is smaller than it was five years ago, and that trend is accelerating.

Drupal Multi-Site Is Dead: What Multi-Location Businesses Use Instead - architecture

The Drupal Talent Shortage Is Real

This is the one that agency owners and IT directors feel most acutely. Finding Drupal developers in 2026 is genuinely difficult.

Drupal requires a specific skill set: PHP (advanced), Symfony, Twig templating, Drupal's entity/field system, the plugin API, configuration management (YAML-based), and the render pipeline. It's not that these are bad skills — they're just increasingly rare. Developers coming out of bootcamps and CS programs are learning React, Next.js, and TypeScript. They're not learning Drupal.

The market rates reflect this:

Role Drupal Developer Next.js Developer
Junior $80–$120/hr $60–$90/hr
Mid-level $120–$170/hr $80–$130/hr
Senior $170–$220/hr $120–$170/hr
Available talent pool Shrinking Growing rapidly
Average time to hire 6-12 weeks 2-4 weeks

You're paying more for developers who are harder to find, working in an ecosystem with fewer community resources. That's not a sustainable position for any organization.

We've built our Next.js development practice specifically because this is where the talent and the demand have converged.

Performance: PHP Rendering vs. Edge Delivery

Drupal serves pages through PHP rendering. Each request hits the server, bootstraps Drupal, queries the database, runs through the render pipeline, and returns HTML. Even with caching layers (Varnish, Redis, Drupal's internal page cache), the architecture has a performance ceiling.

Typical Drupal Lighthouse scores on production multi-site installations:

  • Performance: 55–70
  • LCP (Largest Contentful Paint): 2.5–4.5 seconds
  • CLS (Cumulative Layout Shift): 0.1–0.3
  • TTFB (Time to First Byte): 800ms–2.5s (depending on hosting)

Next.js on Vercel with ISR (Incremental Static Regeneration) or SSG (Static Site Generation):

  • Performance: 90–100
  • LCP: 0.8–1.5 seconds
  • CLS: 0–0.05
  • TTFB: 50–200ms (edge-cached)

This isn't a marginal difference. It's a generation gap. Google's Core Web Vitals are a ranking factor, and the performance delta between Drupal and a modern frontend framework on edge infrastructure is measurable in search rankings.

For multi-location businesses, this matters even more. Each location page is a local SEO landing page. If your Dallas clinic page loads in 4 seconds while your competitor's loads in 1.2 seconds, Google notices.

Cost Comparison: Drupal Hosting vs. Modern Stack

Drupal multi-site requires managed Drupal hosting. You need PHP, MySQL/MariaDB, server-level caching, and ideally a platform that understands Drupal's file structure and multisite configuration. The main options:

  • Acquia Cloud: $800–$3,000/month for multi-site
  • Pantheon: $300–$1,500/month depending on plan and site count
  • Platform.sh: $500–$2,000/month
  • Self-managed on AWS/GCP: $200–$800/month for infrastructure, plus $2,000–$5,000/month for a sysadmin to manage it

Our recommended modern stack for multi-location sites:

  • Vercel Pro: $20/month
  • Supabase Pro: $25/month
  • Total: $45/month

That's $540/year vs. $3,600–$36,000/year. Even if you add a CDN for media ($20/month) and a monitoring tool ($30/month), you're at $1,140/year. The hosting savings alone often pay for the migration within the first year.

To be fair: Vercel and Supabase pricing scales with usage. A high-traffic multi-site might see Vercel bills of $100–$300/month and Supabase at $50–$100/month. Even at the high end, you're at $4,800/year — still a fraction of managed Drupal hosting.

Head-to-Head: Drupal Multi-Site vs. Next.js + Supabase

| Factor | Drupal Multi-Site | Next.js + Supabase | |--------|------------------|--------------------|n| Upgrade cost (per major version) | $200K–$600K for 20 sites | $0–$5K (minor dependency updates) | | Annual hosting cost | $3,600–$36,000 | $540–$4,800 | | Developer hourly rate | $120–$220/hr | $80–$170/hr | | Time to add new location | 2–4 weeks | 1–3 days | | Security posture | Requires constant patching, shared codebase = shared risk | Statically generated pages, no server to exploit | | Lighthouse performance score | 55–70 | 90–100 | | i18n support | Drupal i18n module (complex config) | next-intl + locale columns (straightforward) | | Content editing | Drupal admin UI | Supabase dashboard, custom admin, or headless CMS | | Deployment | SSH/Git deploy to single server | Git push → Vercel auto-deploy with preview URLs |

The Migration Path: Drupal to Next.js + Supabase

Here's the actual process we follow when migrating Drupal multi-site networks. It's not a weekend project, but it's well-defined and predictable.

Step 1: Content Export from Drupal

The approach depends on your Drupal version.

Drupal 10/11: Use the JSON:API module (included in core) to export content programmatically:

# Export all nodes of type 'location'
curl https://your-drupal-site.com/jsonapi/node/location?page[limit]=50 \
  -H "Authorization: Basic BASE64_CREDENTIALS" \
  > locations.json

Drupal 7: There's no REST API built in. You'll need to query the database directly. Drupal 7 stores content across multiple tables — node, field_data_*, field_revision_*, and taxonomy tables.

-- Export D7 location nodes with field data
SELECT 
  n.nid,
  n.title,
  n.created,
  n.changed,
  fdb.body_value AS body,
  fda.field_address_value AS address,
  fdp.field_phone_value AS phone,
  fdl.field_latitude_value AS latitude,
  fdl.field_longitude_value AS longitude
FROM node n
LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
LEFT JOIN field_data_field_address fda ON n.nid = fda.entity_id
LEFT JOIN field_data_field_phone fdp ON n.nid = fdp.entity_id
LEFT JOIN field_data_field_location fdl ON n.nid = fdl.entity_id
WHERE n.type = 'location'
AND n.status = 1;

This is messy — Drupal 7's EAV (Entity-Attribute-Value) field storage means you're joining a separate table for every field. But it works.

Step 2: Transform Drupal Data to Supabase Schema

Drupal's data model doesn't map 1:1 to a clean relational schema. Here's how we handle the key conversions:

Paragraph Types → JSONB Fields

Drupal Paragraphs store flexible content layouts as referenced entities. In Supabase, we use JSONB columns:

CREATE TABLE locations (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  slug TEXT UNIQUE NOT NULL,
  site_id TEXT NOT NULL, -- identifies which location/site
  title TEXT NOT NULL,
  body TEXT,
  address JSONB, -- {street, city, state, zip, country}
  phone TEXT,
  coordinates GEOGRAPHY(POINT, 4326),
  page_sections JSONB, -- replaces Paragraph types
  meta JSONB, -- SEO metadata
  locale TEXT DEFAULT 'en',
  published BOOLEAN DEFAULT false,
  created_at TIMESTAMPTZ DEFAULT now(),
  updated_at TIMESTAMPTZ DEFAULT now()
);

The page_sections JSONB field stores what Drupal Paragraphs used to handle:

[
  {
    "type": "hero",
    "heading": "Welcome to Our Dallas Location",
    "image": "/images/dallas-hero.webp",
    "cta": {"text": "Book Appointment", "url": "/dallas/book"}
  },
  {
    "type": "text_block",
    "body": "<p>Our Dallas clinic has served the community since 2008...</p>"
  },
  {
    "type": "staff_grid",
    "staff_ids": ["uuid-1", "uuid-2", "uuid-3"]
  }
]

Drupal Views → Supabase Queries + Server Components

Drupal Views is basically a visual query builder. In the new stack, those become Supabase queries called from Next.js Server Components:

// app/[location]/page.tsx -- replaces a Drupal View
import { createClient } from '@/lib/supabase/server'

export default async function LocationPage({ 
  params 
}: { 
  params: { location: string } 
}) {
  const supabase = await createClient()
  
  const { data: location } = await supabase
    .from('locations')
    .select('*')
    .eq('slug', params.location)
    .eq('published', true)
    .single()

  if (!location) notFound()

  const { data: nearbyLocations } = await supabase
    .rpc('nearby_locations', {
      lat: location.coordinates.coordinates[1],
      lng: location.coordinates.coordinates[0],
      limit_count: 3
    })

  return (
    <main>
      <LocationHero location={location} />
      <SectionRenderer sections={location.page_sections} />
      <NearbyLocations locations={nearbyLocations} />
    </main>
  )
}

Drupal Users → Supabase Auth

If your Drupal sites have user authentication (patient portals, student logins, etc.), Supabase Auth handles this with built-in support for email/password, magic links, OAuth providers, and Row Level Security:

-- Row Level Security: users can only see their own data
ALTER TABLE patient_records ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Users see own records" ON patient_records
  FOR SELECT USING (auth.uid() = user_id);

Drupal i18n → next-intl + Locale Columns

Drupal's multilingual system is powerful but complex — content translation, interface translation, configuration translation, and language detection all run through separate subsystems. With next-intl and Supabase, it's simpler:

// Query localized content
const { data } = await supabase
  .from('locations')
  .select('*')
  .eq('slug', params.location)
  .eq('locale', params.locale)
  .single()

Taxonomy → Tags/Categories in Supabase

Drupal's taxonomy vocabularies become simple lookup tables with a junction table for many-to-many relationships:

CREATE TABLE categories (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  vocabulary TEXT NOT NULL, -- 'service_type', 'specialty', etc.
  name TEXT NOT NULL,
  slug TEXT NOT NULL
);

CREATE TABLE location_categories (
  location_id UUID REFERENCES locations(id),
  category_id UUID REFERENCES categories(id),
  PRIMARY KEY (location_id, category_id)
);

Step 3: Rebuild Templates in Next.js + Tailwind

This is where the actual frontend work happens. We create a component library that renders the JSONB page sections dynamically. Every Drupal template becomes a React component. We use Tailwind CSS for styling, which means your designers can work with utility classes instead of wrestling with Drupal's theme layer.

Step 4: 301 Redirect Every URL

This is critical. Drupal URLs follow patterns like /node/123, /location/dallas-tx, or whatever Pathauto generated. Every single URL needs a 301 redirect to its new Next.js equivalent. We generate these from the Drupal database:

// next.config.js
module.exports = {
  async redirects() {
    return [
      // Generated from Drupal url_alias table
      { source: '/node/1234', destination: '/locations/dallas', permanent: true },
      { source: '/locations/dallas-tx-clinic', destination: '/locations/dallas', permanent: true },
      // ... hundreds more
    ]
  }
}

Step 5: Deploy and Decommission

Deploy to Vercel, verify all redirects, confirm SEO metrics are stable (expect 2-4 weeks of fluctuation), then decommission the Drupal servers. Keep a database backup — you'll never need it, but you'll sleep better.

Industries Leaving Drupal (And What They're Moving To)

Universities

Higher education was Drupal's stronghold. Universities loved multi-site because each department, college, and program could have its own site under one umbrella. But the upgrade costs are brutal for institutions with 50-200 subsites. We're seeing universities move to Next.js with headless CMS options like Sanity or Contentful for content editing, or to our preferred stack of Next.js + Supabase for institutions that want full control over their data. Our headless CMS development work covers these exact migrations.

Hospital Systems

Healthcare organizations need HIPAA compliance, and Drupal on shared hosting is a compliance headache. Modern stacks with Supabase (which offers SOC 2 Type II compliance and can be self-hosted for HIPAA requirements) provide better security posture with less operational overhead. Each clinic location page becomes a statically generated page with no server-side attack surface.

Government Agencies

Government sites were early Drupal adopters — WhiteHouse.gov famously ran on Drupal. But the FedRAMP compliance requirements and ATO (Authority to Operate) process for server-based Drupal hosting is expensive. Static site generators and JAMstack architectures reduce the compliance surface area dramatically. Several agencies have moved to Next.js with static export or to Astro for content-heavy informational sites.

Media Organizations

Publishers need speed — both in page load and in editorial workflow. Drupal's editorial experience, while improved with Layout Builder, can't match the modern editing experiences available with headless CMS platforms. And the performance difference between Drupal rendering and edge-delivered static pages is the difference between readers staying and bouncing.

What the Architecture Looks Like Post-Migration

The end state for a multi-location business looks like this:

┌─────────────────────────────────────────────┐
│                  Vercel                       │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐    │
│  │ /dallas  │ │ /austin  │ │ /houston │    │
│  │ (SSG)    │ │ (SSG)    │ │ (SSG)    │    │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘    │
│       └─────────────┼─────────────┘          │
│                     │                        │
│            Next.js App Router                │
│            (shared components)               │
└─────────────────────┬───────────────────────┘
                      │
              ┌───────┴───────┐
              │   Supabase    │
              │  ┌──────────┐ │
              │  │locations │ │
              │  │staff     │ │
              │  │services  │ │
              │  │reviews   │ │
              │  │media     │ │
              │  └──────────┘ │
              │  + Auth       │
              │  + Storage    │
              │  + Edge Funcs │
              └───────────────┘

Adding a new location? Insert a row in the locations table, add the page sections content, and the site rebuilds via ISR. No new Drupal site provisioning, no DNS configuration, no Apache vhost setup. Just data.

If this architecture interests you, we've documented our approach and pricing for these kinds of migrations at our pricing page. For a conversation about your specific Drupal network, get in touch.

FAQ

Is Drupal 7 still safe to use in 2026?

No. Drupal 7 reached end-of-life in January 2025. It no longer receives security patches from the Drupal Security Team. There are third-party extended support vendors, but they're expensive ($500–$2,000/month) and only cover core — not contributed modules. If you're still on D7, you should treat migration as urgent, not optional.

How long does a Drupal to Next.js migration take?

For a single site, expect 4–8 weeks. For a multi-site network with 10–20 sites, plan for 3–6 months with a phased approach — migrate sites in batches, starting with the highest-traffic locations. The shared component library means each subsequent site migrates faster than the previous one.

Will I lose SEO rankings when migrating from Drupal?

You'll see a temporary fluctuation — typically 2–4 weeks — as Google recrawls and reindexes your pages. Proper 301 redirects are non-negotiable. We've seen most sites recover to their pre-migration rankings within 30 days, and many surpass them within 60 days due to improved Core Web Vitals scores.

What about Drupal's content editing experience? Non-technical editors need a CMS.

This is a valid concern. Supabase's dashboard works for technical teams, but non-technical editors typically need a friendlier interface. Options include: building a custom admin panel with Next.js (2–3 weeks of additional work), using a headless CMS like Sanity or Contentful as the editing layer with Supabase as the data store, or using Supabase's auto-generated APIs with a tool like Retool or Appsmith for quick admin interfaces.

Can Supabase handle HIPAA compliance for healthcare organizations?

Supabase Cloud is SOC 2 Type II compliant. For HIPAA, you'll need either a Business Associate Agreement (BAA) with Supabase — contact their sales team — or self-host Supabase on your own HIPAA-compliant infrastructure (AWS GovCloud, Azure Government, etc.). Self-hosting Supabase adds operational complexity but gives you full control over data residency and compliance.

What's the real cost difference between Drupal multi-site and Next.js + Supabase?

For a 20-site network on Acquia or Pantheon, you're typically spending $12,000–$36,000/year on hosting alone. Next.js on Vercel + Supabase for the same network runs $540–$4,800/year. Factor in the Drupal upgrade cycle ($200K–$600K every 2–3 years) versus near-zero upgrade costs with Next.js, and the five-year TCO difference is often $500K+.

Can I migrate incrementally, or does it have to be all at once?

Incremental migration works well. Use Vercel's rewrites to proxy specific routes to your old Drupal site while serving migrated pages from Next.js. Migrate one location at a time. This approach is lower risk and lets you validate the new stack before committing fully. We've done this with networks of 30+ sites where a big-bang migration wasn't feasible.

What happens to my Drupal contributed module functionality?

Every module maps to something in the new stack. Webform becomes React Hook Form + Supabase inserts. Pathauto becomes Next.js dynamic routes. Metatag becomes Next.js Metadata API. Views becomes Supabase queries. Search API becomes Supabase full-text search or a service like Meilisearch. The functionality doesn't disappear — it just moves to a more maintainable implementation. We've written migration maps for the 50 most common Drupal modules as part of our headless CMS migration practice.