Migrate from Sitecore to Drupal

Migrate from Sitecore to Drupal: what moves and who does the work

Content, structure and media move to Drupal, but renderings are rebuilt and xDB and personalization do not carry over. That is the core of the migration whether your pressure comes from a renewal, a SitecoreAI lifecycle decision or a requirement to host in your own data center. Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, and those items need separate rebuilding on any target. Expect the template and item model to map to Drupal content types, paragraphs and taxonomies, while every Sitecore rendering, controller and view must be rewritten as Drupal theme and component code. Confirm early which Sitecore modules your estate uses, because each one has to be mapped, replaced or dropped.", "In most estates an internal platform or digital team owns the migration, with an implementation partner doing the heavy lifting on content mapping, theme build, hosting and cutover. The internal team should keep ownership of the content model, editorial workflow and sign-off on each site in the multi-site structure. Effort and risk concentrate in three places: multilingual content and URL redirects, media migration, and identity integration. Drupal's SAML Authentication module (samlauth) and the OpenID Connect module cover common single sign-on paths, but you should verify both against your identity provider before scoping. Ask any partner for a written inventory of renderings, sites and languages before agreeing a fixed scope.", "Drupal core and its contributed modules are GPL-2.0-or-later, and there is no paid edition of Drupal itself. That means you do not pay a license fee to adopt the platform, so your costs shift to implementation, hosting, security updates and ongoing support. Those costs recur, and they depend on how many sites you run, how often you release, and whether you buy a retainer for upgrades. Plan your target major version against the Drupal core release schedule, since Drupal 10 reaches end of life on December 9, 2026 and Drupal 12 is scheduled for the week of December 7, 2026. Any quote should separate one-time build and migration work from recurring hosting, support and upgrade effort."]}

Which Sitecore capabilities map to Drupal, and which need rework

This table compares common Sitecore XP and XM capabilities with their Drupal counterparts and marks each as clean, needs rework or gap. Read the status column first, then the Drupal column for the component you would build. Items, templates, multi-language and roles usually map cleanly in concept, while renderings, forms, xDB and personalization require rebuilding or separate tools.

Sitecore capability	Drupal equivalent	Status
Items and templates	Content types with fields, entity references and taxonomy; the item tree becomes a content model you design, not a direct copy	Clean
Renderings and layouts (MVC or SXA)	Drupal Canvas or Twig components with Layout Builder regions; SXA rendering variants must be redesigned as components	Needs rework
Multi-site structure	Multiple sites on one codebase or separate sites sharing configuration and content types	Clean
Multilingual setup	Language and Content Translation modules, with translation workflow configured per content type	Needs rework
Roles and users	Drupal roles and permissions; user accounts must be exported and re-created, and passwords are not portable	Needs rework
Forms	Webform or core-based forms; multi-step logic and CRM hand-offs need rebuilding and testing	Needs rework
Search	Drupal Search API with a self-hosted engine such as Solr or OpenSearch; facets and synonyms are rebuilt	Needs rework
Personalization rules and xDB	No equivalent in Drupal core; visitor analytics and segmentation need separate tools and rebuilt rules	Gap
Marketing Automation, EXM and Path Analyzer	Handled by separate self-hosted tools such as Mautic; campaigns and journeys are rebuilt, not migrated	Gap

Which data can be exported from Sitecore and what has to be rebuilt

Sitecore gives you a documented path for content structure, roles and users, but the visitor data, personalization logic and email marketing assets sit outside it. Each card below separates what moves into Drupal from what you must rebuild or re-collect, and what to confirm with your Sitecore team before scoping the migration.

Content items through serialization

Sitecore Content Serialization writes items, roles and users to YAML files, and the module configuration decides which parts of the content tree are included. For a Drupal migration, these files are the inventory you map to content types, paragraphs and taxonomies. Check which modules scope your serialized tree, because items outside those scopes will not appear in the export. Confirm with your Sitecore team whether any items exist only in the database and were never serialized.

Media files and asset references

Serialized items reference media by ID, but the binary files for images, documents and video must be exported separately from the Sitecore media library. Plan to download each file, keep the original filenames and alt text where they exist, and rewrite media references as Drupal media entities during import. Check file sizes, duplicate assets and any media stored on a CDN outside Sitecore, since those links can break when the old domain is retired.

xDB contacts and analytics

Sitecore's migration guide states that xDB data does not migrate to SitecoreAI, and the supplied facts give no export path for contact profiles or interaction analytics. Treat these as data you must either retain in an archive for retention obligations or stop collecting. Visitor analytics can be rebuilt on Matomo, but historical contact records do not carry over automatically, so ask your privacy team what must be kept and for how long before decommissioning.

