Drupal to Modern Static: The Complete Migration Guide

Drupal is one of the most capable content management systems ever built. Its entity/field architecture, granular permissions, Views query builder, multilingual system, and module ecosystem make it a genuine powerhouse for complex content operations. Universities, government agencies, media organizations, and enterprises around the world depend on Drupal for good reason.

But Drupal’s power comes with a cost. The platform requires PHP hosting, a relational database, caching infrastructure, ongoing security patches, and specialized developer talent. For organizations that use Drupal’s advanced features, this cost is justified. For the many Drupal sites that are primarily serving content to anonymous visitors — marketing sites, blogs, business homepages, portfolios — the infrastructure far exceeds what the site actually needs.

With Drupal 7’s end of life in January 2025 forcing millions of sites to make a decision, the migration question has never been more pressing. This guide covers every realistic option: upgrading to Drupal 10/11, migrating to a static site, going headless, moving to WordPress, or rebuilding with AI assistance. No single answer is right for every site. The goal is to help you find the right answer for yours.

Understanding Drupal’s content architecture

Before discussing migration approaches, it is essential to understand what makes Drupal unique — and what makes Drupal migrations more complex than migrations from simpler CMSes.

The entity/field system

Drupal’s content model is built on entities, bundles (content types), and fields. A “Case Study” content type might have:

• Title (core field)
• Body (text with summary)
• field_client_name (plain text)
• field_industry (taxonomy reference)
• field_featured_image (media reference)
• field_related_services (entity reference to Service nodes)
• field_testimonial_quote (long text)
• field_results_metrics (paragraph reference — multiple metric items)

Every field has configuration: required/optional, cardinality (single vs multi-value), display settings, form widgets, validation. This flexibility is Drupal’s greatest strength and the primary source of migration complexity.

The Paragraphs module

Many Drupal sites (especially D8+) use the Paragraphs module for flexible page building. Instead of a single body field, a page contains a sequence of typed paragraph items:

• Hero paragraph: heading, subheading, background image, CTA button
• Text with Image paragraph: body text, image, layout direction (left/right)
• Testimonial Carousel paragraph: references to testimonial nodes
• Stats Grid paragraph: multiple stat items (number, label, icon)
• CTA Banner paragraph: heading, text, button text, button URL

Each paragraph type has its own fields, creating deeply nested content structures. Extracting and converting Paragraphs content is the single most complex aspect of most Drupal migrations.

D7 vs D8+ differences

This distinction matters enormously for migration planning:

Drupal 8+ (including 9, 10, 11):

• JSON:API is a core module — full RESTful API for all entities out of the box
• Configuration management exports to YAML files
• Entity storage is more normalized
• Twig templates (PHP-based but cleaner)
• Composer for dependency management
• Modern PHP (classes, namespaces, dependency injection)

Drupal 7:

• No built-in content API (requires Services module or RESTful module)
• Each field stored in its own field_data_* table (extracting content requires joining many tables)
• PHPTemplate theme layer
• No Composer (manual module management)
• Procedural PHP with the hook system
• Different entity API (less standardized)

Migrating from D8+ is significantly easier than from D7 because of JSON:API alone. D7 migrations almost always require database-level extraction.

Taxonomy, Views, and Blocks

Taxonomy vocabularies (Tags, Categories, Topics, Regions) are entity types with term hierarchy. They serve as classification systems referenced by content. In a migration, they become either frontmatter fields, content tags, or separate data structures.

Views is Drupal’s query builder — it creates listing pages, blocks, feeds, and data displays without writing SQL. A typical Drupal site might have 20-50 Views: blog listing, news archive, staff directory, event calendar, related content blocks. Each View needs a corresponding implementation in the target platform.

Blocks are content regions placed in layout areas. Drupal’s Block Layout system determines what appears in headers, sidebars, footers, and content regions. In a migration, blocks become components or layout elements.

Multilingual content

Drupal’s multilingual system is enterprise-grade:

• Content Translation module (D8+ core): Each entity can be translated independently with language-specific field values
• Interface Translation: UI strings translated via .po files
• Language negotiation: URL prefix (/en/, /fr/), domain-based, browser detection
• Translation Management: Workflow for sending content to translators, tracking translation status

If your Drupal site is multilingual, migration complexity increases significantly. Multilingual content needs to be extracted with language codes intact and mapped to the target platform’s i18n system.

Decision framework: should you migrate?

