Which removed core modules affect your Drupal upgrade and what to do first
Book, Actions UI and Activity Tracker are already out of Drupal core in Drupal 11.0, so a Drupal 10 site that uses them needs a contributed project or a replacement before it moves to Drupal 11. Ban is removed in Drupal 12.0, and Olivero and Claro are deprecated in Drupal 11.5.0 and removed in Drupal 12.0.0. Any site that still depends on these extensions has to decide what replaces them, and the supported path to Drupal 12 runs through Drupal 11. Drupal.org's deprecated and obsolete extensions page lists the status of each extension and is the first reference to check against your own site.
Start the audit now rather than at cutover. Export the list of enabled modules and the active theme from each environment, then compare that list with the removal dates above. Pay particular attention to the Book outline and its content types, any Actions configured for workflows or mail, Activity Tracker reports used by editors, Ban rules that block IP addresses or user agents, and any custom theme that extends Olivero or Claro through its base theme or library. Each one needs an owner, a named replacement or contributed project, and a test on a staging copy of the site. If a contributed project for a removed module is not yet compatible with your target core version, record that as a blocker rather than assuming it will be resolved later.
Confirm the contributed version and its supported core range on Drupal.org before you commit to a replacement, and confirm the target versions against the Drupal core release schedule for your planning window. Keep the change to removed extensions in its own branch so content, configuration and theme changes can be reviewed and rolled back separately. Where a site relies on Olivero or Claro, decide early whether the theme work moves to a maintained base theme or a rebuilt custom theme, because that decision drives most of the front-end effort.
What changed for each removed module and theme
This table compares each removed or deprecated extension by what changed, what breaks on your site and what to confirm before upgrading. Read it against your own inventory of enabled modules and default theme assignments, because the impact depends on what content and configuration relies on each one. Book, Actions UI and Activity Tracker are already gone in Drupal 11, while Ban and the two themes follow in Drupal 12.
| Change | Impact | Action needed |
|---|---|---|
| Book, Actions UI and Activity Tracker removed in Drupal 11.0 | Book outlines, saved action configuration and recorded activity data stop working unless the contributed projects are installed. Pages may remain in the database but lose their book navigation and admin screens. | Confirm on the Drupal.org deprecated and obsolete page which contributed project replaces each module, then check that project's Drupal 11 compatibility before planning the move. |
| Ban removed in Drupal 12.0 | IP ban rules and the ban admin screen stop being available on Drupal 12. Sites relying on banned address lists for access control need another mechanism. | Confirm the Drupal.org deprecated page entry for Ban, list every ban rule in use, and decide with your security team how those blocks will be enforced before the Drupal 12 upgrade. |
| Olivero deprecated in Drupal 11.5.0, removed in Drupal 12.0.0 | Sites using Olivero as the front-end theme or as a base theme will lose it on Drupal 12. Custom subthemes that inherit from it will break, and block placements tied to its regions may need remapping. | Identify every site, subtheme and block placement that uses Olivero, confirm the removal entry on the Drupal.org page, and plan a replacement theme or a rebuilt subtheme. |
| Claro deprecated in Drupal 11.5.0, removed in Drupal 12.0.0 | Administrative pages styled by Claro will lose their theme on Drupal 12. Custom admin themes or overrides based on Claro need rework, and editors may notice layout changes. | Confirm the Drupal.org removal entry, identify the admin theme setting and any subthemes, then test editorial screens on a staging copy of the Drupal 12 target. |
| Deprecation status checked during Drupal 11 work | Extensions marked deprecated in Drupal 11.5.0 still run, but they signal the removal window. Teams that wait can face several removals at once. | Schedule a review of the deprecated and obsolete page for each Drupal minor release and record the decision for every extension in use. |
Keep, replace or drop: choosing a path for each removed extension
Keeping the feature means installing the project that Drupal.org now hosts for it. Book, Actions UI and Activity Tracker left Drupal 11.0 and are available as contributed projects, so the site keeps its existing configuration and content with the least editorial change. The trade-off is ownership: a contributed project is maintained by its own community, so you carry the risk that its release lags the core version you move to.
- Maintenance ownership: you track the project's releases and security advisories, and you decide when to take each update.
- Target compatibility: confirm that a release supports your target core version before you commit, since support for the new major version can arrive later than core.
- Editorial change: editors usually see the same screens, so retraining and content review stay small.
- Testing scope: test the feature's content paths, permissions and any custom code that calls its APIs, not just whether the module installs.
- Questions for maintainers: which Drupal versions the next release targets, how security reports are handled, and whether the project has an active maintainer team.
Before you choose this path, check the project page on Drupal.org for a release that supports your target version and review its open issues for compatibility blockers.
Replacement means moving the feature's job to a different module, a recipe or a configuration pattern, such as a views-based listing in place of a book outline, or a workflow or moderation tool in place of an action log. This path suits features where the business need is clear but the original module is no longer a good fit. Cost comes from migrating data, rebuilding screens and retraining editors, which usually outweighs the cost of keeping a module.
- Maintenance ownership: the replacement may be contributed or custom, so the owner of its future fixes must be named before you start.
- Target compatibility: verify that the replacement supports the target core version and the other modules you depend on.
- Editorial change: plan for new editor workflows, updated help text and a short adoption period where both old and new patterns coexist.
- Testing scope: test data migration, URL and access behavior, search indexing and any reports that depended on the old feature.
- Questions for the vendor or project: how the replacement handles existing content, what it logs, and how it behaves on the target core version.
Write down what the old feature did for users and auditors, then confirm each duty is covered by the replacement before you remove the original.
Removing the feature is the right choice when the business no longer uses it and no regulation, audit or workflow depends on it. Dropping a feature shrinks the codebase, reduces the number of projects you must patch and simplifies the upgrade. Ban, scheduled for removal from Drupal 12.0, is a typical example: if your site blocks users through another control, the module can be retired. Removal still needs evidence, because hidden dependencies often surface after go-live.
- Maintenance ownership: removal ends maintenance for that feature, but you must still remove its configuration, permissions and content references cleanly.
- Target compatibility: confirm that no other module, view or custom code depends on the removed feature before uninstalling it.
- Editorial change: tell editors which pages, menus or workflows disappear and provide a way to find archived content.
- Testing scope: test navigation, redirects, access rules and any scheduled jobs or reports that referenced the feature.
- Questions for stakeholders: who relies on the feature, whether records must be kept for audit, and whether any integration calls it.
Search your custom code and configuration for the feature's module name and any permissions it provides, then record the decision and its owner before you remove anything.
The choice between these paths depends on two inputs: how much the business uses the feature, and whether a contributed release supports your target Drupal version. Heavy use with a supported contributed release favors keeping the feature. Light use with no supported release favors replacement or removal. Teams often combine paths, keeping one module, replacing another and dropping a third, so the decision should be recorded per extension rather than once for the whole site.
- Usage evidence: count pages, editors and integrations that touch each feature, using logs, analytics and interviews.
- Support evidence: check each project's release history against the target core version and the date your upgrade completes.
- Risk evidence: note any compliance, audit or records obligation that requires the feature's data to remain available.
- Cost comparison: compare the ongoing maintenance of a kept module with a one-time migration and training cost for a replacement.
- Decision record: store the outcome, the owner and the review date for each extension in your upgrade backlog.
Before a quote is requested, ask any implementation partner to price each path separately so the trade-offs are visible.
What to inventory and back up before touching removed modules
Removed core modules leave behind configuration, content and code that still point at them. The cards below cover the records, dependencies and safety nets to build before any extension is disabled, replaced or upgraded, so the change can be reviewed and reversed if it goes wrong.
Extension and configuration inventory
List every enabled extension, including Book, Actions UI, Activity Tracker, Ban, Olivero and Claro, with its version and the configuration it owns. Use the site's extension list and configuration export to capture the exact state. This list is the baseline for deciding which items move to a contributed project, which get replaced and which get removed, and it shows which removals affect the Drupal 11 and Drupal 12 timelines.
Dependent content and configuration
Find the data that stores against each module. Book outlines, action configurations, activity records, IP ban lists and theme assignments in templates and blocks all reference these extensions. Export each dataset and note which content types, menus, views and blocks rely on it. Removing a module without this map can leave orphaned blocks, broken menus or lost access rules.
Custom code and theme calls
Search custom modules, themes and templates for calls to the removed APIs, theme hooks, libraries and Twig templates. Pay attention to Claro and Olivero overrides, which often sit in subthemes. Record each reference with the file path, because these calls decide whether the fix is a dependency change, a code rewrite or a theme rebuild.
Verified database and file backup
Take a full database dump and a copy of the files directory, including the configuration sync directory and custom code. Restore the backup to a separate host and confirm that the site loads and logs in before any change. An unrestored backup is not a recovery plan, so record who runs the restore and how long it took.
Production-based test environment
Build a staging site from a recent production copy with the same extensions enabled, the same PHP version and the same contributed modules. Run the planned changes there first. Test environments that skip the removed modules hide the errors that appear only when real content and configuration are present.
Decision record for each extension
Write one entry per extension stating whether it moves to a contributed project, gets replaced with another tool, or is removed, along with the owner, the reason and the rollback step. This record lets the upgrade be audited and explains later decisions to reviewers and security teams, so keep it under the same change control as the code.
How to move removed modules through the upgrade with rollback points
This sequence moves each removed module or theme to a tested path, one version at a time, with a verified backup or a tagged release to return to at every stage. The result is a Drupal 12 site where no removed extension is still a hidden dependency.
Audit enabled removed extensions
Run the Upgrade Status module on the current production clone and list every enabled extension that is removed or deprecated in the target versions: Book, Actions UI, Activity Tracker, Ban, Olivero and Claro. Also check the configuration for references to them, such as block placements, menu links, views, text formats and theme settings, because enabling a module is not the only way a site depends on it. The step is done when the team has a written inventory that lists each item, where it is used and which site owner signs off on it. Take a verified backup and tag the current release in version control before this step begins, so the inventory is taken from a known state.
Decide the path for each extension
For each item in the inventory, record one of three paths: move to the contributed project, replace with another module or design, or remove the feature and its content. Book and Activity Tracker and Actions UI have contributed versions that teams should confirm are compatible with their target core version before choosing them. Ban is removed in Drupal 12.0, so its decision can wait, but it still needs a documented owner. Olivero and Claro are deprecated in Drupal 11.5.0, so the decision here is which theme the site will use and whether custom theme code depends on either one. The step closes when each decision has a named owner, a reason and a rollback note.
Install and test replacements on the current version
On a staging copy of the current Drupal version, install each contributed module or replacement through Composer and test the features that depend on it. Check content that references removed features, such as book outlines, scheduled actions, user activity views and banned-user rules, and compare results against the baseline taken in the first step. Keep each change in a separate commit so any single replacement can be reverted without touching the others. The step is done when the test script passes on staging and the team has a list of known differences that the business has accepted. Roll back by reverting the commits and restoring the staging database from the pre-test backup.
Upgrade to Drupal 11 and confirm contributed replacements
Apply the core upgrade to Drupal 11 on a staging environment, along with the chosen contributed versions for Book, Actions UI and Activity Tracker. Run database updates, clear caches and repeat the test script from the previous step, checking the same book navigation, scheduled actions and activity views. Review the update logs and the site status report for errors before moving on. The step produces a signed-off staging result that shows each removed-in-11 feature working from its contributed project. If a check fails, restore the verified backup taken before the upgrade and return to the tagged release from step three.
Resolve Olivero and Claro dependencies while deprecated
While Olivero and Claro are deprecated on Drupal 11, move the site to the chosen theme and remove dependencies on the old one. Search custom themes and modules for template overrides, library references and theme-specific settings, and rebuild those parts in the new theme. Test administrative and front-end pages on desktop and mobile widths, with keyboard navigation and screen reader checks for the most important flows. The step is done when the deprecated theme is no longer used as the active theme and no code path in the site refers to it. Roll back by switching the theme setting back and restoring the pre-change theme files from version control.
Complete Drupal 12 steps for Ban and remaining theme changes
Before the Drupal 12 upgrade, remove any remaining use of the Ban module, moving blocked-address rules to a supported alternative confirmed for your hosting or contributed setup. Then remove the last references to Olivero and Claro, including in custom code and configuration, and confirm that the target PHP version of 8.5 runs the full test script. Run Upgrade Status against the target version again and resolve any reported items. The step closes when Upgrade Status reports no removed extensions and the test script passes on staging with the final code. Roll back to the verified backup from before the Drupal 12 change if any check fails, then retry from the tagged release.
Release with a documented rollback plan
Schedule the production change with the team and record the verified backup, the database snapshot and the version control tag that together form the rollback point. Deploy the tagged release, run database updates and repeat the smoke tests for each removed feature. Keep the previous release available until the business owners confirm the features work as expected. The step is done when the production checks pass and the owners sign off, and the rollback point is recorded in the change record. If the release fails, restore the verified backup and redeploy the previous tag.
Why Olivero and Claro need a decision before Drupal 12
Olivero and Claro need a decision now because they are deprecated in Drupal 11.5.0 and removed in Drupal 12.0.0. A site can keep running on them for the rest of the Drupal 11 minor series, but it cannot carry them into Drupal 12. The decision is not whether to change themes, but which replacement you adopt and when. Olivero is the default front-end theme and Claro is the default administration theme, so most sites will need to choose a successor for both, or for whichever one they actually use. Confirm with your team which theme editors see in the back end and which theme visitors see on the public site, because those answers set the size of the work.
There are three realistic paths and each has different consequences for editors and templates. The first is to adopt a replacement front-end or admin theme supplied by the Drupal community or your own team. The second is to build a custom theme that inherits from Olivero or Claro, which keeps the current markup and styles in place but ties your theme to a component you no longer receive updates for once it is removed. The third is to rebuild the presentation layer directly in a custom theme. Whichever path you choose, check how it affects content editors, who will see changes to the admin forms and listing pages, and how it affects Twig templates, block placements, region names and any preprocess functions your custom code depends on. Ask your developers to list every template override in your site before choosing.
Plan the theme work as a separate workstream from module work, because it is usually the larger task. Changing a theme touches markup, CSS, JavaScript and the ARIA and keyboard behavior that accessibility testing depends on, so each template must be re-tested after the change, not just visually inspected. Ask for an inventory of overridden templates, a short list of accessibility checks for editorial screens and public pages, and a staging environment where editors can review the new admin experience before go-live. Schedule the decision early in the Drupal 11 series so the replacement has time to be tested against your content and your contributed modules.
What makes removed-module work longer or shorter
This table lists the factors that change how much work removing or replacing Book, Actions UI, Activity Tracker, Ban, Olivero or Claro will take, and what each one does to the effort. Read it as a checklist for the quote: each row names a driver and the itemized detail to request. The main takeaway is that the count of removed extensions matters less than whether they hold live content, custom code and untested templates.
| Driver | Effect on the work | What to ask for in a quote |
|---|---|---|
| Number of removed extensions enabled | Each enabled extension needs a decision (contributed replacement, rebuild or retirement) and its own configuration check. Ban and Olivero or Claro carry different removal timing than Book, Actions UI and Activity Tracker. | An itemized list of every removed extension enabled on each site, with the chosen path for each |
| Live content or configuration tied to the module | Book outlines, action configuration and stored activity or ban data may need export, mapping or archiving before the module is removed. Sites with little of this data move faster. | A data inventory per extension and the approach for content, configuration and records that must be kept |
| Custom code or subthemes depending on Olivero or Claro | Hooks, preprocess functions, Twig overrides and libraries that reference these themes must be rewritten or moved. Subthemes built on them usually cost more than a plain theme switch. | A list of custom modules and themes that reference Olivero or Claro, with the work planned for each |
| Contributed release for the target core | If a maintained release supports the target Drupal version, the change is mostly configuration and testing. If none exists, a replacement or a maintained fork must be designed and owned. | Confirmation of the contributed project, its supported core versions and its maintenance status for the target release |
| Templates and blocks to change | Each Olivero or Claro template, region and block placement changed in the replacement theme adds build and review work. Heavy customization of these templates is the main driver of theme effort. | A count of templates, regions and block placements to change, and the review method for each |
| Scope of accessibility and visual regression testing | Replacing a theme or module changes markup, focus order and colors. Testing covers key journeys, automated accessibility checks and manual review on the sites in scope, so wider coverage adds time. | The test list, the tools used, the browsers and breakpoints covered, and who signs off the results |
| Number of environments to rebuild | Development, staging, and production copies each need the new module set, configuration import and content checks. Multisite estates multiply this work. | The environments and sites included, the rebuild order, and the refresh steps for each |
Questions teams ask about removed core modules and themes
What does it cost to deal with modules and themes removed from Drupal core?
The cost depends mostly on how much of your site relies on the removed pieces and how much of it you have to rebuild. Each removed module (Book, Actions UI, Activity Tracker, Ban) needs a decision: install the contributed version, replace it with another approach, or retire the feature. Olivero and Claro need a theme decision, and any custom theme built on them needs rework. Cost drivers include the number of affected pages and workflows, the size of custom code that depends on the removed APIs, testing effort across roles, and the editorial time needed to sign off. Ask any partner for a quote that lists each removed component separately with its decision and the testing it requires. No figures are given here because the effort varies by site.
How long does it take to replace removed modules before an upgrade?
Duration depends on the number of removed components in use, whether contributed replacements exist and are compatible with your target version, and how much custom code depends on them. Timing is set by two dates: Drupal 12 is scheduled for the week of December 7, 2026, according to the Drupal core release schedule, and Drupal 10 reaches end of life on December 9, 2026. Sites still on Drupal 10 must stop on Drupal 11 first, so the removal work should finish well before the Drupal 11 target date that your upgrade plan sets. Confirm your own timeline against the schedule and build in review and testing windows.
What does the work need from our team?
The work needs named decision owners who can approve each removal decision, such as a product owner for site features and a security or platform lead for access and authentication behavior. Editorial and content teams must sign off on how Book pages, activity views and other content presentations behave after the change. You also need access to development, staging and production environments, along with a current backup and a way to restore it. Agree on these owners and access points before work starts so that testing is not delayed.
Can our internal team handle removed core modules without a partner?
Yes, a team can do this alone if it has working Drupal experience, including module installation with Composer, configuration management and theme development. Check that your engineers have worked with contributed module release compatibility, can review deprecation reports, and can run regression testing across user roles. If any of these skills are thin, or the site has heavy custom theming on Olivero or Claro, a partner can fill the gap. Consider the time your team needs to keep the regular site running alongside the upgrade.
Does removing the Ban module affect our IP blocking?
Ban was removed in Drupal 12.0, so if your site relies on the Ban module to block IP addresses, that blocking needs a replacement before you move to Drupal 12. Confirm with your platform team whether blocking happens in Drupal or at the web server, load balancer, firewall or CDN, because a perimeter control may already cover the need. Check whether any Drupal rules, custom code or logs depend on the Ban tables. Test that blocked addresses are still refused after the change, and record the replacement in your change control documentation.
Can a Drupal 10 site skip straight to Drupal 12?
No. A Drupal 10 site must first upgrade to Drupal 11, which is the required stop, before it can move to Drupal 12. Removed modules such as Ban and the theme changes in Olivero and Claro need to be handled during that Drupal 11 stop, while the contributed module and PHP requirements are checked for each target. Plan the Drupal 11 step as a complete milestone with its own testing and sign-off.
How DeployOpen scopes and delivers removed-module work
DeployOpen is a Chainscore Labs company that plans, implements, customizes and supports self-hosted open-source platforms inside the client's own infrastructure. For removed core modules, we start by inventorying which of Book, Actions UI, Activity Tracker, Ban, Olivero and Claro your site depends on, then deliver the replacement work as a written, fixed-scope engagement.
How we scope
- Inventory every removed module, theme and dependent view, block, menu link and configuration object on your site.
- Record which features users rely on, which contributed projects or custom replacements will carry them, and who signs off each choice.
- Agree in writing which removed components are reinstated, replaced, or retired, with deliverables and timelines before work starts.
How we build
- Install contributed replacements for Book, Actions UI or Activity Tracker where a compatible release exists for your target Drupal version.
- Rebuild Olivero or Claro dependencies on a maintained theme, and move custom templates and libraries off deprecated theme APIs.
- Test each replacement on a staging copy with production-like content, permissions and cron behavior before any change reaches production.
How we hand over
- Deliver a written record of each removed component, its replacement, its version pin and the reason for the choice.
- Document the Composer changes, configuration exports and content checks so your team can repeat the steps on the next upgrade.
- Walk your developers and content owners through the changed features and the acceptance results before closing the engagement.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, so contributed replacements stay patched after launch.
- Track contributed replacement maintenance and Drupal security advisories against the pinned versions on your site.
- Ask any provider, including DeployOpen, to confirm in writing who maintains each replacement and what happens if it is abandoned.