Personalization rules and email marketing content

Personalization rules, segments and the email marketing content used by EXM and Sitecore Send have no supplied export path, and the migration guide says personalization must be rebuilt. Recreate audience logic in Mautic or the marketing tool you select, and rewrite each rule as a documented condition with an owner. Use an inventory of live campaigns to decide which templates are worth rebuilding and which can be retired.

Identity through SAML and OpenID Connect

Sitecore users and roles are exported as YAML, but passwords and live sessions do not move, so users will sign in against your new identity source. In Drupal, the contributed samlauth module lets the site act as a SAML service provider, and the OpenID Connect module creates accounts on first sign-in. Confirm which protocol your identity provider supports, map Sitecore roles to Drupal roles manually, and test account provisioning before cutover.

Forms and search integrations

Sitecore Forms definitions and submission data sit outside the content tree, so each form must be rebuilt in Drupal with a webform or equivalent module and its submissions exported separately if you need them. Search indexes and third-party connectors are also rebuilt, not copied. Inventory every form, its recipients and any CRM or search connection, then test submission handling and indexing against the new site.

How multi-site and multilingual structure maps onto Drupal

Decide how many Drupal sites you need before building anything, because Sitecore site definitions do not map one to one onto Drupal. In Sitecore, a site definition binds a start item, host names, a language and a set of settings to one content tree, and several sites often draw on the same items in the shared content tree. In Drupal, the main options are separate sites with their own codebases, or one shared codebase that runs several sites through the multisite support in core, where each site has its own settings file and database. Map every Sitecore site definition to a candidate Drupal site, then group the candidates by editorial owner, brand and compliance boundary. Shared navigation, legal text and product data need their own decision about where they live.

Language versions in Sitecore are stored per item, and Drupal handles translations as translations of the same entity, enabled through the core Language and Content Translation modules. Work out which content types are translatable, whether each language gets its own URL prefix or domain, and which field values are shared across languages, such as images or product codes. Pay particular attention to translation fallback. Confirm how missing translations behave on the current Sitecore sites, since a missing version can fall back to the source language in one platform and render an empty page in another. Also plan hreflang output, language-specific path aliases and the translation workflow that feeds content into the site.

Sitecore templates that are shared across sites become Drupal content types with a defined set of fields, and items in the shared content tree become entities that other sites reference through entity reference fields. Decide whether each shared item should be a reference or a copy. References keep one source of truth, while copies drift apart over time and create editorial errors that are hard to trace. Remember that sites in one multisite codebase run the same content type definitions, so a change to a shared content type affects every site at once and needs a release process with a staging check across all sites. Prototype one shared content type and one translated page with your editors before committing to the structure for the full estate.

How the Sitecore to Drupal migration runs, step by step

This sequence moves a Sitecore estate to Drupal in controlled stages, so each site is inventoried, proven on a supported Drupal version, run in parallel and cut over with a rollback path before Sitecore is switched off.

