Moving a Drupal 7 site to Drupal 11 is a rebuild with a content transfer bolted on, not an upgrade — and the sooner a budget reflects that, the better the project goes.
Nobody enjoys hearing this, and plenty of sales conversations avoid saying it. But the architecture changed underneath in ways that make "upgrade" the wrong word, and I would rather explain why than let a client discover it in month three.
What actually changed underneath
Drupal 7 was a procedural PHP application with a hook system and its own implementations of routing, sessions, dependency handling and templating. Drupal 11.4 is a Symfony application. Read from core's own composer.json: it requires symfony/http-kernel, symfony/routing, symfony/dependency-injection, symfony/event-dispatcher and eight more Symfony components, all at ^7.4, plus twig/twig ^3.28.
That is not a version bump. It changes what a module is:
- Hooks became plugins and services. Extensibility runs through a service container with explicit dependencies rather than functions discovered by name.
- PHPTemplate became Twig. Templates lost the ability to run arbitrary PHP, and gained automatic output escaping.
- Configuration left the database. Config exports to YAML into
$settings['config_sync_directory']— the setting is read incore/lib/Drupal/Core/Config/FileStorageFactory.phpand throws if it is undefined. Drupal 7 had no equivalent, which is why the Features module existed. - Rendering became cacheable metadata. Cache tags and contexts travel with render arrays, which is what makes BigPipe and precise CDN invalidation possible.
A Drupal 7 custom module does not port. It gets rewritten against different APIs. That is the honest baseline.
The detail most migration plans miss
Here is something worth checking before anyone quotes you a number. In Drupal 11.4.6, the modules that perform a Drupal 7 migration are marked deprecated in their own info files:
# core/modules/migrate_drupal/migrate_drupal.info.yml
lifecycle: deprecated
lifecycle_link: https://www.drupal.org/node/3223395#s-migrate-drupal
# core/modules/migrate_drupal_ui/migrate_drupal_ui.info.yml
lifecycle: deprecatedThe general-purpose migrate framework is not deprecated and is not going anywhere. It is specifically the Drupal-to-Drupal layer and its upgrade UI that carry the deprecation flag.
What that means in practice: plan the content transfer as migrations you write and own, sourced from the old database, rather than assuming the point-and-click upgrade path will still be there for the whole life of the project. Anyone quoting your migration should be able to say which of the two they are relying on.
What transfers, and what does not
| What you have | What happens to it |
|---|---|
| Nodes, users, taxonomy, files | Transfers. This is what the migrate framework is good at. |
| Content types and fields | Transfers as structure; field types sometimes need mapping. |
| Views | Rebuilt. The Views UI is familiar; the stored configuration is not compatible. |
| Custom modules | Rewritten against plugins, services and the entity API. |
| Theme | Rewritten. PHPTemplate to Twig is a full front-end rebuild. |
| Contributed modules | Case by case. Some are now core, some have modern equivalents, some are gone. |
| Panels / Features config | Superseded by Layout Builder and core configuration management. |
The row that surprises people is the theme. A Drupal 7 theme is not portable in any meaningful sense, and front-end effort is routinely half the project. Scope it as such — that is what Drupal theming work is for, and it is not the same skill set as the back-end migration.
What you get for it
The rebuild has to buy something, or it is just cost. On Drupal 11.4 these are all stable in core, verified from the module directory on disk:
- JSON:API — a standards-based read/write API with no configuration, so a decoupled front end or a mobile app becomes a decision rather than a project.
- BigPipe — the page streams, with dynamic parts filled in after the cacheable shell arrives.
- Layout Builder — per-entity and per-bundle layouts without Panels.
- Configuration management — the site's structure lives in version control, so deployments stop being a database operation.
- Twig auto-escaping — an entire class of cross-site scripting defect stops being possible in templates.
A useful way to frame it to a stakeholder: Drupal 7's technical debt was ten years of a design from 2001 stretched past its original assumptions. The rewrite paid that off. You are buying a platform whose next ten years are incremental.
If you are at the point of costing this, an architecture assessment before the build is the cheapest hour in the project — it is where the scope surprises get found.
How to scope it without guessing
- Inventory the contributed modules. For each, decide: in core now, has a modern equivalent, needs rebuilding, or drop it. This list drives most of the estimate.
- Count the custom modules and read them. A 200-line utility module is an afternoon. A workflow module with its own tables is not.
- Count the Views. Each is a rebuild, and most sites have more than the owner remembers.
- Decide the design question first. Reproducing the old theme exactly is often more expensive than a new one.
- Separate content transfer from feature rebuild. They are different work with different risks, and mixing them in one estimate hides both.
Common questions
Is there any in-place upgrade path from Drupal 7?
No. There has been no in-place upgrade since Drupal 7 to 8. You build a new site and migrate content into it.
Since Drupal 7, are major versions still rebuilds?
No, and this is the important part. Drupal 8 to 9 to 10 to 11 have been incremental: deprecations are announced, removals happen at major versions, and a well-maintained site moves in days. The rebuild was a one-off cost of the architecture change.
Should I go to Drupal 11 or wait for Drupal 12?
Build on the current supported release. Drupal 12 introduces real breaking changes — attribute-based plugin discovery replacing annotations, for one — but those land as deprecations first on a maintained site, not as a rebuild.
Can I keep my Drupal 7 site running instead?
Drupal 7 reached end of life and no longer receives community security coverage. Running it means accepting that risk or paying a vendor for extended support. That is a business decision, but it should be a conscious one.
Is Backdrop CMS a cheaper way out?
For some sites, genuinely yes — it preserves the Drupal 7 model rather than replacing it. It is a different trade-off, covered separately.
Where to go from here
If the rebuild cost is the blocker, read the Backdrop CMS alternative for Drupal 7 sites before committing. If you are weighing the platform itself rather than the version, Drupal against WordPress is the wider comparison.
When you want the estimate rather than the explanation, Drupal development services covers the module and migration work, and send over your module list if you want a read on where the cost is concentrated before you commit to anything.