Top Drupal Alternatives in 2026: Migration Paths & TCO

Top Drupal Alternatives in 2026: Migration Paths & TCO

The best Drupal alternative in 2026 depends on which version you're leaving and what's actually broken: editorial friction, developer scarcity, hosting costs, or an end-of-life deadline. WordPress is the lowest-risk swap for most teams. Craft CMS wins on content modeling and editorial UX. Strapi and Sanity serve API-first architectures — Strapi with full code ownership, Sanity as a managed content platform. Backdrop CMS is the lightest lift from Drupal 7. TYPO3 handles massive multilingual, multisite deployments, primarily in Europe.

This guide compares each alternative on real pricing, migration complexity, and three-year total cost of ownership. Every platform has trade-offs. We name them.

Why teams leave Drupal in 2026

Drupal remains a capable CMS, particularly at the enterprise end where Acquia is frequently evaluated as a Sitecore alternative. But three converging pressures are pushing teams to evaluate alternatives.

Two end-of-life deadlines in 18 months

Drupal 7 reached end of life on January 5, 2025. The Drupal Security Team no longer issues patches, and vulnerabilities discovered after that date have no official fix. According to W3Techs data from September 2026, roughly 29.3% of all Drupal sites still run version 7 — a significant installed base operating without community security support.

Drupal 10 reaches end of life on December 9, 2026, the same week Drupal 12 ships. Only the 10.6.x branch still receives security fixes, and that coverage ends in December. Sites on 10.4.x lost security support in December 2025; sites on 10.5.x lost it in June 2026. If you're on anything below 10.6, your site is already running without security coverage.

Drupal 12 cannot be reached from Drupal 10 directly — the update system requires Drupal 11.3 or later as an intermediate step. "Waiting for 12" still means doing the Drupal 11 upgrade first.

The upgrade path is a rebuild

Moving from Drupal 7 to Drupal 11 is not a software update — it's a full rebuild onto a modern PHP/Symfony architecture. The templating engine changed (PHPTemplate → Twig), the module system changed, and configuration management changed. If you have to rebuild the frontend and rewrite the backend logic anyway, the switching cost to a new CMS is effectively zeroed out.

Shrinking talent pool

Drupal's overall CMS market share declined from roughly 2.0% of all websites in 2015 to approximately 0.7% in 2026, according to W3Techs. The developer pool contracted accordingly. Senior Drupal engineers command comparable rates to WordPress or Laravel developers, but they're harder to find and slower to recruit. Recruiter pipelines that fill a Drupal developer role in 6–8 weeks typically fill an equivalent WordPress or Laravel role in 2–3 weeks in comparable markets.

Complexity tax on editors

Drupal's entity-field architecture is powerful for complex content modeling, but it demands developer involvement for tasks that competing platforms let editors handle directly. Non-technical editors frequently find managing nested Paragraphs, block layouts, and taxonomy references more cognitively demanding than modern block editors. Layout Builder improved the editorial experience in Drupal 10 and 11, but the gap between Drupal's admin UX and what WordPress or Craft CMS offer remains noticeable for content teams.

How your current Drupal version changes everything

The migration path varies dramatically depending on which version you run:

Current version	Status (Oct 2026)	Path forward
Drupal 7	EOL since Jan 2025 — no security patches	Migrate to a new platform or rebuild on Drupal 11. No in-place upgrade exists from D7 to modern Drupal; the architecture changed completely in D8.
Drupal 8 or 9	EOL (Nov 2021 / Nov 2023)	Same as D7 in practice — update to 10.6 first, then 11, or replatform.
Drupal 10 (10.6.x)	Supported until Dec 9, 2026	Upgrade to Drupal 11 now, or use the remaining window to evaluate alternatives.
Drupal 11	Current, actively supported	No urgency. Evaluate alternatives only if Drupal's complexity or talent constraints are the actual problem.

Moving from Drupal 7 to Drupal 11 is not an "upgrade" — it's a rebuild. The effort is comparable to migrating to an entirely different CMS, which is why so many teams use this inflection point to replatform.

Headless Drupal vs. replatforming: a structured comparison

Before choosing an alternative, teams with API-first requirements should explicitly consider whether to keep Drupal as a headless backend. This is a real architectural option, not a default fallback.

