Drupal 10 end of life: how to migrate while delivering business value

This article describes what will change after Drupal 10 EOL, how to determine the scope of steps for your company, and what the most effective Drupal migration paths are for businesses.

Nov 3rd 9 min read

Drupal 10 end of life: how to migrate while delivering business value

Introduction

The popular phrase “Winter is coming” has special meaning for the Drupal community this year — on December 9, 2026, support for Drupal 10 will end. If your company runs on Drupal 10 today, you’re probably already thinking about next steps.

At first glance, the solution seems simple — upgrade to the next supported version of Drupal. For a well-managed website, this is indeed a reasonable approach, but there’s an important caveat. Over several years, a website often takes on a life of its own — custom code, outdated integrations, non-standard processes, temporary solutions, and modules that are no longer properly maintained. Meanwhile, the business also changes — for example, some features become unnecessary, while others require recalibration because they were implemented inconsistently. In such cases, upgrading to the next supported version of Drupal can cost a pretty penny, as technical work takes precedence over strategic work.

In this article, we’ll explain what will change after Drupal 10 end of life (EOL), how to determine the scope of steps for your company, and what the most effective Drupal migration paths are for businesses.

How does Drupal 10 end of life impact your business?

Some people think the impact of EOL will show up literally the day after support ends. No, your website will continue to function as before, but it will gradually become increasingly difficult to function properly in the modern IT environment, as problems and risks accumulate. And the number of specialists willing to work with the old version for the long term will dwindle.

Drupal 9 has already reached EOL, and it’s clear that companies still using it are beyond its official lifecycle. Companies using Drupal 10 still have a few months to prepare. Those already running Drupal 11 are in a much better position: the recommendation is simply to keep moving in small steps and stay on the latest release. Sites that are currently on 11.x face a routine update rather than a migration project when Drupal 12 arrives.

In July 2026, Drupal updated its core release schedule.

The week of June 29, 2026 — Drupal 11.4.0 was released, and security support ended for the Drupal 11.2.x and 10.5.x branches.

The week of December 7, 2026 — the final versions of Drupal 12 and Drupal 11.5 are expected. At the same time, security support will end for Drupal 11.3 and Drupal 10.6.

The week of December 9, 2026 — Drupal 10 will reach end of life.

If your Drupal site has a lot of custom code and non-standard solutions, upgrading can be more difficult and expensive. The same applies to companies with multiple websites on a shared Drupal platform: changes need to be coordinated across all websites.

A separate issue is technical debt accumulated from previous migrations and customizations. It will resurface during the next upgrade and increase the workload.

And for companies in regulated industries, outdated Drupal can also create compliance risks, such as issues during audits.

What steps should a company take to determine the scope of the process?

A successful website migration from one Drupal version to another is always preceded by analysis. This is necessary to select the right strategy based on past experience and current givens.

Assess whether your site reflects your positioning

Don’t automatically migrate your site to the new version of Drupal, but open its homepage and try to understand the impression it creates about the brand. A lot can change for a company in just a few years — its clients, products, markets, and positioning. But a website isn’t redesigned from scratch each time, it gradually begins to reflect the company’s past, not its current state.

Make sure you don’t need to reset architecture

The business grows as new countries, brands, mobile apps, partner systems, and channels emerge. But the architecture remains the same, and it must constantly be “stretched” to accommodate new tasks for which it was not originally designed. The problem often appears as a multitude of small inconveniences that accumulate over the years, ultimately making the platform expensive to maintain and difficult to evolve.

Get honest feedback on the website from the team

Before migrating, it’s important to understand not only the website itself but also how convenient it is for the company to use it today. A business almost certainly has processes that waste time every day: an editor struggles to update content, or a marketer has to go through too many steps for a simple task. Answering the question, “What would you change about the current system if nothing were stopping you?” helps you identify pains that have become habits, even though they’re actually slowing your team down, and avoid migrating them to the new version of Drupal.

Benefits of migration

Migrating from Drupal 10 to a supported version isn’t just a way to meet the EOL deadline. For businesses, it’s also an opportunity to mitigate risks and update the platform’s underlying technology.

Protection from new cyberattacks

After support ends, Drupal 10 will no longer receive official security updates. New vulnerabilities continue to be patched on the supported version, significantly reducing the risk of exploiting known issues.

A more modern technology stack

New versions of Drupal work with the latest versions of PHP, databases, JavaScript, and infrastructure components. This simplifies integration, support, and further development of the platform.

