Drupal to Next.js Migration | D7–D11
Your Drupal Site Hits End-of-Life Before Your Next Campaign Ships
Why leave Drupal?
- Drupal 7 stopped security patches January 2025 — unpatched CVEs now sit in exploit databases while your site runs
- Every major Drupal upgrade breaks contrib modules and costs $50–200K to rewrite themes and custom code
- Multisite deployments multiply every upgrade bill by the number of sites sharing the codebase
- Acquia and Pantheon hosting bills run $300–2,000/mo for infrastructure delivering 55–70 Lighthouse scores
- Drupal developers command $120–200/hr and the talent pool shrinks every quarter as agencies pivot to React
- Content editing workflows lock non-technical users into Drupal's admin UI with no headless preview layer
What you gain
- Next.js major versions ship codemods that auto-migrate breaking changes — no rewrite-level upgrades ever again
- Lighthouse Mobile scores jump to 95–100 with static generation, edge rendering, and automatic image optimization
- Hosting drops to $20–45/mo on Vercel with global CDN, instant rollbacks, and better uptime than managed Drupal
- Any JavaScript developer can contribute — hiring pool is 10× larger and rates run 40–60% lower than Drupal specialists
- Supabase bundles PostgreSQL, auth, file storage, and real-time subscriptions at $25/mo for most content libraries
- Full 301 redirect mapping preserves every backlink and ranking while zero-downtime cutover keeps your site live during deploy
Why Drupal Teams Are Migrating to Next.js
Drupal gave organizations a serious content management platform. But every major version has essentially been a new application: D7 to D8 was a complete rewrite (Symfony). D8 to D9 was easier. D9 to D10 broke contributed modules. D10 to D11 continues the pattern.
Running Drupal Multi-site makes it worse — every version upgrade multiplies by the number of sites. At some point, the upgrade cost exceeds the rebuild cost. Most of our Drupal clients hit that point two versions ago.
Drupal 7 hit end-of-life in January 2025. No more security patches. Drupal 10 EOL lands December 2026. If you're on either version, you're paying for an upgrade that delivers zero new features, or you're running unpatched software in production. Neither is acceptable.
The migration to Next.js with Supabase isn't about chasing trends. It's about escaping the Drupal upgrade treadmill permanently. Next.js major versions are backward-compatible. There is no "D7 to D8" moment in the JavaScript ecosystem.
Drupal Version-Specific Migration Paths
Every Drupal version requires a different extraction strategy. We've migrated all of them.
Drupal 7: Direct Database Migration
D7 has no REST API by default. The restws module exists but is rarely installed, and even when it is, it doesn't expose everything. The reliable path is direct database extraction.
Our process for D7:
- MySQL dump with Python or Node.js transformation scripts to normalize D7's EAV (Entity-Attribute-Value) field storage into flat Supabase tables
- D7 content types become Supabase tables — one table per major content type
- D7 CCK/Field API fields map to Supabase columns or JSONB for complex nested data
- D7 Views become Supabase queries consumed by Next.js server components
- D7 Panels and Display Suite layouts become React component compositions
- D7 users with SHA-512 hashed passwords migrate to Supabase Auth — we implement a rehash-on-first-login pattern via Auth hooks so users never need a password reset
D7's field storage schema is genuinely painful. Every field lives in its own table (field_data_field_*, field_revision_field_*). A single content type with 15 fields requires joining 15 tables. Our transformation scripts flatten this into clean, queryable Supabase schemas.
Drupal 8, 9, 10, and 11: JSON:API Export
D8+ ships with JSON:API at /jsonapi/node/[content_type]?page[limit]=50. This makes content extraction significantly cleaner. We paginate through every content type, resolve entity references, and transform the output into Supabase-ready data.
Key mapping decisions for D8+:
- Paragraphs (Drupal's nested content blocks) become either JSONB fields on the parent table or separate related tables, depending on query patterns
- Drupal Media entities migrate to Supabase Storage or Vercel Blob with CDN URLs
- Drupal i18n maps to next-intl with Supabase locale columns using a slug + locale unique constraint
- Workbench Moderation / Content Moderation becomes a status column (
draft,published,archived) on each content table - Webforms become custom Next.js server actions with Supabase insert and Resend email notifications
Content Type Mapping
Here's how Drupal entities translate to the new stack:
| Drupal Entity | Supabase / Next.js Equivalent |
|---|---|
| node (basic page) | pages table |
| node (article/blog) | posts table |
| node (landing page) | capabilities table |
| taxonomy term | tags table with polymorphic type column |
| paragraph types | JSONB field or related table |
| media entity | Supabase Storage with CDN URL |
| webform | Server Action + Supabase insert |
| Drupal Views | Supabase query + Next.js server component |
| Drupal user | Supabase Auth user + profiles table |
| Drupal menu | Static Next.js nav config |
| Drupal block | React component |
Taxonomy vocabularies with hundreds of terms and complex hierarchy (parent/child relationships) get a parent_id self-referential foreign key in Supabase. Drupal's taxonomy is actually one of the cleaner data models to migrate.
Drupal Multi-site Migration Strategy
Drupal Multi-site networks share a codebase but run separate databases. Every upgrade multiplies effort by site count. We've seen 12-site networks where a D9-to-D10 upgrade was quoted at $180K and six months.
Our multi-site migration approach:
- Each site database is exported independently
- Shared modules and custom themes are audited for functionality that needs to be preserved
- Per-site content migrates to Supabase with
location_idisolation — one database, row-level filtering - Old Drupal site domains get 301 redirects to new
/locations/[slug]routes - Shared admin functionality consolidates into a single Next.js admin interface
The result: one codebase, one database, one deployment. Not twelve of each.
Media Migration
Drupal stores files under public:// (mapped to /sites/default/files/) and optionally private:// (requires authentication to access). Our migration script handles both:
- Enumerate all file entities via
drush scror a Node.js script querying thefile_managedtable - Download every file — public files via HTTP, private files via authenticated Drush commands
- Upload to Supabase Storage with organized bucket structure
- Rewrite all body text references from old
/sites/default/files/paths to new CDN URLs using regex transformation across all content
This catches the images embedded in WYSIWYG body fields that most migration tools miss entirely.
301 Redirect Strategy for SEO Preservation
Drupal's URL aliases live in the url_alias table (D7) or path_alias table (D8+). Every /node/123 has a human-readable alias like /about-us or /blog/my-post.
Our redirect process:
- Export all aliases:
SELECT source, alias FROM url_alias(orpath_alias) - Map each Drupal alias to the corresponding new Next.js path
- Implement redirects via
vercel.json(supports up to 1,024 redirects) or Next.js middleware (unlimited) - For multi-site networks: per-domain redirect mapping in middleware
- Submit updated sitemaps to Google Search Console immediately post-launch
- Monitor 404s in Vercel analytics for the first 30 days and patch any missed redirects
SEO equity doesn't disappear if you handle redirects properly. We've migrated sites with 10,000+ indexed pages and maintained organic traffic through the transition.
What Stays the Same
- Content hierarchy and organization
- Internal linking structure (preserved via redirects, then updated to direct links)
- SEO equity (301 redirects + sitemap resubmission)
- User accounts (migrated with rehash-on-login, not reset)
What Gets Better
- Performance: Lighthouse Mobile scores jump from 55–70 to 90–100. Next.js static generation and edge rendering eliminate Drupal's PHP rendering bottleneck.
- Hosting costs: $20–45/mo on Vercel versus $300–2,000/mo on Acquia or Pantheon.
- Developer availability: Any JavaScript developer can work on Next.js. Drupal specialists charge $120–200/hr and are increasingly scarce.
- Upgrade path: Next.js major versions ship with codemods and backward compatibility. No more rewrite-level upgrades.
- Security surface: No PHP, no MySQL exposed to the web, no Drupal security advisories to patch weekly.
Our Migration Process
Phase 1: Audit (Week 1)
We inventory every content type, field, taxonomy vocabulary, view, webform, and custom module. We identify what needs to be migrated, what can be dropped, and what needs to be rebuilt as custom functionality.
Phase 2: Schema Design + Data Migration (Weeks 2–3)
Supabase schema design, migration scripts, data validation. We run the migration against a staging environment and verify every content type.
Phase 3: Frontend Build (Weeks 3–6)
Next.js pages, components, server actions. We match or improve existing layouts. No pixel-perfect Drupal theme recreation — this is an opportunity to modernize the UI.
Phase 4: Redirects, QA, Launch (Weeks 5–8)
Redirect mapping, cross-browser testing, performance validation, DNS cutover.
Timeline and Pricing
| Site Size | Content Types | Pages | Timeline | Investment |
|---|---|---|---|---|
| Small | 5–20 | < 500 | 3–4 weeks | $10–25K |
| Medium | 20–50 | 500–5,000 | 4–7 weeks | $25–50K |
| Large | 50+ | 5,000+ | 6–10 weeks | $50–80K |
| Multi-site | Per site | Per site | Per site + integration | Volume discount applies |
Every engagement starts with a free migration audit. We'll pull your content type inventory, estimate data volume, and deliver a fixed-price proposal within one week.
The migration process
Discovery & Audit
We map every page, post, media file, redirect, and plugin. Nothing gets missed.
Architecture Plan
New stack designed for your content structure, SEO requirements, and performance targets.
Staged Migration
Content migrated in batches. Each batch verified before the next begins.
SEO Preservation
301 redirects, canonical tags, sitemap, robots.txt — every ranking signal carried over.
Launch & Monitor
DNS cutover with zero downtime. 30-day monitoring period included.
Drupal vs Next.js + Supabase
| Metric | Drupal | Next.js + Supabase |
|---|---|---|
| Lighthouse Mobile | 55-70 | 95-100 |
| TTFB | 1.2-3.0s | <0.3s |
| Monthly Hosting | $300-2,000 | $20-45 |
| Major Version Upgrade | $50-200K rewrite | npm update + codemod |
| Developer Rate | $120-200/hr specialist | $60-120/hr JS developer |
| API / Headless | Bolt-on (D7: none, D8+: JSON:API) | Native (server components + Supabase API) |
Common questions
How do you migrate Drupal 7 without a REST API?
We pull content straight from the MySQL database using transformation scripts — no REST API needed, which is good because D7 doesn't have one by default. D7's Entity-Attribute-Value field storage is the ugly part: 15 fields on a content type means 15 table joins. Our Node.js scripts flatten all of that into clean Supabase schemas in a single pass, handling field collections, entity references, and taxonomy relationships along the way.
Will we lose SEO rankings during the Drupal migration?
Not if you handle redirects properly. We export every URL alias from Drupal's database, map each one to its new Next.js path, and wire up 301 redirects through Vercel or Next.js middleware. Sitemaps get resubmitted to Google Search Console on launch day. Then we watch 404s in Vercel analytics for 30 days post-migration and patch anything we missed. We've done this on sites with 10,000+ indexed pages without losing organic traffic.
How do you handle Drupal Paragraphs in the migration?
Paragraphs — Drupal's nested content blocks — go one of two ways: JSONB fields on the parent content table, or separate related tables in Supabase. The deciding factor is whether you need to query paragraph data on its own. Honestly, most teams end up with JSONB because paragraphs almost always get rendered inside their parent anyway. There's rarely a reason to join across tables for them.
Can users keep their existing passwords after the Drupal migration?
Yes, and users won't even notice. We migrate Drupal accounts to Supabase Auth and use Auth hooks to handle the password transition transparently. First time someone logs in, their password gets verified against the old Drupal hash — SHA-512 for D7, bcrypt for D8+ — and quietly rehashed to Supabase's format in the background. No password reset emails, no support tickets.
What's the cost difference between upgrading Drupal and migrating to Next.js?
A D7-to-D10 upgrade typically runs $50–200K and takes 3–12 months. A full migration to Next.js + Supabase costs $10–80K and wraps up in 3–10 weeks. You also drop $300–2,000/mo in Acquia or Pantheon hosting fees down to $20–45/mo on Vercel. And you're done with major-version rewrites — Next.js doesn't do that to you.
How do you migrate a Drupal Multi-site network?
Each site's database gets exported independently. Content migrates into a single Supabase database with `location_id` row-level isolation keeping everything separated. Old site domains get 301 redirects pointing to the new `/locations/[slug]` routes. You end up with one codebase and one deployment — not a shared Drupal codebase where every upgrade hits you twelve times.
What happens to Drupal Views after migration?
Drupal Views are basically database queries with display logic glued on. We translate each View's query logic into Supabase queries, then wire those up to Next.js server components. Filters, sorts, pagination, exposed filter forms — all of it gets rebuilt as React components. The end result is faster, easier to read, and you don't need to click through a Views UI every time something needs tweaking.
Do you support Drupal multilingual (i18n) migration?
Yes. Drupal's i18n content translations migrate to Supabase using locale columns with a slug + locale unique constraint. The Next.js side uses next-intl for routing and language switching. Interface translations, content translations, per-language URL aliases — all of it carries over into the new architecture.
What is the Drupal migration process?
The Drupal migration process involves several key steps. First, assess your current Drupal site to understand the data structure and custom modules. Next, set up a new Drupal 9 or 10 environment, as Drupal 11 is still in development. Use the Migrate API to transfer content, users, and configuration settings. Pay close attention to custom code and modules, ensuring they are compatible or rebuilt for the new environment. Finally, thoroughly test the new site to ensure data integrity and functionality before going live.
Does anyone use Drupal anymore?
Yes, Drupal is still widely used, particularly for large-scale, complex websites that require robust content management capabilities. As of 2023, Drupal powers around 2% of all websites, which includes high-profile sites like those of government institutions and large corporations. Its strong community support, flexibility, and scalability make it a preferred choice for developers. Upgrading from Drupal 7 to Drupal 11 remains a common practice to take advantage of improved security features and modern development tools.
Ready to migrate?
Free assessment. We'll audit your current site and give you a clear migration plan — no commitment.
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.