Headless Drupal (decoupled) uses Drupal 11's built-in JSON:API or the contributed GraphQL module to serve content to a separate frontend (Next.js, Nuxt, Astro). You retain Drupal's content modeling power and access controls but eliminate its frontend rendering. This is viable when:

• Your team already has strong Drupal expertise and maintaining that investment is cheaper than retraining
• Your content model is unusually complex (deep entity references, granular workflow permissions, multilingual parity)
• You need to serve content to multiple frontends simultaneously

Replatforming makes more sense when:

• The primary driver is editorial friction — headless Drupal doesn't fix the admin UX
• Developer scarcity is the constraint — a headless Drupal backend still requires Drupal expertise
• Hosting costs are unsustainable — running Drupal purely as an API layer on Acquia or Pantheon is expensive for what you get
• Your module dependencies have no maintained successors in Drupal 11

Factor	Headless Drupal	Replatform to Strapi/Sanity
Content model complexity	Advantage: retains D11 field system	Neutral: requires remapping
Editorial UX	No improvement	Significant improvement
Developer scarcity	Problem persists	Solved (Node.js/JS ecosystem)
Hosting cost	High (Drupal infra + frontend)	Lower (purpose-built headless platforms)
Migration effort	Low (no content migration needed)	High (full ETL + rebuild)
Long-term vendor risk	Low (open-source core)	Variable by platform

Drupal module compatibility matrix

The most common reason migrations stall is discovering mid-project that a critical Drupal module has no equivalent on the target platform. This table maps the most-used contributed modules to their nearest equivalents. "No direct equivalent" means the functionality must be custom-built.

Drupal module	WordPress	Craft CMS	Strapi	Sanity
Paragraphs	ACF Flexible Content / Gutenberg blocks	Matrix fields (native)	Dynamic zones	Portable Text arrays
Webform	Gravity Forms / WPForms	Craft Campaign / custom	Custom API endpoint	Custom form integration
Rules	WP-Cron + custom / Automator	Custom PHP / webhooks	Lifecycle hooks	GROQ-based webhooks
Commerce	WooCommerce	Commerce plugin (Pixel & Tonic)	No direct equivalent	No direct equivalent
Search API + Solr	SearchWP / ElasticPress	native search / Algolia	No direct equivalent — external search required	No direct equivalent — external search required
LDAP / SSO	Various SAML/OAuth plugins	SAML plugin	Custom middleware	Custom middleware
Pathauto	Yoast SEO / Rank Math (auto slugs)	URL slugs (native)	Slug field (native)	Slug field (native)
Metatag	Yoast SEO / Rank Math	SEOmatic plugin	Custom fields	Custom fields
Views	WP_Query + plugins / Toolset Views	Element API / GraphQL queries	REST/GraphQL filters	GROQ queries
Workspaces	Editorial Workflow (WP) / PublishPress	Drafts (native)	Draft system (native)	Drafts (native)
Multilingual (core)	WPML ($99–$199/yr)	Sites + translation (Pro)	i18n plugin (built-in)	Localization (built-in)

Modules marked "custom" require scoping with your development team before committing to that platform. Webform and Rules, in particular, are the two modules most likely to block a migration when their functionality is deeply embedded in site workflows.

WordPress: the default alternative

WordPress is an open-source CMS that powers roughly 60% of the CMS market. It is the most common Drupal migration target by volume.

The plugin ecosystem is vast (60,000+ free plugins on WordPress.org), the developer talent pool dwarfs Drupal's, and hosting options range from $5/month shared plans to WordPress VIP at ~$2,000+/month for enterprise managed infrastructure.

To replicate Drupal's structured data in WordPress, you'll map Drupal content types to WordPress Custom Post Types (CPTs) and use Advanced Custom Fields (ACF) to recreate field structures. Drupal's Paragraphs can be mapped to ACF Flexible Content fields or native Gutenberg blocks, though the latter requires React development skills for custom blocks.

Migration trade-offs:

• Drupal's entity-field system and WordPress's post-meta model structure content differently. Entity references chaining content types, or Paragraphs module nesting, don't map directly.
• Drupal modules and WordPress plugins serve the same purpose but rarely match feature-for-feature. A Drupal site using Webform, Rules, and Entity Registration has no drop-in WordPress equivalents — expect custom development for each.
• WordPress relies on third-party plugins for functionality Drupal includes in core: multilingual support (WPML at $99–$199/year), complex user roles, and revision workflows. This plugin dependency introduces security surface area and requires strict update governance.
• URL structures differ. Drupal's Pathauto-generated paths need careful 301 redirect mapping to preserve SEO authority. Sites that skip this step typically see 20–40% organic traffic decline in the first 90 days post-migration as Google processes the new URL structure.
• Themes cannot be ported. Drupal 8+ uses Twig; WordPress uses PHP templates. A theme rebuild is unavoidable.