Migrate away from Drupal if:

• Your site serves the same content to every visitor (no authenticated user areas)
• Content changes weekly or monthly, not minute by minute
• You do not use Drupal’s permissions system beyond basic admin access
• You do not use editorial workflows (draft/review/publish moderation)
• Your content model is straightforward (blog posts, pages, maybe a few custom types)
• You are on Drupal 7 and the D10 upgrade cost exceeds your budget
• Finding Drupal developers is becoming difficult or expensive
• You want AI agents to be able to maintain your site

Stay on Drupal (upgrade to D10/11) if:

• You genuinely need complex role-based permissions
• You have editorial workflows with content moderation (draft, review, approved, published)
• You manage multilingual content with translation workflows
• Your content model has complex entity relationships that drive application behavior
• You have deep integrations with enterprise systems via Drupal modules (LDAP, SSO, CRM)
• Your content editors are deeply invested in Drupal’s admin interface
• You have a team with strong Drupal expertise
• Your site has member/user-facing features (profiles, dashboards, user-generated content)

Consider headless Drupal if:

• You want Drupal’s editing experience with a modern frontend
• Content editors need Drupal’s familiar admin UI
• You have complex editorial workflows worth preserving
• You want to modernize the frontend without losing the backend
• You have budget for running both Drupal and a frontend application

All migration paths

Path 1: Upgrade to Drupal 10/11

The official path. Drupal 10 is modern, well-architected software with a strong community and roadmap. The upgrade is the right choice for sites that genuinely need Drupal.

What it involves (D7 to D10):

• Rewriting custom modules from D7’s hook-based system to D10’s plugin/service architecture
• Converting themes from PHPTemplate to Twig
• Migrating database schemas (Drupal’s Migrate module handles much of this)
• Finding D10 equivalents for all contributed modules (some D7 modules have no D10 version)
• Testing thoroughly — entity references, permissions, Views, custom functionality

Timeline: 3-6 months for a mid-size site. 6-12+ months for enterprise sites.

Cost breakdown:

Component	Estimated Cost
Custom module rewrites	$20,000-$80,000
Theme conversion (PHPTemplate to Twig)	$10,000-$30,000
Data migration (Migrate module config + custom)	$5,000-$15,000
Contributed module audit + replacement	$5,000-$20,000
Testing and QA	$10,000-$30,000
Project management	$5,000-$15,000
Total	$55,000-$190,000
Ongoing hosting	$100-$500/month
Ongoing maintenance	$3,600-$24,000/year

For D8/D9 to D10: Much simpler. D8-to-D10 is a version upgrade, not a rebuild. Use composer update and handle deprecations. Typically $5,000-$30,000 depending on custom module complexity.

Where to find Drupal upgrade specialists: Drupal.org marketplace, Acquia partners, agencies like Lullabot, Chapter Three, Palantir.net, or the Drupal Slack #jobs channel.

Path 2: AI coding agents (Claude Code, Cursor, Windsurf, Cline)

This is the most powerful migration approach for developers. AI coding agents can consume Drupal’s APIs, extract all content, and build a complete new site in hours to days.

Why this works especially well with Drupal: Drupal has the best content extraction APIs of any mainstream CMS. JSON:API (D8+) exposes every entity type with full field data, relationships, filtering, and pagination. This is not a workaround — it is a first-class, well-documented API designed for exactly this kind of programmatic content access.

For Drupal 8+ sites with JSON:API:

1. Verify JSON:API is enabled: visit https://your-site.com/jsonapi
2. Open Claude Code, Cursor, Windsurf, or Cline
3. Provide a detailed prompt:

“My Drupal 10 site at example.com has the following content types: Article (blog posts), Page (static pages), Case Study, Team Member, and Event. Fetch all published content from the JSON:API at /jsonapi. For each content type, create a markdown file with frontmatter matching the Drupal fields. Download all media files. Scaffold an Astro project (or Next.js, Hugo, etc.) with content collections for each type. Create listing pages equivalent to these Drupal Views: blog archive (sorted by date, paginated), team directory, upcoming events. Preserve all URL aliases. Create a redirect map for any URLs that change.”

4. The agent iterates: fetches API endpoints, builds markdown files, downloads images, scaffolds the project
5. Review and iterate — the agent can fix issues, add missing content types, adjust layouts
6. Deploy when ready

For Drupal 7 sites:

