CMS Care Lab

Drupal 11 migration without the scramble

Drupal 11 is the supported target for most new work in 2026. Whether you are leaving Drupal 7 or stepping up from Drupal 10, I migrate with an audit first and a fixed-price plan before build starts.

Get a free assessmentSee the process

Why Drupal 11

Why Drupal 11 — not “upgrade sometime”

Drupal 10 support winds down around late 2026. Starting a migration to Drupal 11 now avoids a second forced upgrade soon. From Drupal 7 there is no in-place upgrade — it is a rebuild: new site plus the Migrate API for content and configuration.

Teams delay Drupal 11 migration because the site “still works.” That is the wrong signal. The right signals are support dates, PHP and hosting constraints, module health on Drupal.org, editor complaints, and whether last year’s security backlog was closed. Drupal 11 gives you a supported core, current PHP expectations, and a module ecosystem that is actively maintained for this major version.

If you are already on Drupal 10, the jump to 11 is usually closer to a planned major update with deprecation cleanup than a full rebuild — still audited, still staged, still priced before work starts. If you are on Drupal 7 or 8/9, treat the project as a migration with content modelling and a theme rebuild at its centre.

  • Drupal 7 / 8 / 9 / 10 → Drupal 11
  • Module & custom-code audit before any quote hardens
  • Content, users, taxonomy, and files migrated deliberately
  • Theme rebuilt in Twig; abandoned contrib replaced
  • URL map + 301 redirects so organic traffic survives
  • Fixed price agreed before development starts

Fit

Who this is for

Still on Drupal 7, 8, or 9

End-of-life or aging cores that need a supported line — see also Drupal 7 end of life.

On Drupal 10, heading to 11

Move before Drupal 10 EOL so you are not forced into a rushed follow-on upgrade.

Architecture

What changes between Drupal 7 and Drupal 11

Drupal 7 sites store much of their “shape” in the database and PHPTemplate themes. Modern Drupal stores configuration in YAML, themes in Twig, and expects Composer-managed dependencies. Custom modules that relied on procedural hooks often need OOP services, dependency injection, and updated APIs. Integrations that scraped Drupal 7 paths or session cookies may need redesign against JSON:API or authenticated services.

That is why a Drupal 11 migration always starts with inventory: every enabled module, every custom project in the codebase, every content type and field, every external system that posts into or pulls from the site. Guessing those mid-project is how timelines explode.

Good news for content: the Migrate API is mature. Nodes, users, taxonomy terms, files, and many field structures can move with repeatable pipelines. We run migrations iteratively on staging — fix mapping, re-import, validate counts — until parity is good enough for a planned cutover.

How it works

How a Drupal 11 migration runs

  1. Inventory — modules, custom code, content types, integrations, hosting and PHP versions.
  2. Target model — Drupal 11 content types, fields, roles, and workflows you actually need (not a 1:1 clone of every legacy quirk).
  3. Migrate — content, users, taxonomy, and files via the Migrate API, with custom process plugins where source data is messy.
  4. Rebuild — theme in Twig; replace abandoned contributed modules; rebuild critical forms and views.
  5. Preserve SEO — URL map, 301s, metatag carryover, staging QA against known ranking URLs.
  6. Cutover — minimal downtime plan, DNS/host coordination, and a post-launch support window.

The first deliverable is always the audit. Discovering incompatible custom code halfway through is the most common way migrations overrun — we surface that before the fixed price is locked.

During build I keep a written risk list: modules without a Drupal 11 port, editor features that need redesign, media libraries with fragile file paths, and multilingual edge cases. You see that list before go-live, not after.

Timelines & cost

What drives timeline and fixed price

Brochure sites with a handful of content types and little custom code can complete in a few weeks once hosting is ready. Enterprise-shaped sites with dozens of modules, custom checkout/membership flows, or heavy multilingual content take longer — sometimes months of phased work. The assessment turns “it depends” into a scoped plan with a calendar and a fixed price.

Price tracks risk more than page count: undocumented custom modules, unavailable theme source, broken staging environments, and “nobody knows what this Views display does” all cost more to unwind than clean content alone. That is why I ask for admin access (or an anonymised database clone) early — not to start unpaid development, but to stop guessing.

Questions

Drupal 11 migration — FAQ

Can you migrate Drupal 7 directly to Drupal 11?

Yes. Drupal 7 can go straight to Drupal 11 with the Migrate API — no forced hop through 8 or 9. Content and configuration move; modules map to modern equivalents; the theme is rebuilt in Twig.

Why Drupal 11 instead of Drupal 10?

Drupal 10 support ends around late 2026. Landing on Drupal 11 now usually saves a second upgrade cycle soon after go-live.

How long does a Drupal 11 migration take?

A small brochure site can take a couple of weeks; a large multi-module site takes longer. The free assessment scopes timeline before any fixed-price quote.

Will I lose rankings?

No. Aliases and redirects are planned deliberately so search traffic and inbound links survive the cutover.

Do editors need training?

Usually yes — briefly. Layout Builder, Media, and modern admin UX differ from Drupal 7. I include a short handoff and hypercare so people are not abandoned on day one.

Related

Explore more

Planning a Drupal 11 migration?

Get a free assessment and a clear, fixed-price plan for your site.

Request your free assessment