TCO range: A production WordPress stack (managed hosting, premium theme, essential plugins) typically runs $200–$600/month for mid-market sites. A comparable Drupal deployment on Pantheon or Acquia starts at $500–$1,000/month for hosting alone. Premium plugins like ACF Pro ($149/yr) and WPML ($99–$199/yr) add meaningful but predictable annual costs.

Best for: Teams that want the largest ecosystem, broadest talent availability, and lowest hosting floor — particularly when editors need to operate independently without developer support.

Craft CMS: best for structured content modeling

Craft CMS is a commercial CMS built on PHP (Yii2 framework) that prioritizes rigorous content modeling and a clean editorial interface over pre-built themes. For teams accustomed to Drupal's fieldable entities and taxonomy systems, Craft is the most logical lateral move.

Craft's content engine maps neatly to Drupal concepts. Drupal Nodes become Craft Entries. Drupal Vocabularies become Craft Categories. Drupal Paragraphs translate directly to Craft Matrix blocks, which provide a significantly better authoring experience natively — authors add, reorder, and configure content blocks without developer intervention.

Pricing: Solo is free for a single user. Self-hosted Team is $279 per project; Pro is $399 per project — both include one year of updates, with renewals at $99/year (Team) and $199/year (Pro). Cloud-hosted options bundle the license with managed hosting: Team at $120/month and Pro at $240/month per project on annual billing. Enterprise tiers are custom-quoted. Hosting on a managed platform like Servd or standard VPS infrastructure adds $50–$200/month. The primary TCO driver is the initial frontend rebuild, not software licensing.

Migration trade-offs:

• Craft assumes you have a frontend developer. There is no theme marketplace. You write Twig templates from scratch or configure Craft as a headless API via GraphQL or the Element API plugin.
• The plugin ecosystem is smaller than WordPress or Drupal. Verify that the specific functionality your Drupal modules provide has a Craft equivalent before committing — use the module compatibility matrix above.
• No built-in multisite in the WordPress sense. Multiple sites require multiple Craft installs or a custom Craft setup using Craft's Sites feature, which supports multiple locales within one install but not fully independent sites with separate schemas.
• The developer community is smaller, though Laravel/PHP developers adapt within days given the shared Twig templating and PHP paradigm.

Best for: Content-heavy sites with complex, structured content models — editorial teams, publishers, and agencies that value content architecture and editor UX above ecosystem breadth.

Strapi: open-source headless for API-first teams

Strapi is an open-source headless CMS built on Node.js that provides both REST and GraphQL APIs out of the box. Unlike Drupal's JSON:API layer, Strapi is purpose-built for headless delivery — the content modeling UI, API generation, and permission system are all designed for this use case from the start.

Pricing: Self-hosted Community Edition is free under the MIT license — you own the code and can self-host on any infrastructure. Strapi Cloud starts at $29/month (Developer), with Pro at $99/month and Team at $499/month. Self-hosting on a VPS (DigitalOcean, Hetzner, AWS Lightsail) runs $10–$50/month in infrastructure costs for most mid-market workloads.

Why it fits Drupal teams going headless: Drupal 11 supports JSON:API and GraphQL, but running Drupal as a headless backend means paying its full complexity tax — PHP/Symfony operational overhead, Drupal-specific developer knowledge, and Acquia/Pantheon hosting costs — while discarding the frontend entirely. Strapi provides a purpose-built headless API layer with a simpler content modeling UI and lower operational overhead for teams that don't need Drupal's advanced permission system or workflow capabilities.

Migration trade-offs:

• No built-in frontend. You need a separate application (Next.js, Nuxt, Astro) and the engineering capacity to build and maintain it — this is typically the largest cost in a Strapi migration, not the CMS itself.
• Drupal's entity-reference and taxonomy systems have no direct Strapi equivalent — you'll model relationships using Strapi's relation fields, which work differently and require remapping during migration.
• Strapi's plugin/provider ecosystem is growing but far smaller than Drupal's 50,000+ contributed module library. Complex functionality (commerce, advanced search, workflow) requires custom development or third-party services.

