Moving from Drupal to SitecoreAI: a guide for Drupal 10 and 11 teams

1 November 2026
Andrew Hany

If your website runs on Drupal 10, there is a date to plan around. On 9 December 2026, Drupal 10 reaches end of life: security support ends and no new Drupal 10 releases will be made. For most sites the sensible answer is an upgrade to Drupal 11, and we say so below. Some organizations are using the deadline to ask a bigger question: is Drupal still the right platform for what the website now has to do?

We wrote this for digital and marketing leads in the Gulf and Egypt, many of them in government, universities and large companies, who are weighing SitecoreAI against another Drupal upgrade. It covers the dates, the realistic options, what moves when you change platform, and the Drupal details that make these projects bigger than they first look.

The dates

This is what the Drupal project has published, in order.

2 August 2024

Drupal 11.0 is released. It needs PHP 8.3, and six modules leave core for contributed projects: Actions UI, Activity Tracker, Book, Forum, Statistics and Tour.

17 December 2025

Drupal 10.6 ships. It is the last Drupal 10 minor release, with security support until December 2026.

28 January 2026

Drupal CMS 2.0 ships on Drupal 11.3, with the Drupal Canvas visual page builder and site templates.

9 December 2026

Drupal 10 reaches end of life, in the same week that Drupal 12.0 is due. No new Drupal 10 releases are made after this date.

Mid to late 2028

Support for Drupal 11 is planned to end, no earlier than the release of Drupal 13.

Nothing switches off on 9 December, and your site keeps serving pages. What changes is that no further Drupal 10 releases will be made, security fixes included. Acquia ends its own Drupal 10 support on the same date and says no long-term support option extends Drupal 10 past December. We know of no paid extended support either. For government entities, banks and universities, an unsupported platform tends to surface in the next security audit, and that usually sets the real deadline.

Three ways forward

Each of these is a project with code changes, testing and a release. They differ in how much changes, and in what you are committed to afterwards.

Option	What it takes	Makes sense if
Upgrade to Drupal 11	Get to Drupal 10.3 or later (sites on 10.6 must go to 11.3 or later), move to PHP 8.3, update contributed modules, fix deprecated code with Upgrade Status and Drupal Rector, and replace any of the six modules that left core. Acquia says a simple site can upgrade in hours once its modules are ready	Drupal does the job and your team or agency knows it well. For most Drupal 10 sites, this is the right move before December
Rebuild on Drupal CMS	A new site on Drupal CMS 2.0, which runs on Drupal 11 and adds the Drupal Canvas visual page builder and site templates. Content is moved across with Drupal’s Migrate API	Editors need to build pages visually and you want to stay on open source
Move to SitecoreAI	A platform change: a new content model, Next.js components, content migrated in batches, and forms, search and sign-in re-pointed	You run several sites or brands, marketing wants to build and personalize pages without waiting for developers, and you are ready to rebuild the front end

Staying on Drupal 10 after 9 December is the one option we would not sign off on. We would not tell most Drupal teams to switch either. If Drupal works for you and you have people who run it well, upgrade to Drupal 11 and stop there. SitecoreAI makes the most sense when the website is one of several channels a marketing team runs, when personalization and testing matter, and when Sitecore or Salesforce is already in the group. A comparison only means something when every option is priced against your own site, which is what the decision memo described below is for.

What happens to each part of a Drupal site

Almost everything in Drupal has an equivalent in SitecoreAI. The effort goes into deciding what is worth carrying over.

In Drupal	In SitecoreAI	The decision to make
Content types and their fields	Templates with fields, and pages built from Next.js components on the Sitecore Content SDK, edited in the page builder	Which content types you still need. Older sites often have several that do the same job
Paragraphs and Layout Builder sections	Components placed in placeholders, with datasource items holding their content	Which paragraph types become components, and which become plain fields on a page
Custom blocks and the block layout	Reusable datasource items and shared page parts such as headers and footers	Who owns them after the move
Taxonomy vocabularies and terms	Taxonomy items used for tagging, navigation and search facets	Which vocabularies still drive anything a visitor sees
Views	Listing components that query content through Experience Edge, or Sitecore Search	Which listings visitors actually use, and with which filters
Media items and files under `/sites/default/files/`	The SitecoreAI media library, SitecoreAI DAM, or your current DAM connected to SitecoreAI	Whether to move the files or connect a DAM. Our guide to choosing a DAM covers the checks
Content, configuration and interface translations	Language versions of the same item, plus dictionary items for interface text	How Arabic gets written, approved and published
Webforms and their stored submissions	SitecoreAI Forms, which send each submission to a webhook for your CRM	Where each submission should land, for example Salesforce, and what happens to the ones already stored
Content moderation workflows	SitecoreAI workflows	Who signs off, in which language, and how quickly
Logged-in areas for visitors	An identity provider and a portal or CRM, with the website showing content by signed-in state	Whether those accounts move at all, and where to
Custom modules, hooks and cron jobs	Webhooks, front-end services and integration services around the SaaS platform	Which custom PHP you still need
Path aliases, Pathauto patterns and redirects	Sites in SitecoreAI and a Next.js front end behind a CDN, with redirects managed in the platform	The redirect map, line by line
Search API and Solr	Sitecore Search, or a search service you already run	The queries, facets and synonyms people actually use, in both languages

