Upgrading from Drupal 10 to Drupal 11: what actually changes
Drupal 11 is a far smaller step than the Drupal 7 to 9 migration was. Here is what the upgrade touches, what breaks, and the order to do it in.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Decoupling is justified by multiple genuine consumers, not by architectural taste.
- You give up contextual editing, preview and much of the module ecosystem.
- Progressive decoupling is the better trade for most business sites.
- Decide preview, caching and authentication before you commit.
The honest case for decoupling
Decoupled Drupal makes sense when the same content genuinely feeds several consumers — a website, a mobile application, a partner feed, an in-store display — or when a front-end team works in a framework and toolchain of its own.
It makes considerably less sense when there is exactly one consumer, which is a website. In that case you are adding a network boundary, a second deployment, a second set of dependencies and a caching problem, in exchange for architectural tidiness.
What you give up
Drupal's contextual editing, layout tools, preview and much of the contributed module ecosystem assume Drupal renders the page. Decoupling means rebuilding those capabilities or doing without them.
Editors notice. Losing in-place preview is one of the most common complaints after a decoupled launch, and retrofitting it is expensive.
Progressive decoupling as a middle path
Drupal renders the page and hands specific interactive regions to a JavaScript framework. Editors keep their tooling, the site keeps its server-rendered performance and SEO characteristics, and the parts that genuinely need rich interaction get it.
For most business sites this is the better trade, and it can be adopted incrementally rather than as a rebuild.
If you do decouple, decide these early
- JSON:API or GraphQL, and who owns the contract between the two teams.
- How preview works for unpublished content.
- Where caching and invalidation live, and how a content change reaches the front end.
- How authentication and per-user content are handled.
The operational cost nobody budgets for
A decoupled build turns one deployable artefact into two, each with its own dependencies, pipeline, hosting and monitoring. That is manageable, and it is rarely in the original estimate.
The subtler cost is the contract between them. Every field added in Drupal needs a corresponding change in the front end, which means two teams, two release cycles and a coordination overhead on changes that used to be a configuration edit. Organisations with a single small team frequently find this slows them down rather than speeding them up.
None of this argues against decoupling where it is warranted. It argues for making the decision on the basis of how many consumers the content really has, and staffing accordingly rather than discovering the overhead after launch.
Frequently asked questions
Not automatically. A well-cached traditional Drupal site behind a CDN is very fast. Decoupled architectures can be fast too, and they introduce new ways to be slow particularly when the front end makes many small API calls to assemble a page.
JSON:API is in core, requires no additional modelling and is the pragmatic default. GraphQL is worth the extra setup when consumers need to shape their own queries precisely and you have a front-end team that will use that capability.
Yes, and it is often the best answer. Keep the content-managed pages server-rendered and decouple the specific application-like sections that genuinely need it.