Reduced technical debt

Migration is a good opportunity to remove deprecated code, replace outdated modules, and review accumulated custom solutions.

Easier maintenance and future updates

The longer a site remains on a supported version, the easier it is to perform future updates without a large and expensive migration project.

Higher reliability and performance

New core versions include improvements that help make the platform more stable, faster, and easier to maintain.

A stronger compliance position

For enterprises and regulated industries, it’s important to use software that is officially supported and receives security fixes. This reduces risks during audits and internal reviews.

Upgrade or rebuild — which to choose?

Before Drupal migration, you need to understand the current state of your website and how it meets your organization’s current needs. There are usually two options — either upgrade the existing website to Drupal 11 or 12, or rebuild the site using Drupal, revising its architecture, structure, and design.

Upgrade in place

The existing website remains the same — its content, structure, design, core functionality, and architecture are preserved, while the Drupal version underneath is updated. This option is suitable if no serious issues are identified during the strategic analysis.

The site is doing what the organization needs, the architecture still works well, the developers aren’t constantly having to work around a messy implementation, and the plans for the next few years can be delivered on the existing platform. In other words, EOL forces an upgrade, but it's not a reason to rebuild the whole site.

An upgrade is not a cleanup. Whatever technical debt your site carries on Drupal 10 will still be there on Drupal 11, just running on a newer core. Moving from Drupal 10 to 11 makes the most sense for relatively healthy sites that the organization has already invested in fairly recently.

Keep what works, rebuild what doesn’t

Drupal stays as the platform, but the site itself gets substantially rebuilt. This approach makes sense when the analysis shows a real misalignment between how the site is currently set up and what the organization actually needs today. And the problem doesn’t necessarily have to be Drupal itself. Drupal may still be the right platform, but the way the site was built may have become outdated over time and started getting in the team’s way rather than helping them.

Developers end up having to rely on workarounds all the time just to make the old architecture do what the business needs today. Once the cost of constantly working around the old site becomes higher than the cost of rebuilding it, there’s a real business and strategic case for a rebuild.

With this kind of rebuild, you don’t have to throw everything away. You keep what already works well in Drupal — its flexibility, security model, content modeling capabilities, and the wider ecosystem — and rebuild the parts that have become outdated.

You can also take a step back and look at what role Drupal should actually play in the overall architecture. If the organization needs to deliver the same content to multiple frontends — for example, a website, a mobile app, and other digital interfaces — it may make sense to consider headless Drupal and decoupled approaches or another tech solution that fits your specific needs.

Pre-migration checklist

Audit your custom code for outdated or deprecated parts. Everything the team wrote over the years needs a review against what the new core version still supports.
Verify every contributed module. Confirm each one has a stable release for the new core version moving to.
Check server-side requirements with your hosting team. Each Drupal major version raises PHP and database versions.
Review the front-end separately. Custom themes and JavaScript don’t fully cover automatic code audit tools, and they usually rely on parts of the core that can be changed between major versions.
Treat testing as a phase, not a final step. Plan for a separate environment with real content, and reserve a few weeks in the migration schedule to actually work in it and test everything.
Plan against the deadline from day one. Drupal 10 reaches end of life on 9 December 2026. Work planned in advance gets done properly, work compressed into the final weeks gets done in a hurry where the expensive mistakes happen.

How can Attico help turn Drupal EOL into business value?

A Drupal EOL deadline is what gets the project started, but the decision about what to do next is really a business decision. Before committing to an upgrade, a rebuild, or a bigger architectural change, it’s worth taking a step back and looking at where your current platform is today, what it’s costing you to maintain, and what you’ll need from it over the next few years.

To make that decision with confidence, Attico combines migration expertise with Drupal strategy and consulting to help you understand your current platform, identify the areas that need attention, and choose the right path forward. The goal isn’t just to meet the EOL deadline. It’s to make sure the decision you make today still makes sense for the business a few years from now.

We help enterprise teams move to a supported version of Drupal with a clear plan, predictable delivery, and as little disruption to day-to-day operations as possible. Our Shift-Left approach means we look at architecture, security, integrations, and quality early in the process, rather than discovering problems late in the project. We also combine automated and manual testing to catch issues early and avoid unnecessary rework.

The end result is more than just an upgraded Drupal version. You get a secure, maintainable, and scalable platform that’s ready to support the business well beyond the migration itself.