The best Drupal alternative depends on what must survive the move and who will operate the destination. First determine whether the problem is Drupal 7’s end of life, the complexity of the current site, or the organization’s operating model. Consider modern Drupal when existing capabilities still fit, Backdrop when a compatible Drupal 7 site needs continuity, WordPress when self-hosted flexibility and extension governance are acceptable, and hosted or commerce-focused platforms only after confirming their data and feature fit.
Drupal 7 reached end of life on January 5, 2025. Drupal.org no longer provides official community security or compatibility updates for it. That does not make Drupal obsolete: Drupal Core and Drupal CMS remain active products. The practical question is whether your current capabilities, team, and operating responsibilities still fit Drupal.
A migration decision is not a feature-count exercise. It is a decision about preserving content relationships, workflows, permissions, URLs, integrations, and operational ownership. A site with 150 pages and bespoke commerce can be harder to move than a larger site built from standard content patterns.
Start with the source site’s migration profile
Before comparing Drupal alternatives, inventory what the site does and why each capability matters. Group the findings into five areas:
- Content and data: content types, fields, taxonomy, media, revisions, multilingual content, multisite requirements, files, and URL aliases.
- Behavior and workflow: editorial states, forms, search, filters, user roles, permissions, approvals, notifications, and scheduled publishing.
- Presentation: templates, layouts, responsive behavior, design requirements, accessibility, and reusable components.
- Integrations: analytics, CRM, commerce, identity, search services, APIs, webhooks, and custom code.
- Operations: hosting, backups, updates, security reviews, privacy, consent, analytics, and the people responsible for ongoing changes.
Mark each capability required, replaceable, or retired. A business or technical owner should approve every status. Then record a candidate, migration method, and acceptance test for each required capability.
A useful inventory can begin as a spreadsheet with these fields:
capability_id, source_component, business_owner, required_status, target_candidate, migration_method, acceptance_testKeep the source database, files, code, configuration, module inventory, and URL list as the reference record. Do not shortlist a destination until every required capability has a credible implementation route and an owner who can approve the result.
Choose the CMS only after every must-keep capability has an owner, an implementation path, and a test.
Compare migration paths, not just CMS labels
Use the same capability inventory for every candidate. The important difference is whether the destination preserves a Drupal-like operating model or requires a different content model, delivery approach, and ownership structure.
| Candidate | Strongest fit | Migration shape | Decision gate |
|---|---|---|---|
| Modern Drupal | Drupal capabilities still fit | Migrate content and configuration, rebuild the theme, and assess contributed or custom functionality | Can the organization fund migration and ongoing Drupal ownership? |
| Backdrop CMS | Compatible Drupal 7 site where continuity and self-hosting matter | Use Backdrop’s documented upgrade route with preparation, backups, compatibility review, and testing | Do required modules, themes, layouts, and custom code have a workable path? |
| WordPress | Self-hosted flexibility with extension governance | Rebuild the content model and select or develop themes, plugins, and integrations | Who will test, update, and support each extension? |
| HubSpot Content Hub | Hosted CMS and HubSpot operating environment | Plan a rebuild or obtain a scoped migration-services proposal | Are content, redirects, forms, search, access, and integrations explicitly covered? |
| Shopify | Commerce is the dominant system and fits Shopify’s model | Map products, variants, orders, inventory, content, and commerce rules | Do the selected plan’s APIs and commerce functions meet requirements? |
| Webflow | Design-led publishing with suitable structured content | Map content into collections and verify plan-specific publishing and API limits | Do capacity, relationships, permissions, and export needs fit? |
Drupal’s migration overview describes moving Drupal 6 or 7 sites to Drupal 10 or later as a migration, not a simple in-place update. Content and configuration can be migrated, themes need rebuilding, and contributed or custom functionality may require additional work. This does not mean every element must be rebuilt.
Backdrop documents a dedicated Drupal 7 upgrade route, but it is not a one-click conversion. The process includes preparation, backups, compatibility review, database work, and checks of themes, layouts, views, and contributed projects. Retain the old site for comparison.
WordPress is self-hosted and extension-based. An available plugin is not proof of compatibility or suitability. WordPress’s plugin guidance supports a governance approach: record the maintainer, tested versions, license, data export route, update history, and maintenance owner for every proposed extension.
HubSpot confirms that it offers website migration services, but its public migration-services page does not establish a universal Drupal import method, delivery duration, redirect workflow, or feature-coverage guarantee. Treat a hosted rebuild as unconfirmed until a scoped proposal assigns those deliverables. Shopify’s plan information and Webflow’s pricing and plan information describe plan-dependent capabilities and limits. Verify the selected plan before designing an import.
Backdrop or modern Drupal
These paths are strongest when the existing data model, self-hosting preference, and technical capabilities remain valuable. Both still require component-level migration testing.
WordPress or a hosted or commerce platform
These paths can reduce or redistribute operational work, but they generally require mapping or rebuilding content, workflows, integrations, and ownership around a different product model.
Use a staged migration workflow with named outputs
Run a representative test migration before authorizing the full move. The migration engineer should own mapping and the test environment. Content and business owners should approve meaning and behavior. The site owner should approve release readiness.
A screenshot can confirm visual similarity, but not functional parity. Test record relationships, access control, editorial workflow, form delivery, search results, and integration behavior separately.
Use deterministic rules before AI
Most migration decisions should be explicit rules. Exclude unpublished content, flag missing identifiers, detect duplicate source IDs, and route unsupported field types to review. AI is appropriate only when a record’s meaning cannot be mapped reliably to an approved target vocabulary.
For that optional classification step, keep the source database as the system of record and store the suggestion in a reviewed migration mapping queue. Send only the necessary excerpt and source ID. Validate the returned structure and allowed values, compare the source hash with the current record, and send low-confidence or contradictory results to the content model owner. AI must not write directly to the destination.
{
"source_system": "drupal7",
"source_record_id": "node-4812",
"source_hash": "sha256:illustrative-content-fingerprint",
"decision": "review",
"target_content_type": "approved-type",
"confidence": 0.72,
"policy_version": "mapping-policy-01"
}This is an illustrative operational pattern, not a schema supplied by a CMS vendor. Save the policy version, model information, reviewer decision, and source hash where auditability matters. Write only after approval and a current-source check.
A read-then-insert check can create duplicates when two workers process the same record. Define the true row grain, enforce a database uniqueness constraint, and use a transactional upsert or insert-on-conflict operation. For a migration record, a practical key may be source system plus source record ID plus target environment. Add a source version or content hash so retries can distinguish changed content from completed work.
Protect URLs and organic search during the move
A CMS does not guarantee search performance. Migration risks include changed URLs without redirects, lost metadata, incorrect canonicals, broken internal links, inaccessible pages, and indexing mistakes. Treat URL reconciliation as its own release dataset, not as a note attached to a page.
Use one row per legacy URL per migration release. Useful fields include release_id, legacy_url, target_url, redirect_status, canonical_target, source and target status codes, hreflang_group, sitemap_inclusion, and validation_timestamp. Several old URLs may intentionally point to one destination, so the target URL alone is not a unique key.
- Every legacy URL has an approved destination, an intentional unchanged status, or a documented retirement outcome.
- Redirect tests cover chains, loops, query strings, case, trailing slashes, media URLs, pagination, and deliberately removed pages.
- Target responses, canonicals, metadata, internal links, and sitemap inclusion match the approved mapping.
- Staging and production crawls are reviewed before and after launch.
- The owner monitors indexed URLs, crawl errors, traffic, and conversions after release.
Scope cost, schedule, and ownership honestly
There is no reliable universal price or schedule for a Drupal migration. Cost and duration depend on content and data-model complexity, custom code, integrations, commerce, multilingual or multisite requirements, design scope, testing, redirects, and governance.
Ask delivery partners to estimate against the same scope: inventory, mapping, migration, design, integrations, SEO reconciliation, quality assurance, launch support, and post-launch ownership. Request a scoped discovery and test migration before accepting a firm estimate. HubSpot’s public page confirms that migration services are available, but duration and specific deliverables should be confirmed in a proposal rather than inferred from the service page.
Hosted products can reduce infrastructure and core-update responsibilities, but the organization still owns content governance, permissions, integration decisions, privacy, redirects, analytics, subscription management, and vendor-change planning. Decide who will maintain extensions and custom code, manage access, and retain migration records after launch. Teams clarifying these responsibilities can review ConsultEvo’s systems consulting services.
Make the final choice with acceptance gates
- Choose Backdrop when a Drupal 7 site is compatible, its current data model remains suitable, and continuity and self-hosting matter. Test modules, themes, layouts, views, database behavior, and custom code first.
- Choose modern Drupal when the organization still needs Drupal’s capabilities and can fund migration, theme rebuilding, custom functionality, and ongoing technical ownership.
- Choose WordPress when self-hosted flexibility fits and an accountable owner can govern extensions, updates, compatibility, security, and data exports.
- Choose a hosted CMS when reduced infrastructure ownership outweighs unrestricted code-level control. Confirm how every required Drupal capability will be handled and who owns the resulting configuration.
- Choose Shopify when commerce requirements fit its product, inventory, checkout, and integration model. Test products, variants, customers, orders, tax, currency, discounts, inventory, and fulfillment separately.
- Choose Webflow only after verifying CMS capacity, collection and API limits, publishing controls, relationships, permissions, and export requirements against the actual target design.
Reject an exact-replica promise until the target has been assessed for data relationships, templates, roles, workflows, forms, search, integrations, analytics, and consent. Then shortlist two candidates, map every must-keep capability, and run a representative test migration. Approve a full rebuild only when each required item has a named owner, a verified implementation path, and a testable acceptance condition.