Six details that make Drupal migrations bigger than they look

A crawl of the live site sees pages. It cannot see how they are built, and that is where Drupal estimates usually go wrong. Check these six before anyone quotes you a number.

Media and links stored by ID

When an editor embeds an image or a document in a text field, CKEditor 5 saves a <drupal-media> tag that points to the media item by its UUID. The Embed media filter builds the real markup only when the page is displayed. Sites that use the Linkit module save internal links with data-entity-type and data-entity-uuid attributes in the same way. Export the raw field and those embeds and links point at IDs that will not exist on the new platform. Each one has to be resolved and rewritten during the migration, or the new site goes live with missing images and quiet 404s.

Text formats

Drupal stores text exactly as the editor entered it. The text format’s filters, such as media embeds, automatic links, allowed tags and any custom filters your developers added, run each time the page is displayed and never change the stored copy. Decide early if you will migrate the stored HTML and rebuild those filters, or capture each field as visitors see it.

Paragraphs inside paragraphs

The Paragraphs module lets a page hold paragraphs that hold more paragraphs, each one a separate Drupal entity. After a few years of editors building pages, three levels are common. Decide where to flatten them before you map a single item, because every extra level adds component work.

Layout Builder overrides

If Layout Builder allows per-page overrides, any page an editor customized keeps its own layout, and changes to the default layout no longer reach it. Drupal stores that layout as serialized PHP data in a field on the page, every revision keeps its own copy, and the field is not translatable, so the Arabic and English versions share one layout. A site can look like it has five templates and actually have hundreds of one-off layouts. Count the overridden pages in the database before you estimate.

Views

News archives, event listings, staff directories and search pages are usually Views, set up in the admin screens with exposed filters, contextual filters and sorting. Each View is stored as configuration, so a content export leaves it out. They look like simple lists and carry real query logic. Export the list of Views with their displays, check which ones visitors still use, and rebuild only those.

Translations outside the content

Drupal core translates content, configuration and interface text with three separate modules. Views, menus, block titles, field labels and the site name are configuration. Buttons and messages are interface strings. A content export misses both, and on Arabic sites they are often half done because nobody owned them. List them separately and decide who writes the Arabic.

How we run the move

We use the same method and toolkit as ArcShift™, our SitecoreAI migration accelerator. There are five stages.

1. Scan the site and decide

We take the inventory from Drupal itself. That covers every content type and paragraph type with its count, how deep paragraphs nest, how many pages override their layout, and every View, webform, contributed and custom module, language and redirect. From that we write a decision memo that prices every option, upgrading to Drupal 11 included. It also shows how many content types you could retire, which Views still get traffic, and how far your Arabic content has drifted from the English.

2. Extract and map the content

Content comes out through Drupal’s JSON:API module, a stable part of core since Drupal 8.7, or from a database export. The JSON:API documentation calls its translation support basic, so on a bilingual site we script the language pairs directly. Content is mapped to SitecoreAI templates and imported in batches, each Arabic page with its English pair, and embedded media and links are rewritten on the way. Sitecore’s own migration tool, SitecoreAI Pathway, has an “Any website” option that crawls up to 200 URLs of a public site and, since version 1.4, brings the images too. That suits a small campaign or department site. A full Drupal estate needs scripted extraction so that paragraphs, taxonomy and language pairs come through intact.

3. Rebuild the front end

Twig templates become Next.js components, built from a bilingual component library on an Arabic-first starter, so right-to-left layout, Arabic typography and hreflang work from the first sprint. Your design tokens come across as they are, so the site still looks like your brand.

4. Rebuild forms, search and integrations

Webforms are rebuilt and pointed at your CRM, and the stored submissions you must keep are exported with an agreed retention period. Search is rebuilt and tested in Arabic and English with real queries from your logs. We record an analytics baseline before launch, since your history stays in the old tool, then re-point the CRM, DAM, sign-in and anything that ran as a cron job.

