Drupal 7 Migration in 2026: Upgrade to Drupal 11 or Move Off Drupal?

Many organizations postponed the decision. Drupal 10, the version most guides still recommend as the target, reaches end of life on 9 December 2026, in the same week Drupal 12 is released. Drupal 12 also drops the core modules that migrate Drupal 7 sites.

In late 2026, a Drupal 7 site should migrate to Drupal 11, because Drupal 10 reaches end of life on 9 December 2026 and Drupal 12 removes the core Migrate Drupal and Migrate Drupal UI modules that Drupal 7 migrations depend on.

This article compares three exits for a Drupal 7 site: rebuilding on Drupal 11, moving to another platform and buying extended support as a bridge. It shows what migrates automatically, what has to be rebuilt and what each path costs. It does not cover upgrades between Drupal 8, 9 and 10, and it does not compare hosting providers.

Key takeaways

• Drupal 7 community support ended on 5 January 2025. Paid extended security support is available from vendors approved by the Drupal Association.
• Drupal 10 reaches end of life on 9 December 2026, so a Drupal 7 site should migrate straight to Drupal 11.
• Drupal 12 removes Migrate Drupal and Migrate Drupal UI from core. They remain in Drupal 11, which makes Drupal 11 the natural landing point for Drupal 7 content.
• A Drupal 7 to Drupal 11 move is a rebuild with a content migration. Content, users, taxonomy and files migrate with core tools, while the theme, custom modules and most Views are rebuilt.
• Staying on Drupal suits content-heavy sites, multi-site setups and complex editorial permissions. Moving off suits small marketing sites and products that have outgrown a CMS.
• Typical budgets run €15,000–€40,000 for a small site, €40,000–€120,000 for a mid-size site and €120,000 or above for large platforms with commerce, integrations or many sites.

The dates that shape the decision

The Drupal core release cycle page lists the official dates. The practical consequence is simple: migrating to Drupal 10 in late 2026 buys a site a few weeks of support, and waiting for Drupal 12 removes the core tools the migration relies on.

How many sites are still on Drupal 7?

A large share. W3Techs data from August 2026, reported by The DropTimes, shows Drupal 7 on 29.6% of detected Drupal sites, almost level with Drupal 10 at 30.6% and well ahead of Drupal 11 at 19.2%. About half of all detected Drupal sites run a version that no longer receives community support.

These sites are rarely abandoned. Many are long-lived platforms with years of content, custom integrations and subscription or membership logic, which is exactly why their owners have hesitated.

Three exits for a Drupal 7 site

Extended support deserves a clear-eyed view. The Drupal 7 end-of-life page lists vetted vendors that provide security patches for core and selected modules. That covers known vulnerabilities, but the rest of the stack still ages: PHP versions, hosting images, libraries such as jQuery and CKEditor 4, and the pool of developers willing to work on Drupal 7. Treat it as time to finish a migration, with an end date written into the plan.

Stay on Drupal or move off: a signal check

Go through both columns. The side with more matches is usually the right direction, and a close result calls for a short discovery phase before committing.

When the product side wins, moving off Drupal does not have to be a single switch. A common pattern keeps Drupal for content and administration while new services take over the product logic, and retires Drupal later or keeps it as a content backend.

What migrates and what gets rebuilt

Drupal 7 and Drupal 11 have different architectures, so there is no in-place upgrade. Core's Migrate API, with the Migrate Drupal and Migrate Drupal UI modules, moves data from the old database into a new site that has been set up separately. Everything that is code or configuration rather than data is largely rebuilt. Plan the work on Drupal 11: the two migration modules stay in its core, but Drupal 12 removes them from core as part of its standard deprecation process.

Two things decide most of the budget: the amount of custom code and the number of contributed modules without a modern equivalent. A site built mostly with core and popular modules migrates far more cheaply than one built around custom modules written ten years ago.

How to run the migration

