Drupal 7 migration: the complete guide to moving to Drupal 11

Many websites still run on Drupal 7, more than a decade after it came out. Moving such a site to a current Drupal version is not an update but a migration: you build a new Drupal 11 site and move the content, users and files into it. This guide covers where Drupal 7 stands today, what Drupal 11 gives you, how to plan and budget the move, a checklist, and what to do after launch.

Where Drupal 7 stands in 2026

Drupal 7 reached end of life on 5 January 2025. Since then the Drupal Security Team publishes no security advisories or fixes for Drupal 7 core or its contributed modules, and module maintainers have moved on to newer versions. Drupal.org lists the options for sites still on it on its Drupal 7 end-of-life page, including paid extended security support from certified vendors. Extended support buys time, but it keeps an old platform running instead of moving you forward.

Two dates at the end of 2026 settle where to go next. Drupal 10 reaches end of life on 9 December 2026, and Drupal 12 is planned for the week of 7 December 2026, according to the Drupal core release schedule. The Migrate Drupal and Migrate Drupal UI modules, which import Drupal 6 and 7 sites, are deprecated in Drupal 11 and will not be included in Drupal 12 (Migrate Drupal documentation). So the target for a Drupal 7 site is Drupal 11: it is the last version with the Drupal 7 migration path in core, and moving on to Drupal 12 later is a regular update.

Why not Drupal 10?

Drupal 10 is supported only until 9 December 2026, so a site migrated to it would need another major update straight away. Migrate to Drupal 11 directly; there is no need to pass through Drupal 8, 9 or 10.

The cost of staying on Drupal 7

• Security. Every new vulnerability in Drupal 7 core, its modules or its libraries stays open unless you pay for extended support or patch it yourself. Security scanners and procurement checks flag unsupported software.
• Hosting. Many Drupal 7 modules do not run on current PHP versions, and hosting providers retire the old ones.
• Integrations. Payment, CRM and marketing services change their APIs, and a Drupal 7 module that nobody maintains stops working when the API it talks to changes.
• People. Fewer developers work with Drupal 7 every year, so changes and fixes take longer and cost more.

The longer a site stays on Drupal 7, the more of its budget goes into keeping it alive instead of improving it.

What you get with Drupal 11

Drupal 8 rebuilt Drupal on modern foundations, and Drupal 9, 10 and 11 continued from there, so a Drupal 7 site that moves to Drupal 11 gains ten years of improvements at once. For the details of the current version, see our overview of Drupal 11.

• Updates instead of migrations. Since Drupal 8, a new major version mostly removes code that was deprecated before, so a site that keeps up with minor releases updates without a rebuild. Minor releases come out twice a year. After this migration, moving to Drupal 12 and later versions is planned maintenance, not another migration.
• A modern PHP stack. Drupal 11 runs on Symfony 7 and PHP 8.3 or later, and the project and its modules are managed with Composer.
• Faster pages. The render cache with cache tags and contexts, the Dynamic Page Cache and BigPipe serve pages faster and clear only what changed, where Drupal 7 often cleared whole caches.
• Better editing. CKEditor 5, the Claro admin theme, the Media Library, Layout Builder and content moderation are in core. Drupal CMS 2.0, released in January 2026, adds the Drupal Canvas visual page builder and site templates on top of Drupal 11.
• Configuration as code. Content types, fields, views and settings are exported to YAML files, versioned with the code and deployed from development to production. Modules such as Config Split and Config Ignore handle settings that differ between environments.
• A modern front end. Themes use Twig templates and Single Directory Components, and JSON:API in core lets you run Drupal headless with a front end such as Next.js.
• Accessibility and languages. The default themes, Olivero and Claro, were built to meet WCAG AA, and multilingual support is in core instead of a set of contributed modules.

Migrate as it is, improve, or rebuild

Drupal 7 and Drupal 11 are different systems: Drupal 7 modules and themes do not run on Drupal 11. Whatever the approach, you build a new Drupal 11 site and move the content into it with Drupal's Migrate API. What changes is how much of the old site you keep.

• Like for like. The same content model, features and design, rebuilt on Drupal 11. The quickest route when the site does its job and the budget is tight.
• Migrate and improve. Keep the content, but use the move to drop unused content types and modules, simplify editing and refresh the design. Often the best value, because a Drupal 7 site usually carries years of features nobody uses any more.
• Rebuild and import. Design a new site, for example starting from Drupal CMS, and import only the content worth keeping. The right choice when the old structure no longer fits the business.

Plan the migration

