Drupal 10 reaches end of life in December 2026: action plan

In December 2026, Drupal 10 will officially reach its end of life. As is often the case with these deadlines, some will have already taken the necessary measures, while others will find out when they have little time left to act.

In our experience, we have encountered cases of companies that didn't even know they were using that CMS system on their website, as they installed it many years ago and did not take care of updating it until a problem arose and they contacted a specialist, often different from the one who provided it. In other cases, those who are aware that their life cycle is coming to an end have not found that quiet moment amidst the daily fires to look for an alternative. In both cases, they are running unnecessary risks.

The specific date is December 9, according to the official Drupal calendar. The website will continue to function afterward, but Drupal 10 will stop receiving official support and new security updates. A problem discovered from then on may remain uncorrected for that version.

This does not mean that the end of support will suddenly cause bottlenecks or that the platform will cease to be compatible with its environment. It does require a decision on how you will maintain it from that moment on. And the longer you wait to review its status, the less time you will have to resolve any issues that arise.

The recognizable situation: what point is your organization at?

Technical and business teams can reach the end of life of Drupal from quite different situations:

• “We are running on Drupal 10, but we have old custom modules.” Everything works and we are afraid to touch it: maybe a change will break the connection with the ERP or the CRM. Custom modules may still be useful. What needs to be determined is whether they need changes to work in the next version.
• “We haven't completed the jump from Drupal 7 or 9 yet.” So official support has already ended. We need to study from that version what steps the update or migration requires. We cannot assume that the work is comparable to that of moving from Drupal 10 to 11.
• “We depend on a provider that does not propose a clear path.” We do not know how much it will cost or how long it will take. We also do not have technical documentation and feel trapped with that provider.
• “The person who installed Drupal for us no longer exists.” The provider contracted for the current system has ceased operations and we do not have effective control over its development.

To review those applications, we need to locate the code and gain access to prepare a working copy.

Diagnosis: before approving a budget

Let’s start with the basics. Before writing a single line of code or approving a budget, it is essential to evaluate the platform to choose the right strategy and make the first decision: is it enough to update, or is there something else we need to resolve?

The transition from Drupal 10 to Drupal 11 has a planned upgrade path. To know how much work it will take, we need to see what extensions your website uses and what has been custom programmed. Also, what versions of PHP and the database are installed. Without reviewing that, we would be budgeting with incomplete information.

1. We would start with the modules, both community and custom, the theme, and the patches. Which ones already work with Drupal 11? Which ones need to be adapted? Is there any that has stopped being maintained? Upgrade Status helps us find incompatibilities. After that, we will need to test the application and ensure it still communicates correctly with the other systems.
2. And here it is advisable to decide how far we want to go. If a module prevents updating and needs to be replaced, we will have to do it. Changing the design or reorganizing all the content is another decision. We may be interested in taking advantage of the project to do so, but we will need time to decide on those changes and test them. Before including them in the budget, we will need to assess whether it is worth doing them now.

Real learnings: the case of Labdoo.org

At Natiboo, we participated in the migration and modernization of the global platform of Labdoo.org.

• The initial request: to move from Drupal 7 to Drupal 10.
• The proposal after the analysis: rethink its architecture while preserving the accumulated knowledge about the organization’s operations.

The project ended up having a much broader scope than initially planned. We discuss it in the success case of Labdoo.

This example needs a nuance here: updating to Drupal 10 does not imply undertaking a transformation like that of Labdoo. The decision to rebuild a platform must be justified by its problems and needs. The version change alone is not a sufficient reason.

Drupal 2026 action plan: what should be resolved in each phase

Phase 1. Diagnosis

• First, we review the custom code, its dependencies, and the integrations. You need to know what prevents updating and what options we have to resolve it.
• With that, we can define the budget. If there is still something we do not know, it must be indicated in the estimate.

Phase 2. Preparation and testing

• We work on a representative copy of the application, in an isolated environment.
• We test that the order reaches the ERP, that the editor can publish a translation, and that each user retains the permissions that correspond to them.

If the project includes a data migration, there are other difficulties that should be reviewed. In our experience, a common source of problems is nested data, which require more complex extraction algorithms. Another is external resources: files or photographs that are not accessible at the time of synchronization. These are specific checks for a data migration; not all updates from Drupal 10 to 11 require that process.

Phase 3. Validation with platform users

In a Drupal migration, problems often arise from undeclared requirements that are not easily identifiable by reviewing the code. Those who use the application must test it and give their approval before publishing the changes.

Phase 4. Deployment and review

• Before publishing, we agree with those in charge of the deployment whether it is necessary to interrupt the service, what will happen to the data generated during the change, and how to roll back.
• Backups must be restorable. It must also be decided who validates the result and who reviews the website afterward.

The commitment of Natiboo: collaboration and documentation

We collaborate with your team or take charge if you do not have one. We document the changes, decisions, and what remains pending.

Does your platform depend on Drupal 10?

If you need help with the update, we can review your platform and provide a diagnosis to estimate the work.

Tell us what point your platform is at.