Drupal 8 development means two very different things in 2026. If you are planning a new build, Drupal 8 is the wrong target. If you are inheriting a live Drupal 8 site, though, development is still very real work: stabilizing the platform, protecting business processes, and preparing a clean route to a supported version without breaking publishing, integrations, or reporting.
That distinction matters for business owners, operations leads, and agency teams. The hard part is rarely writing one more feature. The hard part is deciding which work is safe to do on a legacy stack, which work should wait for the upgrade, and how to avoid turning every urgent fix into more long-term debt.
What Drupal 8 development should mean now
Drupal 8 reached end of life on November 17, 2021. In practice, that means no ongoing security support for Drupal 8 core and no reliable future for Drupal 8-only contributed modules. So in 2026, sensible Drupal 8 development is not about starting fresh on 8.x. It is about reducing risk while you move toward supported Drupal.
Reasonable Drupal 8 work still includes:
- Fixing business-critical bugs that block sales, publishing, or internal workflows.
- Auditing custom modules, integrations, and deployment processes before an upgrade.
- Isolating custom logic so it can be tested and migrated more predictably.
- Replacing abandoned contrib dependencies where they would block the next major version.
What usually does not make sense is a large new feature program tightly coupled to an unsupported Drupal 8 stack. If the feature matters enough to fund properly, it usually matters enough to build on supported foundations.
Practical rules for safe legacy work
If a Drupal 8 site is still earning its keep, treat every change as part maintenance and part upgrade preparation. The safest pattern is to keep custom code organized, dependency-managed, and easy to reason about. Custom logic should live in dedicated modules, not in core hacks, one-off snippets, or undocumented theme behavior.
For teams touching legacy code today, a few rules go a long way:
- Keep custom work clearly separated from contributed code so it can be reviewed and migrated cleanly.
- Make sure module metadata and dependencies are explicit, not tribal knowledge.
- Use Composer from the project root to add and update packages instead of mixing manual uploads with managed dependencies.
- Record any patches, overrides, and environment assumptions so the upgrade team is not forced to rediscover them later.
For Composer-managed projects, the day-to-day workflow still tends to look like this:
composer require drupal/PROJECT_NAME
drush en module_name
drush updatedbThose commands are simple, but the discipline behind them is what matters. If a site has half of its code installed manually and the other half managed with Composer, every future update becomes more fragile and more expensive. If the site was originally built from tarballs or manual uploads, budget time to convert it into a Composer-managed codebase before you promise easy updates.
For net-new Drupal work or rebuilds, start from a supported Composer-managed project such as drupal/recommended-project. That keeps dependencies aligned with official releases and avoids locking a new delivery into legacy assumptions from day one.
Plan the upgrade as a delivery project, not a weekend task
Drupal's official upgrade path is sequential. You do not skip major versions. For a Drupal 8 site, that means planning a route through Drupal 9 and then onward to Drupal 10 and Drupal 11. That sounds slower, but it reduces the chance of data loss, broken schemas, and hard-to-debug contrib conflicts.
A practical upgrade plan usually starts with four questions:
- Which contributed modules are still maintained, and which are now blockers?
- How much custom code depends on deprecated APIs?
- Is the site already Composer-managed, or does that conversion need to happen first?
- Can the team freeze unnecessary feature work long enough to upgrade cleanly?
The official guidance to use Upgrade Status is worth following early. It is faster to get a grounded compatibility report than to guess from issue queues and old documentation. On larger sites, I would also map every integration by business criticality: payments, CRM sync, search, SSO, forms, and reporting first; editorial nice-to-haves later. That gives stakeholders a delivery order they can actually use.
There is also a timing issue here. As of June 2, 2026, supported core work is on Drupal 10 and Drupal 11, and Drupal 10 itself is scheduled to reach end of life on December 9, 2026. So if you are budgeting a Drupal 8 rescue now, do not treat Drupal 10 as a final destination. Plan for a route that keeps the site supportable beyond that date.
Where outside help pays off
The value of a consultant on a Drupal 8 engagement is not mystery expertise. It is structured decision-making. A good consultant can separate urgent fixes from upgrade noise, turn a messy module stack into a keep-replace-rewrite list, and give your internal team or delivery agency a sequence that is technically defensible and commercially realistic.
If you are sitting on a Drupal 8 site and need to decide whether to stabilize, upgrade, or replatform, that is usually the right moment to bring in outside help. A short technical audit can save months of confused delivery later. If you want that kind of practical support, Greg can help you turn a legacy Drupal problem into a clear delivery plan.
Need help with this kind of work?
Need a clear plan for a Drupal 8 site? Greg can audit the stack, prioritize the risks, and help your team move to a supported platform. Get in touch with Greg.