Inventory sites, templates and integrations
Build a register of every Sitecore site, its languages, domains, templates, renderings, placeholders, content items, media libraries, user roles and integrations such as forms, search, identity and analytics. Assign an owner to each site and mark which items are live content, which are unused, and which depend on xDB or personalization rules that will need rebuilding. The step closes when the inventory register is signed off by the content owners and the platform team, and every integration has a named replacement or a decision to retire it.
Map the information architecture to Drupal
Translate Sitecore templates into Drupal content types and fields, and map the site tree to Drupal menus, taxonomy and multilingual structure. Decide how multi-site shares components, configuration and users, and which content stays separate per site. Document renderings as the Drupal components or Layout Builder sections that will replace them. The output is a schema mapping document and a content model reviewed by editors, with each Sitecore rendering assigned to a Drupal target.
Build a pilot site on a supported Drupal version
Install a new Drupal site on a currently supported major version, confirm the PHP version and database the release requires, and rebuild one representative site end to end. Include the theme, navigation, one multilingual page set, search, forms and the identity connection you plan to use. Confirm the chosen core version against the Drupal core release schedule before the build starts. Note that Drupal sites are not upgraded in place from Sitecore, so the pilot is a new build. The step closes with a pilot sign-off by the business owner, covering accessibility, performance and editorial workflow.
Migrate content, media and users in batches
Export content from Sitecore using its serialization or database tooling, then transform items into Drupal entities with a migration pipeline built on the core Migrate framework. Move media files with their metadata and check references inside rich text. Import users only where authentication is planned, and assign roles from the register rather than copying Sitecore role names. Run each batch against a staging copy, record row counts and reconciliation errors, and repeat until a full load produces no unresolved mappings. The output is a reconciliation report per site and language.
Run Drupal in parallel with Sitecore
Keep Sitecore serving production traffic while Drupal runs on a separate hostname or staging environment. Editors author in Drupal for a defined set of pages and the team compares rendered output, search results, forms submissions and analytics events between the two systems. Track defects in a single register and fix content mapping issues at the source rather than by hand. The step closes when the agreed parity checklist is complete and the content owners accept the Drupal site as the authoritative version for cutover.
Cut over DNS and redirects
Write a cutover runbook that lists the DNS change, TLS certificates, redirect rules for every old URL that changed, cache purge steps, the freeze window for content edits and the rollback steps back to Sitecore. Rehearse the runbook on staging and confirm that the redirect map covers high-traffic and search-indexed URLs. Monitor error rates, redirect hits and form submissions after the switch. The output is a signed cutover runbook, a redirect map and a post-cutover monitoring record.
Decommission Sitecore and archive evidence
After a stable period agreed in the runbook, stop Sitecore publishing, revoke its service accounts and remove integration credentials. Export a final archive of content and configuration in a format your records team can read, and keep it under your retention policy. Record what was retired, what was rebuilt elsewhere, and what was intentionally dropped, including xDB data and personalization rules. Confirm the contract end date and any data return or deletion obligations with your vendor. The step closes with a decommissioning record approved by the platform owner and the compliance lead.

What drives cost and duration in a Sitecore exit

This table lists the factors that make a Sitecore to Drupal move larger or smaller, along with the cost components you will see in a quote. Read each row as a question to answer for your own estate before asking for a fixed-scope proposal. The main takeaway is that site count, language count, rendering complexity and personalization rules usually set the effort, while hosting and upgrades recur after launch.

Driver or cost component	Why it changes cost or effort	How to keep it down or what to ask for
Number of sites and shared components	Each site needs its own content model choices, navigation and theme work, and shared components reduce repeated build effort.	Inventory every site and shared module, then ask the quote to show site-by-site scope.
Languages and translation structure	Each language adds content migration checks, URL and hreflang setup, and translator workflow decisions.	Limit languages to those with live traffic, and ask how translated content is mapped and validated.
Rendering complexity	Sitecore renderings and MVC views must be rebuilt as Drupal components, so custom logic and layouts drive build time.	Group renderings by pattern, retire unused ones, and ask for a rendering-by-rendering rebuild list.
Media volume and asset quality	Large libraries add transfer time, metadata mapping, duplicate checks and broken-link fixes.	Archive unused assets, and ask how media files and their metadata will be moved and verified.
Integration count	Each CRM, search, forms, PIM or identity connection needs its own mapping, testing and credentials.	List every connected system and mark which ones must work on day one.
Personalization and marketing rules to rebuild	xDB contacts, analytics and personalization rules do not migrate, so each rule is rebuilt in a separate tool.	Export the rule list, prioritize the rules that carry revenue, and confirm which tools the quote includes.
Authentication scope	Single sign-on, roles and editor permissions must be designed again, and each identity provider adds testing.	Decide which user groups need SSO and ask how roles from Sitecore are mapped.
Internal team time	Your staff pay for content owner review, decision-making, and acceptance testing, which is often the largest hidden cost.	Ask the quote to name the roles and hours expected from your side.
Implementation partner and build	A partner is paid for planning, migration scripts, build, testing and documentation under a written, fixed scope.	Request a fixed-scope proposal with deliverables, acceptance criteria and a change process.
Hosting and ongoing upgrades	Hosting, backups, security patches and major version upgrades recur after launch, and PHP and Drupal version support affects timing.	Ask for the hosting model, backup frequency, and who applies patches and major upgrades.

How the migration differs by starting point

A single Sitecore site with a small number of languages is the most contained case. The content model is usually a few page templates, a navigation tree, a media library and one or two forms. Drupal's core content types, the Layout Builder and a single theme can cover this scope, and the migration can run as one project with a short cutover window. Scope is driven mainly by how many renderings must be rebuilt as Drupal components and how many languages need translation workflows.

