Drupal 10 Reaches Its End of Life on December 9, 2026: A 60-Day Readiness Plan

Drupal 10 reaches its end of life on December 9, 2026: a 60-day readiness plan

On December 9, 2026, Drupal 10 reaches end of life. Your site won't go dark that morning. It will keep serving pages and taking edits. What changes is that the Drupal Security Team stops issuing advisories and patches for Drupal 10 core. After that date, any new vulnerability in Drupal 10 exposes your site to that security risk.

For a federal agency, that means an unpatched system that your ISSO, your ATO package, and your next FISMA review will all flag. For a nonprofit or association, it means risk to donor data, member records, and your reputation. In both cases, the fix is the same: move to Drupal 11.

If you are starting now, you have about 60 days. That is tight but workable, provided you run procurement and technical work in parallel rather than one after the other. Here is the plan we use.

Days 1–10: Assess what you actually have

Before you write a statement of work or call a vendor, find out how big the job is. Two sites that both run "Drupal 10" can differ by a factor of ten in upgrade effort.

Check your current version. Drupal only upgrades from a recent Drupal 10 release. A site stuck on an early 10.x minor has to be brought up to date on the 10 branch before the major upgrade can start. Record the exact core version from the Status Report page.

Run Upgrade Status. Install the contributed Upgrade Status module on a non-production copy of the site. It scans every contributed module, custom module, and theme for Drupal 11 compatibility and deprecated code. The report it produces will drive the rest of your plan.

Inventory your modules in three groups:

1. Contributed modules that already have Drupal 11 releases. Updating these is usually routine.
2. Contributed modules with no Drupal 11 release. For each one, decide whether to patch it, replace it, or remove it. Many sites find several modules they no longer use.
3. Custom modules and themes. Your team or vendor has to fix this code, so this group is usually where most of the effort goes.

Talk to your hosting provider. Ask what PHP, database, and web server versions they support, and when they can provision them. If you self-host or run on-premises, get your infrastructure team involved now, because server changes often require change-control approval.

By day 10, you should have a one-page summary covering the module counts, the custom code footprint, the hosting gaps, and a rough effort estimate. Leadership needs that summary to approve funding.

Days 5–20: Procurement and vendor selection

Start procurement during assessment, not after it. Contracting timelines are usually what kills an upgrade schedule.

If you already have a vendor, check your contract. An existing O&M or support contract may already cover a major version upgrade, or it may cover it through a task order modification. Ask your contracting officer or COR early. A modification is almost always faster than a new award.

If you need a new vendor, use a vehicle you can move quickly on. Federal buyers can often order through GSA MAS (SIN 54151S for IT professional services), NASA SEWP, an existing agency BPA, or, for small scopes, a simplified acquisition. Small business set-asides, including SDVOSB, 8(a), HUBZone, and WOSB, can shorten competition further. Nonprofits and state and local organizations should check whether a cooperative purchasing agreement lets them skip a full RFP.

What to require from any vendor:

• Verifiable Drupal 10-to-11 upgrades already completed, with references you can call.
• Named staff who hold current Acquia certifications (Developer, Back End Specialist, Front End Specialist, or Triple Certified Drupal Expert), not a pledge to "leverage certified resources."
• A written testing approach that covers accessibility, not just functional checks.
• A rollback plan. If the vendor can't explain how they would undo a failed deployment, move on.
• Hosting and security experience that fits your environment: FedRAMP-authorized hosting for agencies, PCI awareness if you take payments.

Scope the work as a fixed deliverable where you can: "Site upgraded to Drupal 11, passing the agreed test plan, deployed to production." Open-ended hourly work tends to drift, and you don't have time for drift.

Days 10–25: Get the servers ready

Drupal 11 raises the platform floor. Confirm each of these in every environment (local, development, staging, and production):