1. Inventory the site. List content types, fields, node counts, enabled modules, custom modules, Views, user roles, integrations and URL patterns. Mark what is still used. Most Drupal 7 sites carry content types and modules nobody needs.
2. Clean up the content model. Merge near-duplicate content types, drop unused fields and decide where Media and Paragraphs replace older patterns. This is the cheapest moment to fix ten years of accumulated structure.
3. Build the Drupal 11 site. Install a fresh Drupal 11 site on PHP 8.3 or later, set up the new content model, build the theme and port or replace custom functionality.
4. Run the migrations repeatedly. Run the content migrations against a copy of the live database, check the results, adjust the mappings and run them again. Each run should be repeatable with one command.
5. Map every URL. Keep URL aliases where possible and create redirects for everything that changes. Compare the old and new sitemaps, and check the pages that bring in the most search traffic.
6. Freeze and migrate the difference. Before launch, run a final migration of content created since the last full run, keep the content freeze short and switch DNS.
7. Watch the first weeks. Monitor 404 errors, search console coverage, form submissions and editor feedback, and fix issues before they turn into lost traffic.

What a Drupal 7 migration costs

These ranges reflect typical projects with an experienced team at Central European rates. Custom code and integrations move a project up the range faster than content volume does.

Moving off Drupal is often cheaper for small sites, because a simpler platform fits them well. For larger platforms it usually costs more, because the content model, permissions and editorial workflows have to be rebuilt in a tool that was not designed around them.

Drupal decisions in .wrk projects

Staying on Drupal: a shared framework for a network of sites

HIMSS, a US non-profit focused on healthcare technology, runs several healthcare media sites, including Health Care IT News and MobiHealthNews, each with about 50,000 daily users. .wrk built a shared Drupal framework in a separate repository, with CSS naming conventions that let developers extend it safely and documentation kept in step with every change. Annual redesigns that used to take months of team effort now take one developer one week, and redesign costs fell 10–12 times. For multi-site organizations like this one, staying on Drupal keeps that shared foundation. Read the HIMSS case study.

Securing a Drupal 7 site while the business grows

Connell Guides, a UK publisher of study guides, ran its subscription site on Drupal 7, built by an earlier vendor. Spam registrations and cross-site scripting threatened the business. .wrk ran a security-first sprint, updated core and modules, rebuilt the layouts to be responsive and set up subscription permissions. The project came in 18% under budget, and the bounce rate fell to about 4%. Work like this keeps a Drupal 7 site safe while a migration is planned, and the cleanup makes the later migration cheaper. Read the Connell Guides case study.

A long-lived Drupal 7 platform with a million users

For a New York education company, .wrk built a subscription platform on Drupal 7 in 2017, with an editor admin panel, subscription and newsletter integrations and a teacher-facing portal. It grew to over a million users and made a six-figure net profit in its first year. Platforms like this carry the hardest migration questions: subscriptions, user accounts, years of editorial content and integrations that cannot stop working for a day. Read the EdTech platform case study.

Moving off Drupal step by step

A Canadian healthcare startup ran its patient platform on Drupal 6, which could not meet the security and feature demands of insurance partners. .wrk rebuilt the core services as Symfony microservices and restricted the legacy Drupal to admin-only functions that auditors could isolate, which supported SOC 2 Type 2 certification. API calls became about five times faster, and monthly outages stopped after the infrastructure upgrade. The move happened in stages, with Drupal shrinking over time instead of being switched off on one day. Read the healthcare platform case study.

Mistakes that make migrations expensive

• Migrating to Drupal 10 in late 2026. It means a second upgrade almost immediately.
• Waiting for Drupal 12. The core migration modules leave core, so the move gets harder.
• Porting everything. Unused content types, fields and modules add cost without adding value.
• Skipping the redirect map. Lost URLs cost search traffic that can take months to recover.
• One big migration run. Repeatable migrations, tested many times before launch, catch data problems early.
• Treating extended support as the plan. Patches buy time, and the time needs an end date.

Our article on legacy system modernization covers the wider choice between refactoring, replatforming and rebuilding. If you plan to bring in an outside team for the migration, our guide on how to outsource software development covers the selection and contract steps.