Is your Drupal platform ready for 2027?
Why 2027? The milestones to know
Drupal 10 will reach end of life on 9 December 2026. Drupal 12 is currently planned for the week of 7 December 2026, according to the official Drupal project schedule.
These milestones are useful for planning. On their own, they do not determine the right path for your site and do not justify a rushed migration.
Depending on the state of your platform, the next step may be an upgrade, progressive modernization, a more structured migration, or simply a few checks before deciding.
When might this apply to you?
A review can be useful if:
- you are on Drupal 7, 8, 9, 10 or 11 and the next path is unclear;
- you do not know the exact Drupal version or the dependencies actually in place;
- the site works, but changes are becoming harder to plan or validate;
- contributed modules, custom code or important integrations need to be preserved;
- a redesign, hosting change or modernization is being considered;
- you want to know what really needs to be checked before committing budget or starting a project.
None of these situations means that everything needs to be rebuilt. The goal is to avoid choosing a path based on assumptions.
What needs to be checked
A credible Drupal roadmap is not just about the CMS version number. The checks fall into four clear groups.
1. Technical foundation
- exact Drupal Core version;
- PHP and runtime environment;
- Composer dependencies;
- database and services required by the project.
2. Application and dependencies
- contributed modules and compatibility;
- custom developments;
- theme and front-end layer;
- integrations with external services or systems.
3. Usage, content and quality
- critical business workflows;
- data and content model;
- multilingual content;
- SEO and URLs;
- performance and accessibility where they affect user journeys.
4. Ability to change in a controlled way
- maintenance and security monitoring;
- backups and rollback capability;
- DEV / PREPROD / PROD environments;
- automated tests and human validation;
- deployment and post-production checks.
Why it is not just `composer update`
Composer manages the dependencies of a modern Drupal project. On its own, it cannot verify that custom development remains compatible, that a business integration still works, that the theme keeps behaving correctly or that a critical user journey has not regressed. The right goal is to distinguish what can be updated straightforwardly from what needs to be checked, adapted or tested.
Our method in four steps
1. UNDERSTAND
First diagnostic + context
Understand the situation, the objectives and what genuinely needs to be checked. A technical audit is proposed only if it provides a useful basis for decision-making.
2. PREPARE
Development + tests
Handle the necessary adaptations and verify the changes before presenting them as ready.
3. VALIDATE
PREPROD + human validation
Review the candidate in a validation environment, check the useful user journeys and make a human decision before production.
4. DEPLOY & MONITOR
Production deployment + monitoring
Deploy in a controlled way, then verify the real behavior after production release.
These four steps are a commercial presentation of capabilities that E-merging Digital actually uses in practice; they do not imply that every project requires the same level of process.
A free, human first diagnostic — not a migration decided in advance
- Free first diagnostic
- human review and low friction
- no automated scanner or exhaustive audit
- no repository or production access required by default
- paid audit only when useful, with no automatic migration
The first diagnostic is free, reviewed by a person and intentionally low-friction. The platform URL and a few contextual details are enough to get started; access to the repository or production is not required by default.
This first diagnostic is neither an automated scanner nor an exhaustive technical audit. Its purpose is to understand the situation, identify what genuinely needs to be checked and determine the next useful step.
The existing drupal_lifecycle_diagnostic Webform remains the only diagnostic surface. A paid technical audit is proposed only if a deeper analysis adds real decision-making value, and migration is never automatic.
When a technical audit is genuinely useful
A paid technical audit is only proposed when a deeper analysis provides a useful basis for decision-making. It is not systematic and may also conclude that no immediate migration is justified.
Depending on the context, it can cover Drupal Core and the environment, contributed modules, custom code, the theme, Composer, integrations, deprecations, tests, infrastructure and deployment.
The deliverable remains useful for understanding the findings, prioritizing checks and deciding what to do next, even if E-merging Digital does not subsequently carry out the modernization or migration.
The existing content from #958 about Drupal 10 end of life remains a relevant resource for further reading. It will be linked publicly from the URL actually confirmed during the future materialization/review, without inventing a route.
FAQ
I do not know my Drupal version. Is that a problem?
No. The URL and project context are enough to get started. The exact version is one of the elements to check.
Is the first diagnostic free?
Yes. It is a low-friction, human-reviewed first diagnostic intended to understand the situation and determine what genuinely needs to be checked. It does not replace an in-depth technical audit.
Is the diagnostic an automated scanner?
No. It is reviewed by a person and is not an exhaustive automated audit. Access to the repository or production is not required by default.
Do I need to move directly to Drupal 12?
Not necessarily. The right path depends on the starting version, dependencies, custom code and project schedule. The goal is to understand the existing platform before deciding.
Does an audit mean I have to migrate?
No. The audit is paid only when a deeper analysis is useful, and it may conclude that no immediate migration is justified.