What Are Drupal Upgrades?
Upgrading a Drupal site isn’t a single task — it’s a process that involves multiple layers of the system working together:
- Core upgrades — Updating Drupal itself (e.g., 10.5 to 11.2), which brings security patches, new APIs, and platform changes
- Contrib upgrades — Updating third-party modules and themes, many of which need to stay in sync with the core version
- Composer updates — Managing dependencies at the PHP package level using composer.json and composer.lock
- Custom patching — Writing or applying code changes when no official update or fix exists
These pieces are interdependent. You often can’t upgrade one layer without touching the others — and without the right approach, things break.
That’s why Drupal upgrades require more than just running composer update. They need planning, compatibility checking, patch management, and validation.
Why This Matters
Most Drupal teams eventually hit one of these issues:
- Can’t upgrade core because a key module isn’t compatible
- Composer won’t resolve due to locked or abandoned dependencies
- A patch is missing—or worse, no one has written it yet
- An upgrade breaks functionality with no clear fix
This is where we come in: combining Composer insight, patch development, and upgrade experience to get your site cleanly updated, tested, and deployed.
What We Do
We take a full-stack approach to upgrades—not just version bumps.
• Plan and execute Drupal core updates with proper testing and rollback safety
• Update contrib modules and scan for API-breaking changes
• Review and adjust Composer constraints to match real-world compatibility
• Identify existing patches or write custom patches as needed
• Use patch tracking (composer-patches) to keep everything version-controlled
• Handle partial or full upgrades depending on urgency and scope
• Validate the site with test coverage and manual QA before anything goes live
In short: we upgrade what can be upgraded, fix what blocks the rest, and leave your stack in a clean, maintainable state.
Custom Patching
Patching is not just applying what exists. In many cases, we:
- Write patches to make contrib modules compatible with your core version
- Patch abandoned modules to restore compatibility or stability
- Remove or refactor conflicting patches
- Maintain your patch strategy in Git and Composer
We’ve written and contributed dozens of patches—small compatibility fixes, performance improvements, and full backports.
Technologies We Use
- Composer
- Drush
- GitHub
- cweagans/composer-patches
- Patch tracking and metadata docs
- Testing and code quality tools: PHPStan, Rector, PHPUnit, Behat
Kickstart your next Drupal project with Vortex, our battle-tested, Docker-ready starter kit.
Who This Is For
You’re blocked from upgrading core because a module won’t support it
- Composer fails to resolve or install due to version conflicts
- You want to upgrade safely without risking production
- You’re on Drupal 10.x and need to prepare for Drupal 11
- Your team is tired of patching things manually (or not at all)
Real Example
A client on Drupal 10.5 needed to upgrade to 11.2 but was blocked by a custom module and two contribs. We created three compatibility patches, updated 20+ packages via Composer, and safely deployed the upgrade over two sprints with full test coverage.
FAQs
Can we just upgrade one module or one piece of the stack?
Yes, but we’ll assess the downstream impact first. Sometimes one change forces others.
Do we need to use patches long-term?
Not always. We often help replace them later with upstream fixes or refactors.
Can you help us keep this up to date over time?
Absolutely. We offer monthly upgrade plans with audit reports and patch lifecycle tracking.