Your Drupal 10 site has 292 days to live.
That is not a guess. That is not a prediction. That is an official, published, immovable deadline: December 9, 2026.
After that date, your Drupal 10 installation will receive no security patches. No bug fixes. No updates of any kind. Every vulnerability discovered after that date becomes a vulnerability that stays open. Forever.
And if that sentence made you uncomfortable — good. Because I wrote this article for you.
I have been building enterprise Drupal sites for nine years. In that time, I have watched end-of-life deadlines approach with the quiet inevitability of a train. And every single time, I have seen organizations fall into the same trap: “We still have time.”
You do. But less than you think.
Let me show you exactly what is coming, exactly what you need to do, and exactly how to convince your leadership that this cannot wait until Q4.
The Timeline Nobody Is Talking About
Most developers know Drupal 10 is reaching end-of-life. What most do not realize is how the support cascade actually works.
Here is the reality:
| Version | Status | Security Support Until |
|---|---|---|
| Drupal 10.4.x | Unsupported | Already ended |
| Drupal 10.5.x | Security only | June 2026 |
| Drupal 10.6.x | Active support | December 9, 2026 |
| Drupal 11.2.x | Active | June 2026 |
| Drupal 11.3.x | Active | Until Drupal 12 release |
| Drupal 11.4.0 | Upcoming | Alpha in April, stable in June 2026 |
| Drupal 12.0.0 | Upcoming | Second half of 2026 |
Read that table again. If you are running Drupal 10.4 or earlier, you are already unsupported. If you are on 10.5, you have until June. Only 10.6 gives you the full runway to December.
And here is the part that catches organizations off guard: Drupal 12 is releasing the same month Drupal 10 dies. That is not a coincidence. It is how Drupal’s predictable release cycle works — when a new major version arrives, the oldest supported major version exits.
What “End of Life” Actually Means
Let me be precise about what happens on December 10, 2026:
- No security advisories for Drupal 10
- No security patches for vulnerabilities in core
- No bug fixes regardless of severity
- Contributed modules will progressively drop Drupal 10 support
- Hosting providers will begin flagging your installation as unsupported
- Compliance audits will identify your CMS as running on unmaintained software
If you work in healthcare, finance, government, or any regulated industry? An unsupported CMS is not just a risk. It is a compliance violation.
Why Most Teams Are Not Ready
I have seen this pattern repeat across every major version transition. The reasons teams fall behind are predictable:
1. The “We Have Time” Fallacy
292 days sounds like a lot. It is not.
Here is the math nobody does:
| Factor | Time Cost |
|---|---|
| Getting budget approval | 4-8 weeks |
| Auditing existing site | 1-2 weeks |
| Updating contributed modules | 2-4 weeks |
| Updating custom code | 2-8 weeks (depends on codebase) |
| Testing on staging | 2-4 weeks |
| Production deployment | 1 week |
| Buffer for unexpected issues | 2-4 weeks |
| Total realistic timeline | 14-31 weeks |
That is 3.5 to 8 months. For a site with significant custom code, you are looking at the full 8 months. Count backward from December 9, and you realize: the comfortable window to begin was January. The urgent window is right now. The panic window starts in April.
2. The Budget Conversation Nobody Wants To Have
Project managers know the migration is needed. Developers know it is needed. But the budget holder does not understand why “upgrading” something that currently works costs real money.
I will give you the script later in this article. Keep reading.
3. The Contrib Module Bottleneck
Your site does not just run on Drupal core. It runs on 30, 50, maybe 100 contributed modules. Every single one needs a Drupal 11-compatible version. Some already have them. Some do not. Some never will.
This is the variable that turns a two-month project into a six-month odyssey.
The Upgrade Path: Step by Step
Let me walk you through the exact process. This is not theoretical — this is the playbook I use with clients.
Phase 1: Assessment (Weeks 1-2)
Before writing a single line of code, you need to understand what you are working with.
Step 1: Update to Drupal 10.3+ minimum
Your site must be running at least Drupal 10.3.0 before you can upgrade to Drupal 11. Older core update paths have been removed. If you are on 10.2 or earlier, update core first.
composer update drupal/core-recommended drupal/core-composer-scaffold --with-all-dependencies
drush updatedb
drush cache:rebuildStep 2: Install the Upgrade Status module
This is your diagnostic tool. It scans your entire codebase and tells you exactly what is compatible, what is incompatible, and what needs attention.
composer require drupal/upgrade_status
drush en upgrade_statusNavigate to Admin, Reports, Upgrade Status. The report will categorize every module and theme as:
| Status | Meaning | Action |
|---|---|---|
| Compatible | Ready for Drupal 11 | No action needed |
| Incompatible | Uses deprecated APIs | Update or replace |
| Unknown | No compatibility data | Manual investigation |
| Custom | Your custom code | Audit required |
Step 3: Audit your custom code with Drupal Rector
Drupal Rector is an automated tool that identifies deprecated code and, in many cases, can automatically update it.
composer require --dev palantirnet/drupal-rector
vendor/bin/rector process web/modules/customThis step alone can save weeks of manual code review.
Phase 2: Preparation (Weeks 3-6)
Step 4: Update your infrastructure requirements
Drupal 11 has strict minimum requirements. Verify your hosting environment meets these:
| Requirement | Drupal 10 | Drupal 11 |
|---|---|---|
| PHP | 8.1+ | 8.3+ |
| MySQL | 5.7.8+ | 8.0+ |
| MariaDB | 10.3.7+ | 10.6+ |
| PostgreSQL | 12+ | 16+ |
| SQLite | 3.26+ | 3.45+ |
| Composer | 2.x | 2.7.7+ |
| Drush | 12 | 13 |
Talk to your hosting provider now. PHP 8.3 alone may require a hosting plan change. If you are on shared hosting that only supports PHP 8.1, this is a blocker that needs resolution before anything else.
Step 5: Update contributed modules
Go through your Upgrade Status report. For each incompatible module:
- Check drupal.org for a Drupal 11-compatible version
- If available, update via Composer
- If not available, check the issue queue for patches
- If no patch exists, evaluate alternatives
For modules in transition, you can use multi-version compatibility in Composer:
{
"require": {
"drupal/linkit": "^6.1 || ^7.0"
}
}This allows your codebase to work with both Drupal 10 and Drupal 11 versions during the transition.
Step 6: Address removed core modules
Several modules were removed from Drupal 11 core. If your site uses any of these, you need to install them as contributed modules:
| Removed Module | Replacement |
|---|---|
| Actions UI | Available as contrib |
| Activity Tracker | Available as contrib |
| Book | Available as contrib |
| Forum | Available as contrib |
| Statistics | Available as contrib |
| Tour | Available as contrib |
Check if your site uses these by reviewing your enabled modules. If they are active, install the contributed versions before upgrading core.
Phase 3: Execution (Weeks 7-10)
Step 7: Create a complete backup
This is not optional. Database, files, codebase — everything.
drush sql:dump --result-file=../backup-pre-d11.sql
tar -czf ../files-backup.tar.gz web/sites/default/files
cp -r . ../codebase-backupStep 8: Execute the core upgrade
composer require drupal/core-recommended:^11 drupal/core-composer-scaffold:^11 drupal/core-project-message:^11 --update-with-all-dependencies
drush updatedb
drush cache:rebuildStep 9: Run database updates and export configuration
drush updatedb
drush config:exportThe configuration export captures any schema changes introduced by Drupal 11.
Phase 4: Validation (Weeks 11-14)
Step 10: Test everything
Manual testing is not enough. Here is what a proper validation looks like:
| Test Type | What to Check |
|---|---|
| Smoke test | Can you log in? Do pages load? |
| Functional test | Content creation, editing, publishing workflows |
| Module test | Every contrib module works as expected |
| Custom code | All custom modules and themes function correctly |
| Integration test | Third-party APIs, payment gateways, search |
| Performance test | Page load times, resource usage |
| Responsive test | Mobile, tablet, desktop layouts |
| Accessibility test | Screen readers, keyboard navigation |
Never upgrade production first. The path is: local, staging, production. Three environments. Three rounds of testing.
The Key Technical Changes You Need to Know
Beyond the version numbers, Drupal 11 introduces fundamental platform changes:
Symfony 7
Drupal 11 runs on Symfony 7, replacing Symfony 6. If your custom modules use Symfony components (and most complex ones do), check for deprecations and API changes. The upgrade is generally smooth, but edge cases exist.
jQuery 4
The front-end framework updates to jQuery 4. If your custom themes use jQuery directly, test for compatibility. jQuery 4 removed several deprecated methods. The most common issues involve .andSelf() (replaced by .addBack()), event shorthand methods, and the removal of certain AJAX utilities.
PHPUnit 10
If your codebase includes automated tests (and it should), PHPUnit 10 introduces changes to annotations, data providers, and test configuration. Update your test suites as part of the migration.
How to Sell This to Leadership
Here is the conversation you need to have. I am giving you the exact framework because I know how hard this sell can be.
The Risk Framing
“After December 9, our website will no longer receive security patches from Drupal. Every vulnerability discovered after that date remains open on our site. Here is what that means for us specifically:“
| Risk | Impact | Probability After EOL |
|---|---|---|
| Security breach | Data loss, legal liability | Increases monthly |
| Compliance failure | Audit findings, fines | Near-certain |
| Module incompatibility | Broken functionality | Progressive |
| Developer availability | Harder to hire for legacy | Already happening |
| Insurance implications | Coverage questions | Depends on sector |
The Cost Framing
“The upgrade costs X. Here is what not upgrading costs:“
| Scenario | Estimated Cost |
|---|---|
| Emergency migration after a security incident | 3-5x planned migration cost |
| Compliance remediation after audit finding | Varies, often significant |
| Custom patching without community support | Ongoing, unpredictable |
| Reputation damage from a breach | Potentially millions |
The planned migration is always cheaper than the emergency one. Always.
The Opportunity Framing
This is where you turn a defensive project into an offensive one:
“While we migrate, we can also:”
- Adopt Drupal CMS 2.0 features like Canvas visual editing
- Integrate AI-powered content tools
- Modernize our theme to be component-based
- Improve site performance with updated infrastructure
- Reduce technical debt accumulated over the Drupal 10 lifecycle
Frame the migration as an investment, not a cost.
The Migration Timeline by Site Complexity
Not every site takes the same effort. Here is a realistic breakdown:
Simple Sites (5-15 contrib modules, minimal custom code)
| Phase | Duration |
|---|---|
| Assessment | 1 week |
| Preparation | 2 weeks |
| Execution | 1 week |
| Validation | 1 week |
| Total | 5 weeks |
Medium Sites (15-40 contrib modules, moderate custom code)
| Phase | Duration |
|---|---|
| Assessment | 2 weeks |
| Preparation | 4 weeks |
| Execution | 2 weeks |
| Validation | 2 weeks |
| Total | 10 weeks |
Complex Sites (40+ contrib modules, extensive custom code, integrations)
| Phase | Duration |
|---|---|
| Assessment | 2 weeks |
| Preparation | 6-8 weeks |
| Execution | 2-4 weeks |
| Validation | 4 weeks |
| Buffer | 2-4 weeks |
| Total | 16-22 weeks |
If your site falls into the “complex” category, you needed to start yesterday. Seriously. Twenty-two weeks from today puts you at mid-July. That gives you five months of margin. But margin evaporates fast when contributed modules have surprises or custom code has undocumented dependencies.
What About Jumping Straight to Drupal 12?
I hear this question in every migration planning meeting: “If Drupal 12 is coming out in late 2026 anyway, should we just wait and jump straight from 10 to 12?”
No. Here is why:
- Drupal 12 requires a minimum Drupal 11 version (likely 11.3.0+). You cannot skip Drupal 11 entirely.
- Drupal 12 removes additional core modules (Ban, Contact, Field Layout, History, Migrate Drupal, Migrate Drupal UI). Each requires evaluation.
- Drupal 12 requires PHP 8.5+ — which your hosting provider may not even support yet.
- You would be migrating to a brand-new major version the same month your current version dies. That is zero margin for error.
The correct strategy is:
- Upgrade to Drupal 11 now — stable, proven, well-documented
- Run on Drupal 11 comfortably through end of 2026
- Plan the Drupal 12 upgrade for early-to-mid 2027 when the ecosystem has stabilized
Two smaller, manageable upgrades beat one rushed, risky jump. Every time.
The Action Plan: What to Do on Monday Morning
Today is February 20, 2026. You have 292 days. Here is your Monday morning checklist:
Week 1
- Run the Upgrade Status module on your production site
- Document every incompatible module and custom code issue
- Check PHP, MySQL, and Composer versions on your hosting
- Create a spreadsheet of all contrib modules with Drupal 11 compatibility status
Week 2
- Draft the budget justification using the framework above
- Schedule the conversation with your budget holder
- Set up a staging environment that mirrors production
- Begin the Drupal Rector scan on your custom code
Week 3
- Start updating contrib modules that already have Drupal 11 releases
- Begin refactoring custom code flagged by Drupal Rector
- Contact maintainers of critical unsupported modules
- Begin PHP 8.3 compatibility testing
Month 2
- Complete all contrib module updates
- Complete custom code refactoring
- Attempt first Drupal 11 upgrade on staging
- Begin comprehensive testing
Month 3-4
- Resolve all issues found in testing
- Performance testing and optimization
- Final stakeholder review
- Production upgrade with rollback plan
The Honest Truth
I have been through Drupal 7 to 8, 8 to 9, and 9 to 10 migrations in my career. Every single time, the organizations that started early finished comfortably. Every single time, the organizations that waited suffered.
The 10 to 11 upgrade is, by every objective measure, the smoothest major version transition Drupal has ever produced. The architecture is more similar than any previous leap. The tooling is better. The documentation is more comprehensive.
But “smooth” does not mean “zero effort.” It means the effort is predictable, manageable, and well-supported. If you plan for it.
December 9 is coming. It does not care about your sprint schedule. It does not care about your Q3 feature roadmap. It does not care that your team is busy.
Start now. Not next quarter. Not after the next release. Now.
The clock is ticking. But if you start this week, you have more than enough time to do this right.
Running a Drupal 10 site and feeling the pressure? I have been through every major Drupal migration since 2017. Drop a comment or reach out on LinkedIn — I am happy to answer specific questions about your upgrade path.
And if this article pushed you to finally open that Upgrade Status report? Good. That was the point.