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
- Model the content before designing the theme — structure outlives visual design.
- Name fields for meaning, not position; field names are effectively permanent.
- Curate taxonomies with an owner, or they fill with near-duplicates.
- Constrain layout freedom to the pages where it genuinely adds value.
Model before you theme
The strongest predictor of whether a Drupal build stays maintainable is whether someone modelled the content properly in the first fortnight. Themes can be replaced. A content model with the wrong shape gets worked around for years.
Start on paper. List the things the site is actually about — services, case studies, people, events, locations — and the relationships between them. If two things have genuinely different fields, they are different content types.
Content types, fields and the reuse question
Drupal makes it easy to create fields, which is why so many sites accumulate field_body_2 and field_image_new. Field names are effectively permanent, so name them for meaning rather than position: field_summary, not field_text_top.
Reuse fields across content types where the meaning is identical and split them where it is not. Sharing a field because the widget looks the same, when the two uses mean different things, causes trouble the first time you need to change one of them.
Taxonomy is a structure, not a tag box
Free tagging has its place, but most taxonomies on a business site should be curated vocabularies with a defined set of terms and an owner. Uncontrolled vocabularies fill with near-duplicates within months.
- Use separate vocabularies for genuinely separate axes — sector and service are not the same list.
- Decide whether hierarchy is real. Deep trees are hard to edit and rarely used as intended.
- Give every term a purpose: filtering, routing, display or all three.
Paragraphs, layout builder, or neither
The temptation is to give editors complete layout freedom. In practice, unlimited flexibility produces inconsistent pages and a design system nobody can maintain.
A pragmatic middle ground: a constrained set of well-designed components that editors can arrange, with layout freedom confined to landing pages where it genuinely adds value. Standard content types stay templated so they remain consistent and fast to produce.
Signs the model is wrong
A content model rarely fails loudly. It degrades, and the symptoms show up in the editorial team long before anyone raises them with a developer.
Watch for editors pasting formatted content into a plain body field because the right field does not exist; for content types that differ by a single field, which usually means they should be one type with a flag; for a taxonomy containing three spellings of the same term; and for editors asking how to make one page look different from the others, which means the template is too rigid or the component set is too small.
Each of these is cheap to fix in the first month and expensive after two years of content has accumulated on top of it. Reviewing the model once a year, with the people who use it daily, is one of the highest-return hours you can spend on a Drupal site.
Frequently asked questions
As few as genuinely differ. If two types share almost all their fields and differ only in how they are displayed, they are one type with a category field. Conversely, forcing genuinely different things into one type with many optional fields produces a confusing editing experience and unreliable listings.
Paragraphs suit structured, repeatable component stacks and give tighter editorial control. Layout Builder suits pages that genuinely need arbitrary arrangement. Many sites benefit from Paragraphs for standard content types and Layout Builder confined to landing pages.
If the thing has its own page, its own fields and its own lifecycle, it is a node. If it exists mainly to classify other content, it is a term. Offices, people and services are usually nodes; sectors and topics are usually terms.