Content model first: map each Sitecore template to a Drupal content type with fields, then confirm which renderings are purely presentational and can become theme components.
Language setup: enable the core language and content translation modules early so translated nodes exist before import, not after.
Media and redirects: plan URL redirects from old Sitecore paths, since search visibility is the main risk on a single site.
Forms and search: choose replacements for Sitecore Forms and site search during scoping rather than at cutover.
Drupal CMS option: for a marketing-led team, Drupal CMS recipes and site templates can shorten the build, but confirm that its components cover your layouts before committing.

Check with the implementation team whether the single-site estimate includes translation review, redirect testing and content owner sign-off.

What usually goes wrong and how to prevent it

Sitecore to Drupal projects tend to fail in predictable places: assumptions about what carries over, underestimated front-end work, and loose ends on SEO, access control and platform versions. Each card below names one failure and a check to run before cutover, so the scope you sign off reflects what the platform will actually do.

Assuming personalization and analytics will migrate

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, which must be rebuilt. Drupal will not import those either, so xDB contacts, rules and campaign content need their own inventory and replacement plan. Ask each stakeholder which personalization rules are live, and tag each one as rebuild, retire or move to a separate tool before you estimate the CMS migration.

Underestimating theme and rendering rebuilds

Sitecore renderings and MVC views do not become Drupal themes or components by export. Drupal's own documentation notes that themes must be rebuilt because they cannot be migrated, so each rendering needs a matching Drupal component, field mapping and template. Build a rendering inventory with a count per site, then prototype the most complex page types first to measure the real effort.

Losing SEO through missing redirects

Multi-site Sitecore estates often carry years of URL structure, language prefixes and legacy paths. If the new Drupal URL patterns differ and no redirect map exists, search rankings and inbound links break at cutover. Export the URL list from the live crawl and logs, map every old path to a new one per site and language, and test redirects in staging before DNS changes.

Mapping roles and permissions late

Sitecore roles, users and workflow states are defined in items and security settings that do not map one to one onto Drupal roles and permissions. Map each editorial role to a Drupal role per site and language, decide which permissions editors need in each content type, and confirm the identity provider path before go-live. If you use SAML or OpenID Connect, test group claims with real editor accounts, since the contributed samlauth and OpenID Connect modules create or map accounts differently.

Running an unsupported Drupal or PHP version

Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 is scheduled for the week of December 7, 2026. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later, and Drupal 12 requires PHP 8.5 or later. Target the current major version at launch, confirm the PHP version your hosting supports, and plan the next upgrade against the release schedule rather than treating the new site as finished.

Keeping Sitecore dependencies in the new stack

Teams often keep a Sitecore-hosted search, form or identity service running after cutover because nothing forces its removal. Each dependency that stays in the new stack keeps its license, hosting and support terms alive, and it can block a clean retirement of Sitecore. List every external call the current site makes, assign an owner and a replacement for each, and set a decommission date for the Sitecore environment in the project plan.

Questions buyers ask before hiring help for a Sitecore to Drupal move

What drives the cost of a Sitecore to Drupal migration?

The size and complexity of the estate drives most of the cost: the number of sites, languages, templates and renderings, the volume of content and media, and how much personalization logic must be rebuilt. Costs fall into one-time work (discovery, Drupal build, component rebuild, content migration, testing, cutover) and recurring work (hosting, Drupal and module upgrades, security patching, support). Sitecore license or SaaS fees and implementation partner charges are separate lines you should compare with the Drupal side. Ask any quote to split these lines so you can see what you pay once and what you pay every year.

How long does a Sitecore to Drupal migration take?

No researched duration applies to your estate, so treat any timeline as provisional until discovery is complete. The main variables are the number of sites and locales, how many renderings and components need rebuilding, the volume of media, and how many integrations (forms, search, single sign-on, marketing tools) must be replaced. Running the old and new sites in parallel usually extends the schedule but reduces cutover risk. Ask for a phased plan with milestones and a written scope before committing dates.

What does our team need to provide during the migration?

Your team needs to supply knowledge and decisions that exist only inside the organization: which sites and locales are live, which content is still in use, who approves the information architecture, which integrations are business-critical, and who signs off on each release. Engineers need access to the Sitecore environment, content and media exports, and the hosting environment where Drupal will run. A named product owner and a content lead for each site reduce rework. Confirm these responsibilities in the written scope.

Can our own team run a Sitecore to Drupal migration alone?

A team with strong PHP and Drupal experience can do much of the work in-house, especially the content model and theme work. The harder parts are usually the Sitecore rendering inventory, multilingual content mapping, media migration at volume, and cutover planning across several sites. Drupal 6 and 7 sites are not updated in place but migrated into a new site, and themes must be rebuilt, so the work is a rebuild rather than a copy. Assess your skills against the scope before deciding, and consider a fixed-scope engagement for the migration phase with your team retaining operations.