1. Take inventory of the Drupal 7 site

Document everything the site does before deciding what to move: core, contributed and custom modules; content types and their fields; taxonomies, views, blocks and menus; users, roles and permissions; files and media; languages; forms; integrations with CRM, payment, search or single sign-on; and custom code in the theme. Add the list of URLs and each page's traffic from your analytics, so you can see what people actually use. The inventory becomes the checklist the new site is tested against.

2. Map every module to Drupal 11

For each module, decide where its job goes. Much of what needed contributed modules in Drupal 7 is now in core: Views, CKEditor, Media, entity references, date, link and email fields, and multilingual support. Many popular modules, such as Webform, Metatag, Pathauto and Redirect, have Drupal 11 versions that can import their Drupal 7 data. Others have successors: Field Collection content usually moves to Paragraphs, Features gives way to configuration management, and Panels pages are rebuilt with Layout Builder. What is left needs a replacement module or custom code.

Custom modules and the theme have to be rewritten. Drupal 7 code is procedural and its themes use PHPTemplate, while Drupal 11 uses object-oriented PHP, services, plugins and Twig. Tools like Drupal Rector help with updates between Drupal 8 and later versions, but they cannot convert Drupal 7 code. Order this work by business value: the features the site cannot launch without first, the nice-to-haves later.

3. Plan the content migration

The Migrate API in core, with the contributed Migrate Plus, Migrate Tools and Migrate Upgrade modules, reads the Drupal 7 database and files and writes them into the new site. Map each old content type and field to the new content model; this is where restructuring happens. User accounts can be migrated with their password hashes, so people keep their logins. Run the migrations again and again during development and compare the numbers of content items, users and files with the old site. Because migrations can be rerun and update what they imported, the old site stays live while the new one is built, and the content freeze before launch lasts only as long as the final run.

4. Budget time and people

The effort depends on the number of content types and fields, contributed modules without a Drupal 11 equivalent, custom modules, integrations and languages, and on how much the design changes. A small brochure site can move in a few weeks; a large site with custom features, integrations and several languages takes several months. Budget for developers, but also for testing, content checks by editors and training. Keep a buffer for surprises: an old site always holds some forgotten feature that someone relies on.

5. Protect your search rankings

A migration is the moment a site can lose years of search traffic, mostly through changed URLs. Crawl the Drupal 7 site and export its URLs before you start. Keep the same URLs where you can: path aliases and Pathauto patterns migrate. Every URL that changes needs a 301 redirect to its new address, and existing redirects from the Redirect module can be migrated too. Bring over page titles and meta descriptions with Metatag, rebuild the XML sitemap, and check the new site for broken links before launch. Our article on SEO tactics for Drupal websites covers the modules involved.

6. Test, and keep a way back

Test the new site against the inventory: features and workflows, forms and integrations, content and media, design on different devices and browsers, accessibility, performance under load, and security. Let editors work in it before launch. Keep backups of the Drupal 7 site, its database and files, and write down the steps for switching back, including DNS, until the new site has run without problems for a few weeks.

Drupal 7 to Drupal 11 migration checklist

• Inventory modules, content types, fields, views, users and roles, files, languages, integrations and custom code.
• Export the list of URLs and their traffic.
• Choose the approach: like for like, migrate and improve, or rebuild and import.
• Map every module to core, a Drupal 11 module, a replacement or custom code.
• Set up the Drupal 11 project with Composer, on hosting with PHP 8.3 or later.
• Build the content model, the theme and the custom modules.
• Write the migrations, run them repeatedly and compare the numbers with the old site.
• Plan a 301 redirect for every URL that changes.
• Test features, content, design, accessibility, performance and security.
• Train the editors.
• Freeze content, run the final migration and launch.
• Monitor 404 errors, Search Console and performance after launch.
• Keep the Drupal 7 backups until the new site is stable.

After launch

Watch the first weeks closely: 404 errors and redirects, Search Console's indexing and performance reports, page speed, and feedback from editors. Then set up a maintenance routine: apply security releases when they come out, update to each new minor version, and remove deprecated code as you go, so that moving to Drupal 12 stays a small step. If you would rather not do this in house, our Drupal support and maintenance team can take it over.

Choosing a Drupal migration partner

Look for a team that has migrated Drupal 7 sites before and can show it, works with Drupal 11 every day, and stays for support after launch. Ask how they handle content mapping, redirects and testing, and who your contact will be. Bulcode's Acquia-certified Drupal developers plan and run migrations end to end, from the first inventory to launch; see our Drupal migration services.