5. Go live

Drupal URLs come in several forms: path aliases, the /node/123 system paths behind them, language prefixes such as /ar/, and files under /sites/default/files/. Each one gets a redirect, and a script checks the whole map before launch. SitecoreAI’s redirect maps do not cover media URLs by default, and Sitecore recommends keeping each map to 200 redirects. The long tail of old file and node paths usually sits at the CDN or in the front end. Visual, accessibility and performance tests run in both languages. After launch we watch traffic, rankings and conversions daily until they settle.

Arabic

Drupal handles right-to-left well, and many sites in the region translate field by field. The trouble usually sits around the edges: configuration and interface text translated halfway, fields left untranslatable so English shows on Arabic pages, and Arabic URL aliases with no redirect plan. A migration is the cheapest moment to put that right. In SitecoreAI, Arabic is a language version of the same item, components are built and tested in both directions once, and brand kits carry a glossary so translations keep your names and terms. Before launch, have a native editor read your most visited pages and try site search in Arabic. Our guide to Arabic-first Sitecore has the full checklist.

Comparing cost

Drupal has no licence fee, so a fair comparison looks at everything else over three years: hosting and support, security patching, the migration itself, the changes your marketing team waits on developers for, and the next major upgrade. Drupal ships a new major version every two years. Drupal 12, due in December, needs PHP 8.5, and support for Drupal 11 is planned to end in mid to late 2028, so a site that upgrades now should budget for the next move as well. Put the same lines in your spreadsheet for each option.

SitecoreAI is a subscription, and Sitecore keeps the platform itself up to date. The front end runs on a hosting service you choose. A Forrester Total Economic Impact™ study commissioned by Sitecore reports a 371% three-year return for a composite organization, with page creation time down 60% and developer time on integrations down 50%. Vendor studies are a useful sanity check. Your memo should run on your own numbers.

Questions we get asked

Do we have to leave Drupal before 9 December?

No. If you are staying on Drupal, upgrade to Drupal 11 before then. If you are leaving, plan how the old site stays patched until the new one goes live.

Is there extended support for Drupal 10?

Not that we know of. Acquia says there is no long-term support option that extends Drupal 10 past December 2026, and the two certified vendors of extended support for Drupal 7, HeroDevs and Tag1 Consulting, have announced nothing for Drupal 10.

Should we upgrade to Drupal 11 before we migrate?

If the move to SitecoreAI will be live before your security team objects to Drupal 10, extract from Drupal 10 as it is. If it will run well past 9 December, the upgrade often costs less than months on an unsupported core, and a Drupal 11 site exports the same way. The decision memo puts both costs side by side.

Can SitecoreAI Pathway migrate a Drupal site?

For a small site, yes. Its “Any website” option crawls up to 200 URLs and, since version 1.4, imports the images. A full Drupal estate needs scripted extraction through JSON:API or a database export, otherwise paragraphs, taxonomy and language pairs get lost.

How long does a move from Drupal to SitecoreAI take?

It depends on the number of content and paragraph types, Views, languages, integrations and logged-in areas, so the decision memo gives a dated plan for your site.

What happens to our webform submissions?

They stay on the old site until you export them, and they often hold personal data. Agree what must be kept and for how long, export it with Webform’s submission export before the old site is switched off, and point the new forms at your CRM. SitecoreAI Forms sends each submission to a webhook that you configure.

Our site has logged-in members. Can SitecoreAI handle them?

SitecoreAI manages content and pages. Member accounts, profiles and permissions belong in an identity provider and a CRM or portal, and the website shows content according to who is signed in. On government sites that often means UAE PASS or Nafath. Settle this first, because it shapes the whole architecture.

Will we lose search rankings?

Not if every old URL redirects to its new home, system paths, files and language prefixes included, metadata and structured data come across, and Arabic and English keep their hreflang pairs. We check the redirect map by script before launch and watch Search Console closely afterwards.

Is SitecoreAI right for every Drupal site?

No. For a single site that Drupal serves well, an upgrade to Drupal 11 is cheaper and quicker. The memo makes the case for each option, staying on Drupal included.

On Drupal 10?

We will scan your site and give you a written comparison of the options, upgrading to Drupal 11 included, with your own costs and dates.

Talk to our Sitecore team →or see ArcShift™

Sources

Andrew Hany

Andrew builds Sitecore estates and moves them to SitecoreAI, from headless front ends to integrations.