What cannot be exported from Sitecore?

Sitecore's migration guide states that the SitecoreAI pathway does not migrate xDB data, email marketing content or personalization, which must be rebuilt. Those items therefore need separate handling for a Drupal target. Content and templates are exported through Sitecore tooling such as serialization, and media files need their own export. Confirm with your Sitecore administrator which data sets exist in your environment, because analytics history, personalization rules and marketing data each require their own export or rebuild plan.

How do Drupal versions and PHP requirements affect planning?

Target the Drupal version you can support for the life of the site, and check its PHP requirement first. According to the Drupal core release schedule, Drupal 11 is the current major version, Drupal 12 is scheduled for the week of December 7, 2026, and Drupal 10 reaches end of life on December 9, 2026. Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Confirm your hosting stack and contributed module compatibility against the chosen version before the build starts, because a late version change can force rework.

What should we ask for in a fixed-scope quote?

Ask for a written scope that lists each site, locale, content type, rendering or component, media volume, integration and environment in the engagement. The quote should separate discovery, build, content migration, testing, cutover and post-launch support, and state what is excluded, such as personalization rebuilds or marketing automation. Ask which deliverables are documented, how acceptance is tested, what the change process is for scope additions, and what ongoing support or upgrade retainers cost. DeployOpen does not publish a price list, and a quote follows from the written scope.

Does DeployOpen issue compliance certifications for the new Drupal site?

No. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue audit reports, attestations and certifications. Ask for the documentation the migration produces, such as access controls, backup procedures and hosting configuration records, so your assessor can review them. Confirm early which frameworks apply to your sites, because data handling for forms, personalization data and user accounts will shape that evidence.

What you still run after cutover: hosting, upgrades and support

Drupal carries no license fee, but the estate you move into still needs an operator. The recurring work is Drupal core and contributed module updates. Bugfix releases ship on the first Wednesday of each month and security releases on the third Wednesday, so plan a standing patch window around those dates and assign an owner who watches the Drupal Security Team advisories. Each multi-site instance and each contributed module (for example, samlauth or the OpenID Connect client) adds to the update queue, so test them together in staging before production.

PHP planning is the upgrade risk most teams underestimate. The PHP version must match the Drupal major version you run: Drupal 10 requires PHP 8.1 or later, Drupal 11 requires PHP 8.3 or later and Drupal 12 requires PHP 8.5 or later. Confirm the Drupal 10 end-of-life date against the Drupal core release schedule before you commit to a major version, since Drupal 12 is scheduled for the week of December 7, 2026. Hosting runs on Apache or Nginx with MariaDB, MySQL, PostgreSQL or SQLite, and the database choice drives your backup tooling, so document the one you pick along with the web server, PHP-FPM settings and cron.

Backups and support are where costs recur. Back up the database and the sites/default/files directory together, and rehearse a restore on a separate host, because a database dump without its file store is not a working site. Support is a separate line item: whether you buy it from an agency, a host, a Drupal provider or your own platform team, ask each bidder for the scope covering patching, incident response hours, monitoring and restore testing. Marketing tools for personalization and automation are also separate costs, as the Sitecore migration does not carry them across.

How DeployOpen scopes and runs a Sitecore to Drupal migration

DeployOpen is a Chainscore Labs company that plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. For a Sitecore to Drupal move, we start with a written scope that maps your sites, languages, renderings and integrations before any build begins.

How we scope

Inventory every Sitecore site, language, template, rendering and integration that the Drupal estate must replace.
Record which xDB data, personalization rules and email content will be rebuilt rather than carried over.
Agree deliverables, timelines and acceptance criteria in writing before work starts, as engagements are fixed-scope.

How we build

Design the Drupal multi-site and multilingual structure, including content types, roles and shared components.
Rebuild Sitecore renderings as Drupal components and themes, then test them against the original page inventory.
Migrate content and media in staged batches, with reconciliation reports comparing source counts and target results.

How we hand over

Document the architecture, content model, migration decisions and any items that were rebuilt or retired.
Deliver tested backup and restore procedures for the database and file store on your infrastructure.
Walk your editors and administrators through the site, and provide runbooks for upgrades and incident response.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after handover, if your team wants it.
Plan Drupal core and contributed module upgrades around the published release schedule and security advisories.
Prepare systems, controls and evidence for your compliance assessments, while independent auditors issue any reports.

Migrate from Sitecore to Drupal