Best for: Developer-led teams building API-first or multi-channel architectures who want full code ownership without vendor lock-in. Particularly strong when the same content must be delivered to web, mobile, and other channels simultaneously.

Sanity: managed headless for composable architectures

Sanity is a fully decoupled, API-first content platform—often evaluated alongside Contentful alternatives—where structured content is stored as JSON documents in a managed cloud datastore (Content Lake) and queried using GROQ (Sanity's query language) or GraphQL. Unlike Strapi, Sanity is a managed service — you don't provision or maintain the backend infrastructure.

This is a fundamentally different model from Drupal's relational SQL database. Content is document-oriented, not row-oriented, which simplifies some modeling (nested structures, flexible schemas) and complicates others (complex relational queries, large-scale reporting).

Pricing: Sanity's free tier includes 2 datasets, 500K API requests/month, and 10GB bandwidth. Growth tier is $15/user/month with higher API and bandwidth limits. Enterprise contracts are custom-quoted and regularly exceed $20,000 annually for organizations with high API request volumes or large media assets. Factor in frontend hosting costs (Vercel starts at $20/month for Pro, Netlify at $19/month for Pro) and the higher market salaries for specialized React/Next.js developers when calculating total cost.

Composable architecture means your content layer, frontend layer, commerce layer, and search layer are independently deployed and connected via APIs — no monolithic CMS owns all concerns. Sanity is designed to function as the content node in this model. This is appropriate when you need to serve content to multiple frontends simultaneously or when different parts of your stack must scale independently.

Migration trade-offs:

• Adopting Sanity requires a complete architectural paradigm shift — it is not a drop-in CMS replacement. Your frontend must be built and hosted entirely separately, content previews require configuration between your framework and Sanity Studio, and GROQ is a proprietary query language with a learning curve.
• If your team lacks strong React and API integration skills, this route will stall. Budget for training or specialized hiring.
• Sanity's content model is document-based. Drupal's deeply relational content (entity references across five content types, complex taxonomy hierarchies) requires deliberate remapping, not mechanical migration.

Best for: Engineering-led organizations moving toward composable, multi-channel architectures with modern JavaScript frameworks (Next.js, Nuxt, Astro). Not appropriate for teams that need a working site without significant frontend engineering investment.

Backdrop CMS: the Drupal 7 fork

Backdrop CMS is a direct fork of Drupal 7 that preserves its architecture while adding modern features: configuration management (analogous to Drupal 8's CMI), a layout system, improved Views integration in core, and better mobile admin UX. It is free and open-source under the GPL license.

Community and ecosystem: Backdrop's contributed project library includes approximately 1,000+ modules, compared to Drupal's 50,000+. The community is small but active, with regular point releases. There is no commercial managed hosting equivalent to Acquia or Pantheon — most Backdrop sites run on generic LAMP-stack VPS hosting or shared hosting at $5–$30/month. A basic Backdrop VPS deployment typically costs $10–$40/month on DigitalOcean, Hetzner, or Linode.

For organizations on Drupal 7 that don't need (or can't afford) a full platform migration, Backdrop is the shortest path off an unsupported codebase. Drupal 7 modules can often be ported to Backdrop with minor modification — many core APIs are preserved. The learning curve for existing Drupal 7 developers is near zero.

Migration trade-offs:

• Backdrop's module ecosystem covers common use cases (Views, Webform, CKEditor, token, pathauto equivalents exist) but enterprise-grade modules for commerce, search, or complex SSO integration are limited. Audit your required functionality against the Backdrop project directory before committing.
• It's a pragmatic stabilization move, not a growth platform. If your needs are expanding toward headless delivery, complex personalization, or large-scale multisite, Backdrop won't scale with you. Plan for a second migration in 3–5 years if your requirements evolve.
• No hosting providers specialize in Backdrop at the managed level. Operational responsibility for security patching, server maintenance, and uptime falls entirely on your team or a generalist managed-hosting provider.

Best for: Small-to-mid-size Drupal 7 sites (under 50,000 nodes, limited third-party integrations) that need to exit EOL software quickly without a complete rebuild. Not appropriate for organizations with enterprise requirements or growth trajectories that will stress Backdrop's ecosystem limits.

TYPO3: enterprise multisite and multilingual

TYPO3 is a free, open-source enterprise CMS based on PHP (TYPO3 core team, long-term releases every 2 years) that is dominant primarily in the DACH region (Germany, Austria, Switzerland) and broader Europe. One installation can manage dozens of independent sites with sophisticated, workflow-driven translation management.

TYPO3's multisite and multilingual capabilities are built deep into core — not bolted on through plugins. The Site Configuration system handles multiple domains, languages, and fallback chains natively. For organizations managing 10+ country sites with complex translation workflows, TYPO3 handles this natively in cases where Drupal requires contributed modules (Domain Access, TMGMT) and WordPress requires WPML and additional network configuration.

Pricing: The core CMS is free. Implementation costs for enterprise TYPO3 projects typically range from $30,000 to $300,000+ depending on the number of sites, languages, custom extensions, and integration complexity. TYPO3 GmbH offers Long-Term Support (LTS) releases (currently v12 LTS, supported through October 2026; v13 LTS in active support) and commercial support subscriptions for enterprises requiring SLA-backed assistance.

Migration path from Drupal: There is no automated Drupal-to-TYPO3 migration tooling. A Drupal→TYPO3 migration is a full ETL project: extract structured content from Drupal's EAV schema, transform to TYPO3's page/record model, and load via TYPO3's DataHandler API or direct database import. Content types map to TYPO3 table-based records; Drupal Paragraphs require mapping to TYPO3's content elements or the Fluid Styled Content framework. Plan for 6–18 months of implementation depending on site complexity.

Migration trade-offs:

• Outside Germany, Austria, Switzerland, and the Netherlands, finding experienced TYPO3 implementation partners is difficult. Agency capacity constraints are a real project risk.
• The learning curve is steeper than WordPress and comparable to Drupal — TYPO3's TypoScript configuration language and its extension architecture are not analogous to any other platform.
• TYPO3 extensions (the equivalent of Drupal modules) number approximately 3,500+ in the Extension Repository (TER), covering most enterprise use cases in the European market. Outside that ecosystem, gaps exist.

Best for: European enterprises managing content across 5+ countries and languages, particularly organizations in regulated industries (finance, healthcare, public sector) where TYPO3's LTS release model and German-market vendor ecosystem provide predictable, long-term support.

Three-year TCO comparison

Total cost of ownership includes licensing, hosting, implementation, and ongoing maintenance. These figures represent mid-market deployments — not the floor or ceiling. Support contracts (available for WordPress via VIP support, for Drupal via Acquia or Pantheon plans, and for TYPO3 via TYPO3 GmbH) are not included in license costs below but add $5,000–$50,000 annually for enterprise SLA coverage.

Platform	License (3 yr)	Hosting (3 yr)	Implementation profile	Talent availability
Drupal 11 (Pantheon)	$0 (open-source)	$18,000–$108,000	Existing D10 teams can upgrade; D7 requires a rebuild	Declining
Drupal 11 (Acquia)	$0 (open-source)	$50,000–$200,000+	Same as above; Acquia adds DXP tooling	Declining
WordPress (managed)	$0 (open-source)	$2,400–$7,200	Lower than Drupal for equivalent functionality	Very high
WordPress VIP	$0 (open-source)	$72,000+	Enterprise-grade, includes platform support	Very high
Craft CMS (self-hosted Pro)	$399 + $398 renewals	$1,800–$7,200	Moderate; content modeling is the main effort	Moderate
Strapi (self-hosted)	$0 (MIT)	$600–$5,400	High if building a frontend from scratch	Growing
Sanity (Growth/Enterprise)	~$1,620–$60,000+ (usage-based)	Included in subscription (+frontend hosting ~$720–$2,400)	High — separate frontend required	Growing
Backdrop CMS	$0 (open-source)	$600–$3,600	Low for D7 sites; minimal for the CMS layer	Small but stable
TYPO3	$0 (open-source)	$1,800–$12,000	$30K–$300K+ for enterprise implementations	Regional (Europe)

Content volume thresholds and migration complexity tiers

Migration complexity scales with content volume, schema depth, and integration count — not just node count. Use this framework to bracket your project before scoping:

Tier	Indicators	Typical data migration timeline	Risk profile
Small	<10,000 nodes, <5 content types, no Paragraphs, no multilingual, <5 integrations	1–3 business days	Low
Medium	10,000–100,000 nodes, 5–15 content types, Paragraphs in use, 1–2 languages, 5–15 integrations	3–7 business days	Medium
Large	100,000–500,000 nodes, 15+ content types, deep Paragraphs nesting, 3+ languages, 15+ integrations, Solr/media DAM	7–13 business days	High
Enterprise	500,000+ nodes, complex entity reference chains, 5+ languages, custom Drupal modules with no target equivalent	Custom engagement, 2–6 weeks	Requires pre-migration audit

The most common complexity multipliers encountered in Drupal migrations:

• Deep Paragraphs nesting (3+ levels): requires recursive extraction and editorial decisions about how to flatten or preserve structure in the target platform
• Multilingual content with untranslated fallbacks: requires mapping Drupal's translation entity model to the target platform's locale system
• Entity reference chains: circular or multi-hop references between node types require dependency-ordered import sequencing to preserve referential integrity
• Custom module logic: workflow hooks, entity presave operations, and computed fields in custom Drupal modules may have no declarative equivalent on the target platform

What actually moves in a Drupal migration — and what doesn't

A Drupal migration has two separate efforts with different timelines and teams:

The data migration moves structured content — nodes, taxonomy terms, users, files, media — from Drupal's database to the target platform. This is extract-transform-load (ETL) work that can be scoped, automated, and completed in days. Extraction preference: API first (Drupal's JSON:API or REST), JSON export second, CSV as a last resort.