• PHP 8.3 or later. This is the most common blocker. Check that your PHP extensions and any opcode cache settings carry forward.
• Database: MySQL 8.0+, MariaDB 10.6+, PostgreSQL 16+, or SQLite 3.45+ for development.
• Web server: Apache 2.4.7+ or Nginx. Microsoft IIS is no longer supported, so a Windows-hosted site has to migrate to a supported web server before it can upgrade. Plan extra time for that.
• Composer 2.7.7 or later and Drush 13 for deployment and command-line work.

Upgrade PHP and the database first, while the site is still on Drupal 10. The latest Drupal 10 release runs on PHP 8.3, so you can confirm the site is stable on the new platform before you change any application code. Taking the infrastructure change and the application change one at a time makes problems much easier to diagnose.

Days 15–40: The technical upgrade

This is the core of the work. The sequence matters.

1. Update to the latest Drupal 10 release. Apply every pending contributed module update, run database updates, and export configuration. Freeze new feature work from this point on.
2. Fix deprecated code in custom modules and themes. Drupal Rector automates a large share of these fixes. Add core_version_requirement: ^10 || ^11 to each custom module's .info.yml so the code runs on both versions while you work.
3. Deal with incompatible contributed modules. Swap in Drupal 11-ready replacements, apply community patches where they exist, or remove modules you no longer need. Uninstall a module on Drupal 10 before the core upgrade rather than after.
4. Check front-end dependencies. Drupal 11 ships jQuery 4 and removes several older libraries from core. Custom JavaScript and older themes often break here. Classic and Stable themes are gone from core, so sub-themes built on them need a contributed version or a rebuild.
5. Upgrade core with Composer. Update drupal/core-recommended and related packages to ^11, resolve dependency conflicts, run drush updatedb, and export the resulting configuration.
6. Commit everything to version control and deploy to staging through your normal pipeline. The upgrade should never be applied by hand on a server.

Keep a written log of every patch, replacement, and removal. Your QA team needs it, and so will the next person who maintains the site.

Days 35–55: Quality assurance

Don't let a compressed schedule squeeze out testing. Plan at least two full test cycles on staging with a fresh copy of production content.

Functional testing. Test every content type, form, view, search function, and user role. Pay particular attention to editorial workflows (content moderation, scheduled publishing, media handling) because editors notice breakage there first.

Integrations. Check SSO and SAML login, CRM or AMS connections, payment gateways, analytics, APIs, and feeds. Integrations tend to fail quietly and show up weeks later.

Accessibility. Run automated scans with a tool such as axe or WAVE, then do manual keyboard and screen reader testing on key templates. Federal sites must continue to meet Section 508, and a front-end change is exactly when regressions appear.

Visual regression. Automated screenshot comparison between production and staging catches layout problems that manual testing misses, especially after jQuery and theme changes.

Performance and security. Load-test critical pages, confirm caching and CDN behavior, and run a vulnerability scan. Agencies should hand the results to the ISSO so documentation stays current.

User acceptance testing. Give real content editors a structured test script and a deadline. Their sign-off is your go-live gate.

Days 55–60: Launch and stabilize

• Schedule a content freeze and a low-traffic deployment window.
• Take a full backup of the database, files, and codebase, then confirm the backup actually restores.
• Deploy, run database updates, clear caches, and run a smoke test from a prepared checklist.
• Keep the team on call for at least a week afterward. Watch the error logs, 404 reports, and editor feedback closely.
• Update your system documentation, and for agencies, notify your ISSO so the ATO record reflects the new platform.

If you can't finish by December 9

Some organizations won't make the deadline, often because of procurement delays or large custom codebases. If that describes you, don't do nothing. Harden the Drupal 10 site with a web application firewall, tighter access controls, and closer monitoring. Consider commercial extended-support options as a short-term bridge, document the risk formally, and set a firm completion date early in 2027. An unsupported site with a plan and compensating controls is a manageable risk. An unsupported site with no plan is not.

The bottom line

Moving from Drupal 10 to Drupal 11 isn't a rebuild. It is a structured, predictable upgrade, and it goes smoothly for organizations that start early, run procurement alongside the technical work, and treat testing as required. Sixty days is enough time if you start this week.