D7 lacks JSON:API. The best extraction methods:

Direct SQL queries:

-- Basic article export
SELECT n.nid, n.title, n.created, n.changed, n.status,
       b.body_value, b.body_summary,
       ua.alias as url_alias
FROM node n
JOIN field_data_body b ON b.entity_id = n.nid AND b.entity_type = 'node'
LEFT JOIN url_alias ua ON ua.source = CONCAT('node/', n.nid)
WHERE n.type = 'article' AND n.status = 1
ORDER BY n.created DESC;

-- Custom fields (each field has its own table in D7)
SELECT entity_id,
       field_subtitle_value as subtitle,
       field_author_value as author_name
FROM field_data_field_subtitle s
JOIN field_data_field_author a USING (entity_id)
WHERE s.entity_type = 'node' AND s.bundle = 'article';

-- Taxonomy term assignments
SELECT ti.nid, td.name as tag_name, tv.name as vocabulary_name
FROM taxonomy_index ti
JOIN taxonomy_term_data td ON td.tid = ti.tid
JOIN taxonomy_vocabulary tv ON tv.vid = td.vid
WHERE tv.machine_name IN ('tags', 'categories');

-- File/image fields
SELECT fm.fid, fm.filename, fm.uri, fm.filemime,
       fi.entity_id as nid
FROM file_managed fm
JOIN field_data_field_image fi ON fi.field_image_fid = fm.fid
WHERE fi.entity_type = 'node';

Export results to CSV or JSON, then give the exported files to your AI agent with instructions to build the new site.

Views Data Export module: If you can install modules on your D7 site, Views Data Export lets you create Views that export as CSV or JSON. Create one export View per content type.

Drush commands: drush sql-dump > backup.sql for a full database export. The AI agent can parse the SQL dump directly if needed, though structured exports are easier.

Real-world examples: Teams at Prefect, Sid Bharath (documented publicly), and others have used AI coding agents for site migrations. The pattern — API extraction plus AI scaffolding — is particularly effective with Drupal because of its strong API layer.

Path 3: AI app builders (Bolt.new, v0.dev, Lovable, Replit Agent)

For non-technical teams or rapid prototyping:

1. Export Drupal content to JSON or CSV (via JSON:API, Views Data Export, or database queries)
2. Go to Bolt.new, v0.dev, Lovable, or Replit Agent
3. Upload your content data or paste sample content
4. Describe the site: “Build a professional marketing site with a blog, about page, team section, and contact form using this content data”
5. Iterate visually — adjust layouts, colors, typography
6. Download the generated code or deploy directly

Strengths: Fast, visual, no terminal required, good for simpler sites.

Limitations: Less precise than coding agents for complex Drupal sites. Struggle with many content types, nested Paragraphs content, or complex entity relationships. Best for sites with 3-5 content types and straightforward layouts.

Screenshot approach: Take screenshots of your existing Drupal pages and upload them as design references. The builder attempts to recreate the visual design with clean modern code. This works for visual fidelity but does not extract content — you still need the content export step.

Path 4: Hire a Drupal migration specialist

The Drupal community has deep, specialized migration expertise. This is the most established migration path with the longest track record.

Freelance Drupal developers: $2,000-$10,000 for a typical content site migration. They understand Drupal’s entity system, field storage differences between D7 and D8+, Paragraphs extraction, multilingual content handling, and the nuances that automated tools miss.

Drupal agencies: $10,000-$50,000 for enterprise Drupal sites with complex content models, many custom modules, multilingual setups, or large content volumes (10,000+ nodes).

Specialized migration agencies: Some Drupal shops specialize in migration services. They have refined processes, content mapping spreadsheets, and automated extraction scripts built over years of migration work.

Where to find specialists:

• Drupal.org marketplace (drupal.org/drupal-services)
• Drupal Slack (#migrations and #jobs channels)
• Toptal (search for Drupal migration specialists)
• Upwork (search “Drupal migration to static” or “Drupal to WordPress”)
• Drupal camps and DrupalCon contacts
• Acquia partner network

What to look for: Experience with your specific Drupal version (D7 vs D8+), familiarity with your contributed modules (especially Paragraphs, Multilingual, custom entity types), and references from similar migration projects.

Path 5: BrowserCat Migrate (automated)

BrowserCat Migrate is an automated migration service that uses AI agents to crawl your Drupal site, extract content and structure, and rebuild it as a static site with a GitHub repo and live preview. It handles content extraction, image downloading, component building, and deployment.

Path 6: Headless Drupal (keep Drupal, replace the frontend)

Instead of migrating away from Drupal, keep Drupal as a backend CMS and build a new frontend in Next.js, Nuxt, Astro, or another framework.

How it works:

• Drupal serves as the content API via JSON:API (or GraphQL with the contributed module)
• A JavaScript frontend fetches content from Drupal at build time or request time
• Content editors continue using Drupal’s admin interface
• The frontend handles presentation with modern JavaScript

Configuration:

1. Enable JSON:API (usually already enabled on D8+)
2. Install JSON:API Extras for endpoint customization
3. Configure CORS headers for the frontend domain
4. Build the frontend application with data fetching from Drupal
5. Deploy the frontend to Vercel, Cloudflare, or Netlify
6. Keep Drupal hosted for the API

Costs:

• Drupal hosting: $100-$500/month (still required)
• Frontend hosting: $0-$20/month
• Development: $10,000-$50,000 for the frontend build
• Ongoing: Drupal maintenance continues

Best for: Large organizations with editorial teams invested in Drupal’s UI, complex content operations, and budget for maintaining both systems.

Path 7: Migrate to WordPress

Some Drupal site owners, particularly those on D7, choose WordPress as a migration target. This is a legitimate option worth considering.

Why WordPress:

• Larger developer pool (vastly larger than Drupal’s)
• Lower hosting costs ($5-$50/month)
• Simpler administration for non-technical users
• Huge plugin ecosystem
• Better availability of AI-generated themes and plugins
• Existing Drupal-to-WordPress migration tools and services

Why NOT WordPress:

• Still a CMS with a database, PHP, and security patches (though less maintenance than Drupal)
• WordPress’s content model is less flexible than Drupal’s
• Complex Drupal content types may not map cleanly to WordPress
• You are trading one CMS for another, not simplifying the architecture

Tools for Drupal to WordPress migration:

• FG Drupal to WordPress (WordPress plugin): Automated content import from Drupal databases
• CMS2CMS: Paid automated migration service
• WordPress import tools: WP-CLI + custom scripts for database-level migration
• Freelancers specializing in CMS migration: $1,000-$5,000 for typical sites

Path 8: Drupal-native export + manual build

Use Drupal’s own excellent export tools and build the new site yourself.

Drupal’s content extraction tools (best in the CMS world):

Tool	Drupal Version	Format	Best For
JSON:API (core)	D8+	JSON (REST)	Programmatic extraction, AI agent consumption
GraphQL module (contrib)	D8+	GraphQL	Complex queries with relationships
Views Data Export (contrib)	D7, D8+	CSV, JSON, XML	Bulk export of any View
Migrate module (core)	D8+	Custom destinations	Structured migration with rollback
Default Content (contrib)	D8+	YAML/JSON files	Small sites, version-controlled content
Drush sql-dump	D7, D8+	SQL	Full database backup
Drush sql-query	D7, D8+	SQL results	Targeted content extraction
Services module (contrib)	D7	JSON/XML REST	API access for D7 sites
RESTful module (contrib)	D7	JSON REST	Modern API for D7

The quality of these tools is worth emphasizing. Drupal has genuinely the best content extraction options of any CMS. WordPress, Joomla, and Squarespace do not offer anything comparable to JSON:API for structured content access.

Target platform options:

Platform	Best For	Build Speed	Content Model	Learning Curve
Astro	Content sites, blogs, marketing	Fast	Built-in collections (Zod)	Moderate
Hugo	Large sites (1000+ pages)	Fastest	TOML/YAML frontmatter	Moderate
11ty	Simple sites, flexible templating	Fast	Multiple template options	Low
Next.js	Dynamic features, apps	Moderate	Flexible (MDX, API)	Higher
Gatsby	React-based content sites	Slower	GraphQL data layer	Higher
Plain HTML/CSS	Very simple sites	N/A	None (just files)	Lowest

The content extraction process (step by step)

Regardless of which migration path you choose, content extraction follows the same pattern:

Step 1: Audit your Drupal site

Before extracting anything, document what you have:

• Content types: List every content type with all fields (use /admin/structure/types in Drupal)
• Content volume: How many nodes of each type? (Use Views or drush sql-query)
• Taxonomy vocabularies: List all vocabularies and their terms
• Views: List all Views and what they display (listing pages, blocks, feeds)
• Blocks: Custom blocks, block visibility rules, block layout
• Menus: Menu structure and links
• Media/files: Total file count and size in sites/default/files/
• Custom modules: List all custom modules with descriptions of what they do
• Contributed modules: List all contrib modules (especially Paragraphs, Webform, Pathauto, Redirect)
• URL aliases: How URL aliases are structured (Pathauto patterns)
• Multilingual: Is Content Translation or Entity Translation enabled? What languages?
• User roles and permissions: What roles exist? What can each role do?

This audit determines migration complexity and helps you choose the right approach.

Step 2: Extract content

Using JSON:API (D8+, recommended):

# Discover available content types
curl https://your-site.com/jsonapi

# Fetch all articles (published only)
curl "https://your-site.com/jsonapi/node/article?filter[status]=1&page[limit]=50"

# Include relationships (images, taxonomy terms)
curl "https://your-site.com/jsonapi/node/article?include=field_image,field_tags,uid&filter[status]=1"

# Paginate through all content
# Follow the "next" link in the response's "links" object

Using SQL (D7 or when API is unavailable):

-- Step 1: List all content types and counts
SELECT type, COUNT(*) as count
FROM node WHERE status = 1
GROUP BY type ORDER BY count DESC;

-- Step 2: Export each content type
-- (Example for 'article' -- adjust for your content types)
SELECT n.nid, n.title, n.created, n.changed,
       b.body_value, b.body_summary,
       ua.alias as url_path
FROM node n
LEFT JOIN field_data_body b ON b.entity_id = n.nid AND b.entity_type = 'node'
LEFT JOIN url_alias ua ON ua.source = CONCAT('node/', n.nid)
WHERE n.type = 'article' AND n.status = 1
ORDER BY n.created DESC;

-- Step 3: Export taxonomy
SELECT td.tid, td.name, td.description, tv.machine_name as vocabulary
FROM taxonomy_term_data td
JOIN taxonomy_vocabulary tv ON td.vid = tv.vid;

-- Step 4: Export taxonomy-node relationships
SELECT ti.nid, td.name as term_name, tv.machine_name as vocabulary
FROM taxonomy_index ti
JOIN taxonomy_term_data td ON td.tid = ti.tid
JOIN taxonomy_vocabulary tv ON td.vid = tv.vid;

-- Step 5: Export file information
SELECT fid, filename, uri, filemime, filesize
FROM file_managed WHERE status = 1;

Step 3: Download files and media

Drupal stores uploaded files in sites/default/files/. For managed hosting (Acquia, Pantheon), you may need to use SFTP, rsync, or the hosting platform’s file download tools.

# If you have SSH access:
rsync -avz user@server:/var/www/drupal/sites/default/files/ ./downloaded-files/

# Or via Drush:
drush rsync @remote:%files ./downloaded-files/

For D8+ with media entities, the file paths are stored in the media entity’s field data, not directly in content nodes. Extract media entity data via JSON:API or database queries.

Step 4: Convert content to the target format

The extracted content (JSON, CSV, or SQL results) needs conversion to your target platform’s format. For most static site generators, this means markdown files with YAML frontmatter:

---
title: "Our Approach to Sustainable Design"
slug: our-approach-sustainable-design
author: Jane Smith
date: 2024-03-15
category: Insights
tags:
  - sustainability
  - design-thinking
featuredImage: /images/sustainable-design-hero.jpg
---

Content body here, converted from Drupal's HTML to markdown...

An AI coding agent can handle this conversion automatically. For manual conversion, tools like turndown (HTML to markdown library) can process Drupal’s HTML body fields.

Step 5: Handle Drupal-specific patterns

Paragraphs content: Extract paragraph item data separately, then structure as component data in your target format (JSON in frontmatter, separate data files, or MDX with components).

Entity references: Resolve references during extraction. If an Event references a Venue, include the Venue data inline in the Event’s content file, or create a separate Venue collection with cross-references.

Image styles: Drupal generates multiple image sizes (image styles). You can either download the originals from sites/default/files/ and let your target platform handle image processing, or download specific image style variants.

URL aliases: Create a mapping of old URLs to new URLs. If your new site preserves the same URL structure (recommended), no redirects are needed. For any URLs that change, set up 301 redirects.

Step 6: Build and deploy

Build the new site with your chosen generator, deploy to a static host (Cloudflare Pages, Vercel, Netlify), and verify everything works.

Verification checklist:

• All pages load correctly with proper content
• All images display (check for broken image references)
• Navigation works (all internal links resolve)
• Forms submit correctly (contact forms, newsletter signups)
• Old URLs either resolve or redirect (check via Google Search Console)
• Metadata is correct (title tags, meta descriptions, Open Graph)
• RSS feeds work (if applicable)
• Sitemap.xml is generated and submitted to search engines
• robots.txt is correct
• HTTPS is working
• Performance is good (run Lighthouse)

Technical gotchas and edge cases

Drupal’s Paragraphs module

The most complex pattern to migrate. Paragraphs create nested content structures that do not map neatly to markdown. Options:

1. Flatten to HTML/markdown: Render each paragraph type as HTML during extraction, then convert to markdown. Loses the structured nature but works with any target.
2. MDX components: Convert each paragraph type to a React/Astro component. Store paragraph data as structured frontmatter or JSON, render with components. Preserves structure.
3. Page builder approach: Use a target-platform page builder (if available) to recreate the paragraph-based layouts.

Entity references and relationships

Drupal’s entity reference system creates content relationships: articles reference authors, events reference venues, products reference categories. In a static site:

• Denormalize: During extraction, embed referenced data directly in the content file. An article’s author becomes inline author data in frontmatter, not a reference.
• Cross-collection references: Keep references as IDs/slugs and resolve them at build time. Astro’s reference() schema type supports this.
• Separate data files: Create JSON/YAML data files for entities that are referenced by many content items (e.g., team members, locations).

Multilingual content

If your Drupal site is multilingual:

1. Extract content with language codes: each node has a langcode field
2. Map to your target platform’s i18n system (Astro i18n routing, Next.js internationalized routing, Hugo’s multilingual mode)
3. Create parallel content files for each language
4. Implement language switching in the UI
5. Handle translated URL aliases (Drupal’s path translation)

This is one of the most complex migration scenarios. Consider hiring a specialist if your site has 3+ languages with active translation workflows.

Custom modules with business logic

If your Drupal site has custom modules that implement business logic beyond content display — custom entity types, complex form handlers, integration with external APIs, scheduled tasks — this logic needs to be reimplemented or replaced.

Options:

• Reimplement in JavaScript (serverless functions, API routes)
• Replace with third-party services (form handlers, integration platforms)
• Determine if the logic is still needed (some custom modules were built for requirements that no longer exist)

Drupal’s URL structure and SEO

Drupal sites commonly use the Pathauto module for URL aliases: /blog/2024/03/my-post-title or /services/web-development. Preserving these URLs is critical for SEO.

Most static site generators can match Drupal’s URL structure through file naming conventions or route configuration. For any URLs that must change, set up 301 redirects in your hosting platform’s redirect rules.

Also handle:

• Drupal’s node/123 canonical URLs (redirect to the alias)
• Taxonomy term pages (/taxonomy/term/45)
• Pager URLs (?page=2)
• Feed URLs (/rss.xml, /feed)
• Sitemap URL

The cost comparison (comprehensive)

Path A: D7 to D10 upgrade

Item	Low Estimate	High Estimate
Custom module rewrites	$20,000	$80,000
Theme conversion (PHPTemplate to Twig)	$10,000	$30,000
Data migration	$5,000	$15,000
Contrib module audit + replacement	$5,000	$20,000
Testing and QA	$10,000	$30,000
Project management	$5,000	$15,000
Migration total	$55,000	$190,000
Ongoing hosting (annual)	$1,200	$6,000
Ongoing maintenance (annual)	$3,600	$24,000
First year total	$59,800	$220,000
Five-year total	$79,000	$340,000

Path B: Migrate to static site (various approaches)

Approach	One-time Cost	Ongoing Annual Cost
AI coding agent (DIY)	$0 (your time)	~$0 (static hosting)
AI app builder	$0-$50/month (tool subscription)	~$0 (static hosting)
Freelance specialist	$2,000-$10,000	~$0 (static hosting)
Agency migration	$10,000-$50,000	~$0 (static hosting)
BrowserCat Migrate	Starting at $49	~$0 (static hosting)
Manual DIY	$0 (your time)	~$0 (static hosting)
Five-year total range	$0-$50,000	Near-zero

Path C: Headless Drupal + JS frontend

Item	Low Estimate	High Estimate
Frontend development	$10,000	$50,000
Drupal API configuration	$2,000	$10,000
Migration total	$12,000	$60,000
Drupal hosting (annual)	$1,200	$6,000
Frontend hosting (annual)	$0	$240
Drupal maintenance (annual)	$3,600	$24,000
Five-year total	$36,000	$210,000

Path D: Migrate to WordPress

Item	Low Estimate	High Estimate
Migration (content, theme, functionality)	$2,000	$20,000
Migration total	$2,000	$20,000
WordPress hosting (annual)	$120	$1,200
Maintenance (annual)	$500	$5,000
Five-year total	$5,100	$45,000

When to stay on Drupal

This guide would be dishonest if it did not acknowledge that Drupal is the right platform for many sites. Migrate away only if your site does not need what Drupal provides.

Drupal excels at:

• Complex permissions and roles. “Marketing editors can create and edit articles. Regional managers can approve content for their region. The legal team can edit the terms of service page but nothing else.” No static site or lightweight CMS replicates this.

• Editorial workflows. Content moderation with draft/review/legal-review/approved/published states, scheduled publishing, revision management. Drupal’s Workflows module (core in D8+) handles this natively.

• Multilingual content management. Content Translation with per-field translation, translation jobs, language negotiation, locale-specific content variants. Enterprise-grade multilingual that is difficult to replicate elsewhere.

• Complex content modeling. Entity references, paragraph types, custom entity types, computed fields, entity access callbacks. Drupal’s entity system is the most flexible content architecture in any open-source CMS.

• Enterprise integrations. SSO/SAML, LDAP, Salesforce, custom API integrations via Drupal modules. The integration ecosystem is mature and well-tested.

• Government and compliance. Drupal has certifications and track records with government agencies (whitehouse.gov, many federal and state sites). If compliance requirements mandate specific CMS certifications, Drupal may be necessary.

The Drupal community is rightly proud of these capabilities. They have built something that solves genuinely hard problems. Migrating away from Drupal for a site that needs Drupal’s features would be a mistake.

The Drupal community perspective

Drupal developers often have strong feelings about their platform, and those feelings are grounded in real experience. Drupal’s community has survived major architectural shifts (D6 to D7, D7 to D8) and emerged stronger each time. They have contributed thousands of modules, organized hundreds of events, and built a platform that powers some of the most demanding websites in the world.

When the Drupal community pushes back against “just migrate away” advice, they are often right. Many migration recommendations come from people who do not understand the complexity Drupal handles — the content types with 20 fields, the entity reference chains three levels deep, the multilingual sites with eight languages, the editorial workflows with five approval stages.

The respectful answer is: Drupal is excellent software. The question is not whether Drupal is good, but whether your specific site uses what Drupal provides. Many D7 sites were built on Drupal because it was the best choice at the time, but the site’s requirements have remained simple — a few content types, anonymous visitors, monthly content updates. For those sites, a simpler architecture is a better fit. For sites that truly exercise Drupal’s capabilities, the D10 upgrade is worth the investment.

After the migration

Regardless of which path you choose (except the D10 upgrade), your post-migration reality changes:

If you went static:

• Hosting drops to $0/month (static hosting free tiers)
• Maintenance drops to near-zero (no server, database, or patches)
• Any JavaScript developer or AI coding agent can maintain the site
• Content editing is file-based (or add a headless CMS like Decap, Tina, or Sanity for a browser UI)
• Performance is 95-100 Lighthouse out of the box

If you went headless Drupal:

• Frontend is modern JavaScript, maintained by JS developers
• Content editing stays in Drupal (familiar for editors)
• You still maintain Drupal (hosting, patches, modules)
• You gain flexibility to replace Drupal with another headless CMS later
• Performance depends on caching strategy (ISR, SSG, or SSR)

If you went to WordPress:

• Lower maintenance than Drupal, but still a CMS with a database
• Larger developer pool, cheaper hosting
• AI tools work well with WordPress (many AI page builders and content tools)
• Content editing is familiar (WordPress admin is widely known)

If you upgraded to D10:

• Modern Drupal with a strong roadmap
• All of Drupal’s powerful features intact
• Ongoing investment in hosting, maintenance, and Drupal expertise
• Access to the latest Drupal modules and improvements

Each path has legitimate tradeoffs. The right choice depends on your site’s actual requirements, your team’s capabilities, your budget, and your long-term goals.