Drupal 12 has confirmed it will ship without three components that many sites have quietly relied on for years: the Search module, the Claro admin theme, and the Olivero front-end theme. These are not deprecated in the sense of "we're warning you now but nothing breaks yet." Once a site crosses the Drupal 12 upgrade boundary, core stops supplying them entirely. For agencies managing a portfolio of Drupal sites, this is the kind of change that needs to be on a planning spreadsheet today, not discovered during an upgrade sprint next year.
What's actually being removed
Starting with Drupal 12, the following will no longer ship as part of core:
- Search module - the built-in node and user search that ships enabled on most default Drupal installs. Any site using Drupal's core search pages, search blocks, or the default search bar will lose that functionality unless a replacement is in place before upgrading.
- Claro - the polished admin theme that became the Drupal admin default in Drupal 9.1. Sites where editors and administrators work in Claro every day will revert to an unstyled or broken admin experience if nothing replaces it.
- Olivero - the default front-end theme introduced in Drupal 9.4. Sites running Olivero as their production theme, or as a base theme for a custom sub-theme, will need a migration path.
The rationale from the core team is sound: decoupling these from core allows them to evolve independently on their own release schedules and reduces the maintenance surface that every core contributor has to carry forward. That is a reasonable trade from a project governance standpoint. From an agency standpoint, it means the upgrade cost goes up for a meaningful slice of sites we manage.
Why this matters more than a typical deprecation
Most Drupal deprecation notices give you 1-2 major versions of runway before anything actually stops working. This is different: Drupal 12 is a hard cutoff. The components will be available as contributed modules or standalone projects, but they will not install automatically. If your upgrade runbook does not include a dependency check for these three components, you will have broken admin interfaces and missing search functionality on a production site after the upgrade completes. That is the kind of incident that erodes client trust quickly.
The Search module removal is the one that will catch the most sites off guard. Claro and Olivero are visible enough that most experienced Drupal developers will remember to check them. But Search often gets enabled during initial site setup and then never thought about again, especially on sites that do not use a search-heavy content model. We have audited a handful of client sites in the last week and found Search enabled and actively used on two of them where the primary point of contact had no idea it was a core dependency.
Our take
We want to be direct about the trade-offs here, because the upgrade path is not equally straightforward for every site.
For sites using core Search, the replacement decision is not trivial. The two realistic options are Search API with a backend (database, Solr, Elasticsearch, or a hosted service like Typesense) or a third-party site search product. Search API plus a database backend is the closest functional equivalent for low-to-medium traffic sites. Solr or Elasticsearch are better for large content volumes or faceted search requirements, but they add infrastructure cost and complexity. Hosted search products like Algolia or Typesense Cloud are increasingly attractive for editorial teams that want relevance tuning without managing server infrastructure, but they add monthly cost and a data pipeline. None of these is a drop-in swap. Budget a minimum of 8-20 hours per site depending on existing search customization.
For sites using Claro as the admin theme, the continued Claro contributed project is the obvious path. The core team has confirmed the module will be maintained as a contributed project. The migration is largely mechanical: add it as a dependency, update any admin theme config that references core, and test the editor workflows. For most sites this is a 2-4 hour task during an upgrade engagement. The real risk is sites that have custom admin CSS or JavaScript that overrides Claro styles by relying on its presence in the core path. Audit for hardcoded core paths before the upgrade.
For sites using Olivero as a production theme, you likely already have a longer conversation to have. Olivero was never designed to be a production theme for custom-branded sites; it was a demonstration of Drupal's front-end capabilities. If a client is genuinely running Olivero in production without a sub-theme or significant customization, a Drupal 12 upgrade is a good forcing function to have the "your site's design needs attention" conversation. The contributed Olivero project will exist, but maintaining a dependency on it long-term is not a strategy we would recommend.
The timing question: how urgent is this? Drupal 12 does not have a firm release date in the current public roadmap, but the Drupal 11 end-of-life timeline means most production sites will need to cross to Drupal 12 within a 24-36 month window from now. That sounds comfortable until you account for project queue time, client budget cycles, and the fact that auditing and migrating three separate components per site across a multi-site portfolio adds up fast. The sites we would flag for immediate attention are those using all three: core Search, Claro, and Olivero. Those are the sites where the Drupal 12 upgrade scope is meaningfully larger than a standard version bump.
What to do right now
- Audit your Drupal site portfolio for active use of the Search module, Claro, and Olivero. A quick
drush pm:list --status=enabledpiped through grep on each site will surface Search. Admin theme and default theme settings are in configuration. - Flag Claro and Olivero replacements as low-effort line items in your next maintenance engagement. Getting these off core-supplied paths now costs less than doing it under deadline pressure during an upgrade.
- Scope Search replacements as a distinct project conversation for any site where core Search is actively used. This is not a "do it in the background" task; it needs editorial testing and potentially infrastructure changes.
- Update your internal upgrade estimating template to include a Drupal 12 dependency check step that explicitly covers these three components. Every Drupal 12 upgrade estimate should carry a line item for this audit, even if it comes back clean.
Originally referenced: Drupal 12 Will Remove Search, Claro and Olivero from Core on The Drop Times.
If you are managing Drupal sites and want help running this audit across your portfolio, or you need a realistic estimate for what your Drupal 12 upgrade path looks like with these removals factored in, get in touch.