The platform rebuild is the design, development, and QA of the new site: themes, templates, custom functionality, integrations, editorial workflows. This is a separate project measured in weeks or months.

Keeping these two efforts distinct matters for planning. The data migration can run in parallel with the rebuild, with a final delta sync at cutover to capture content published during the rebuild period. Conflating them produces inaccurate scopes, missed dependencies, and unrealistic timelines.

Technical challenges in Drupal data extraction

Extracting data from Drupal is notoriously difficult due to its Entity-Attribute-Value (EAV) database architecture. Content is not stored in a single table — a single Drupal Node might have its data scattered across dozens of node__field_* and field_revision_* tables. A node with 20 custom fields requires joining across 20+ tables, and that join count scales with the number of fields and field types. Complex Drupal schemas can involve 300–500 database tables, with content spread across node, field_data, taxonomy, file, and paragraph entity tables simultaneously.

Paragraphs and field collections

The Paragraphs module (or older Field Collection) creates nested, referenced entities for flexible page layouts. These are the most complex structures to migrate because they encode layout intent, not just content. Extracting them requires recursive queries to flatten the data into a JSON payload suitable for a modern block editor. Flattening Paragraphs for a platform that doesn't natively support nested content requires transformation decisions that are editorial, not just technical — an editor or content strategist should be involved in defining the target structure, not just a developer.

