By Greg Nowak. Last updated 2026-07-04.
Drupal 8 development in 2026 needs a different mindset from ordinary feature delivery. If you are planning a new Drupal build, Drupal 8 is not a sensible target. If you have inherited a live Drupal 8 site, however, development may still be unavoidable: fixing blocked workflows, keeping publishing moving, stabilizing integrations, and preparing the site for a supported future.
The business decision is not simply “can we make this change?” A better question is: will this change reduce risk, preserve value, and help the upgrade, or will it make an unsupported platform harder to leave? That distinction matters for owners, operations leads, and agencies responsible for keeping an old site useful without pretending it is healthy.
Start with the support reality
Drupal 8 reached end of life on November 17, 2021. That means Drupal 8 core no longer receives normal security support, and Drupal 8-only contributed projects are not a reliable foundation for future work. As of July 2026, supported core work is on Drupal 10 and Drupal 11, with Drupal 10 itself scheduled to reach end of life on December 9, 2026. So a Drupal 8 rescue plan should normally aim beyond Drupal 10, not stop there.
In practical terms, Drupal 8 development should now mean controlled legacy support. Keep the site running, remove upgrade blockers, and avoid large new builds that tie more business logic to obsolete APIs.
| Request | Usually safe on Drupal 8 | Better during upgrade | Decision rule |
|---|---|---|---|
| Critical bug fix | Yes | Also test in upgrade branch | Fix it if sales, publishing, compliance, or operations are blocked. |
| New integration | Only if small and isolated | Usually yes | Avoid coupling new vendor logic to unsupported APIs. |
| Contrib module replacement | Yes, when it removes a blocker | Yes | Prefer maintained modules with Drupal 10/11 compatibility. |
| Large editorial redesign | Rarely | Yes | Do not spend design budget on a theme layer you may soon replace. |
| Custom module cleanup | Yes | Yes | Separate custom logic, remove deprecated calls, and document dependencies. |
What safe legacy development looks like
Safe Drupal 8 work is boring in the best way. It is version-controlled, Composer-managed, tested on a copy of production, and documented well enough that the next developer is not forced to guess. Custom modules should live in dedicated custom directories. Patches should be committed locally and recorded in Composer. Manual uploads, core edits, and unexplained vendor changes should be treated as risks to unwind.
For day-to-day module work, keep the workflow explicit and run it from the project root where composer.json lives:
composer require drupal/PROJECT_NAME
drush pm:install module_name
drush updatedb
drush cache:rebuildOlder notes often use drush en; that alias still maps to module installation in current Drush, but drush pm:install is clearer in handover documentation. The important point is not the command spelling alone. It is that Composer, Drush, database updates, and cache rebuilds happen consistently in a repeatable deployment process.
Audit before promising the upgrade
A serious Drupal 8 upgrade starts with discovery, not estimates written from memory. List every contributed module, custom module, theme, patch, integration, scheduled job, and deployment assumption. Mark each item as keep, replace, rewrite, or remove. Then rank the business-critical systems first: payment flows, CRM sync, search, SSO, forms, reporting, imports, and editorial permissions.
Drupal's major-version upgrade path is sequential. You do not safely jump from Drupal 8 directly to Drupal 11 or Drupal 12. A Drupal 8 site needs a staged route through Drupal 9, then Drupal 10, then Drupal 11, with database updates and compatibility checks at each step. For older Drupal 8 builds, confirm whether a development copy can first reach the late Drupal 8.8 or 8.9 line, because the Drupal 8 to 9 path was designed around that compatibility window.
Use Upgrade Status where it fits, but do not install a current release blindly on an old Drupal 8 codebase. Version compatibility matters. On modern stages, Upgrade Status helps check the environment, contributed projects, custom code, deprecated APIs, configuration, and next-major requirements. For Drupal 8, you may need an older compatible release, a temporary analysis branch, or a staged check once the site reaches Drupal 9.
Where outside help pays off
The value of an experienced consultant is not just writing patches. It is helping the team make clean decisions under constraint. Should you stabilize first or upgrade immediately? Which modules are genuine blockers? Which custom code can be refactored now without wasting budget? Which new feature requests should be paused until the supported platform is in place?
For agencies, this is also useful risk control. A short independent audit can turn a vague legacy problem into a scoped delivery plan with clear assumptions, known blockers, and a defensible sequence of work. For business owners, it helps separate urgent operational fixes from expensive work that should wait for the upgrade.
A practical next step
If your Drupal 8 site is still important to the business, treat the next change as part of the upgrade plan. Stabilize what must keep working, document what is fragile, and move toward supported Drupal in staged, testable steps. Greg can help audit the stack and shape a practical Drupal upgrade plan before more budget is spent on the wrong layer.
Related on GrN.dk
- MariaDB 10.6 EOL: quiet CMS hosting debt needs a real upgrade plan before July 2026
- Drupal 10's December 2026 Deadline: Start With the Upgrade Inventory
- Drupal CMS 2.0 Speeds Marketing Site Rebuilds, but It Is Not Autopilot
Need help with this kind of work?
Plan a Drupal upgrade with Greg Get in touch with Greg.