Entity references

Drupal's entity reference fields create relationships between content types (Nodes, Users, Taxonomies). During migration, legacy Drupal entity IDs must be mapped to the new platform's IDs to maintain referential integrity. Import order matters: referenced entities must exist in the target system before the entities that reference them are imported. The target platform's relationship model varies significantly: WordPress uses post meta + ACF, Craft uses entries and relations fields, Strapi and Sanity each model relations differently still.

Multilingual content

Drupal's core translation system stores translations as separate entities linked by a translation set identifier. The migration must extract base content, its translations, and the relationship between them, then reconstruct that relationship in whatever locale model the target platform uses. This is rarely a direct mapping and requires platform-specific transformation logic.

URL aliases and redirects

SEO preservation is non-negotiable. Years of Pathauto-generated URLs, manual aliases, and redirect chains need to be extracted and mapped to the target platform's URL structure with 301 redirects. Sites that fail to implement 301 redirects for high-authority URL aliases typically see 20–40% organic traffic decline in the first 90 days post-migration as search engines process URL changes and update their index. Missing redirect coverage is the fastest way to lose accumulated organic authority. Extract all URL aliases from the path_alias table before any cutover work begins.

How to scope a Drupal migration realistically

Start scoping at least 3–4 months before any internal deadline or legacy contract expiration. Here's what the scoping phase should cover:

1. Audit your Drupal version and modules. Which version? Which contributed modules are in active use? Cross-reference against the module compatibility matrix above to identify functional gaps on the target platform.
2. Map content types and fields. Export your content type definitions and field configurations. Count content items per type. Identify Paragraphs usage depth (how many nesting levels?), entity reference chains, and taxonomy hierarchy depth.
3. Inventory media and files. Total file count, total storage size, and whether files are stored locally on the Drupal server, on S3/object storage, or in a separate DAM. File migration is often underestimated — 50,000 media entities with associated file system paths require careful mapping.
4. Document URL structures. Export all URL aliases from path_alias. Identify redirect chains. Plan the 301 redirect strategy before the migration, not after.
5. Identify integrations. CRM connections, marketing automation, search (Solr/Elasticsearch), commerce, authentication (SSO/LDAP) — each integration that touches Drupal needs a counterpart on the target platform. This is where custom Drupal module functionality creates the highest risk of blocking a migration.
6. Separate the data migration from the rebuild. Get a fixed-price quote for the data migration as a discrete deliverable. Scope the platform rebuild separately with your development team or agency. These are different work products with different risk profiles.

The ClonePartner migration process

We connect directly to the underlying systems, preferring API extraction first (Drupal's JSON:API), JSON second, and CSV as a last resort. We don't rely on generic export modules.

Our process follows a consistent pattern:

1. Connect Accounts. Establish secure connections to your legacy Drupal database or API and your target CMS.
2. Migration Checklist. A dedicated migration engineer maps every field, taxonomy, user role, and media relationship.
3. Sample Migration. We run unlimited sample migrations until the data structure maps correctly in the target system. You verify the output before we proceed.
4. Full Migration. Execute the complete data transfer using checksums, record-count parity checks, field-level validation, and referential integrity checks.
5. Delta Sync. Run background syncs to capture content published on the Drupal site during the migration window, enabling a zero-gap cutover with no content loss.

Migration timelines by content volume tier: small datasets (under 10,000 nodes) typically complete in under 24 hours. Medium datasets (10,000–100,000 nodes) complete in 3–7 business days. Large and enterprise datasets with deep Paragraphs nesting, multilingual content, and extensive entity reference chains require 7–13+ business days and a custom engagement scoped after an initial audit.

When staying on Drupal still makes sense

Not every Drupal site should migrate. If you're already on Drupal 11, your contributed modules are actively maintained, your team has Drupal expertise, and your content architecture uses Drupal's strengths — complex permissions, granular content workflows, decoupled delivery via JSON:API — staying may be the right call.

Drupal 11 shipped meaningful improvements: automatic security updates for core and contributed modules, the Project Browser for in-admin module discovery and installation, Workspaces for content staging across environments, and the Navigation module for a modernized admin sidebar. These reduce the operational overhead that drives many migration decisions.

The question isn't whether Drupal is a good CMS. It is. The question is whether Drupal's operational costs — developer scarcity, upgrade complexity, hosting overhead — still justify its technical capabilities for your specific use case and team structure.

Picking the right alternative

Match the alternative to the problem you're actually solving:

• "Our editors can't work without a developer" → WordPress (Gutenberg) or Craft CMS (Matrix fields + clean admin)
• "We can't find Drupal developers" → WordPress (deepest talent pool) or Craft CMS (Laravel/PHP developers adapt within days)
• "We need API-first delivery to web and mobile" → Strapi (code ownership) or Sanity (managed, real-time collaboration) — or evaluate headless Drupal 11 if your content model is too complex to rebuild
• "We need to get off Drupal 7 fast with minimal disruption" → Backdrop CMS (if under 50,000 nodes and limited integrations)
• "We manage 10+ country sites with complex translation workflows" → TYPO3 (if European ecosystem access is feasible) or stay on Drupal 11
• "Our hosting costs on Acquia are unsustainable" → WordPress on managed hosting, or self-host Drupal 11 on a VPS with Composer-based deployment
• "We use Webform or Rules extensively" → WordPress with Gravity Forms + Automator, or custom development on the target platform — no platform offers a drop-in equivalent

If the CMS & DXP End-of-Support Calendar is driving your timeline, separate the urgent work (getting off unsupported software) from the strategic work (choosing the right long-term platform). For teams running a CMS past its end-of-support date, the risk playbook covers the exposure in detail.

Pricing and engagement model

ClonePartner operates on one fixed price per project, starting at $500. No hourly billing, no hidden fees, no change orders, and no per-record metering. Your quote is driven by data volume, schema complexity, and the specific platforms involved.

You're assigned a dedicated migration engineer who owns your project end-to-end. Migration delivery is backed by a defined validation checklist: record-count parity, checksum verification, referential integrity checks, and a post-migration delta sync to capture any content published during the migration window.