Migration from Drupal 7 to Drupal 11: The Complete Guide

Drupal 7 was launched in 2011 and enabled many institutional, corporate, media, and portal websites to operate for over a decade. But this version is now obsolete.

Since January 5, 2025, Drupal 7 no longer receives security updates from the Drupal project. Continuing to run a Drupal 7 site therefore exposes the organization to several issues:

• an increased security risk, since vulnerabilities in Drupal 7 core, modules, and themes are no longer fixed by the Drupal security team;
• compatibility issues, especially with recent versions of PHP, libraries, and third-party services;
• more complex maintenance, as the Drupal 7 ecosystem is gradually being abandoned;
• difficulties evolving the site, particularly when legacy modules or features no longer have a maintained equivalent;
• growing technical debt, which can make a future migration longer and more expensive.

The end of life of Drupal 7 is therefore above all an opportunity to overhaul a site that has sometimes evolved significantly since its launch.

Yes, but we should talk about migration rather than simply upgrading.

A Drupal 7 site cannot be treated like a Drupal 10 site that you would just update to Drupal 11. Thearchitectural gap between Drupal 7 and modern versions of Drupal involves having to rebuild part of the project and migrate the data to the new site.

Drupal offers tools and migration mechanisms that allow you to transfer content, users, files, and certain configuration data from a Drupal 7 site. But each project must be analyzed individually: the installed modules, custom developments, and data structure can significantly affect the scope of migration.

That is why a Drupal 7 to Drupal 11 migration project generally starts with a complete audit of the existing site.

A successful migration relies on a structured methodology. At bluedrop.fr, we generally organize the project around several steps.

1. Audit the Drupal 7 site

Before developing anything, we start by precisely understanding the existing site.

The audit focuses in particular on:

• the content types;
• the fields and their relationships;
• the taxonomies;
• the users, roles, and permissions;
• the media and files;
• the views and listings;
• the contributed modules;
• the custom modules and developments;
• the theme and templates;
• the forms;
• the search engines;
• the connections with external services or applications;
• the performance;
• the accessibility;
• the SEO;
• the hosting infrastructure.

This mapping allows us to distinguish what needs to be migrated as is, adapted, replaced, or abandoned.

It also makes it possible to identify features that are no longer needed and those that could be improved on the new site.

For example, when migrating from Drupal 7 to Drupal 10 the IRP AUTO site, the social protection group for automotive professionals, we made slight graphic improvements to better match the brand guidelines, thus enhancing brand recognition.

2. Define the migration strategy

A Drupal 7 migration does not necessarily have to exactly replicate the existing site.

Moving to Drupal 11 can be an opportunity to:

• simplify the content model;
• revamp the structure;
• improve user journeys ;
• modernize the interface ;
• enhance accessibility ;
• optimize performance ;
• revise the search engine ;
• streamline the modules ;
• improve the contributors' experience ;
• strengthen SEO.

The goal is to find the right balance between preserving what exists and improving the project.

3. Build the new Drupal site

Once the strategy is defined, we set up the new Drupal foundation.

The necessary configurations are either carried over or rebuilt: content types, fields, taxonomies, views, roles, permissions, workflows, media, editorial features...

The Drupal 7 modules are also reviewed individually. A module used on the legacy site can:

• have an equivalent for Drupal 11;
• require a different configuration;
• be replaced by a core Drupal feature;
• be replaced by another contrib module;
• require specific development;
• or no longer be needed.

Migration is therefore also a technical streamlining process.

4. Migrate content and data

Data migration is a central stage of the project.

Depending on the needs, we can migrate editorial content, media, documents, users, taxonomies, relationships between content, some business data, histories or specific information required by the project.

Migration should be automated as much as possible to ensure it is repeatable and testable. Intermediate migrations are run to check data quality before go-live.

5. Rethink or rebuild the theme

Upgrading from Drupal 7 to Drupal 11 usually means reworking the site's theme. This isn't necessarily bad news: it's an opportunity to modernize the interface while maintaining the brand's visual identity.

Depending on the project, we can work on UX/UI design, responsive design, the design system, editorial components, accessibility, front-end performance, and eco-design.

During the migration of IRP AUTO's website, for example, we used the project as an opportunity to slightly evolve the interface to better adhere to the group's graphic charter and strengthen brand recognition.

6. Preserving natural search engine ranking

However, a successful technical migration can become a failure if it causes a significant loss of visibility in search engines. SEO must therefore be integrated into the migration project from the audit phase onward.

We specifically check:

• the existing URLs;
• the ranked content;
• the metadata;
• the title and meta description tags;
• the canonical tags;
• the structured data;
• the internal linking;
• the sitemap files;
• the crawl rules;
• the performance;
• the 404 errors;
• the 301 redirects.

When URLs need to change, we create a redirect plan between the old and new URLs.

After go-live, monitoring errors, indexing, and positions allows us to verify that the migration has not negatively impacted the site's search engine ranking.

For a large project, this phase should be considered a core component of the migration, and not simply a check performed at the end.

7. Testing, user acceptance, and going live

Before launch, the new website goes through several testing phases.

We specifically check business features, forms, user journeys, rights and permissions, migrated content, media, links, redirects, responsiveness, accessibility, performance, SEO, and connections with third-party services.

The migration is then carried out according to a go-live scenario prepared in advance. The goal is to minimize service interruption as much as possible and have a rollback plan in place if necessary.

This is one of the most frequently asked questions during a Drupal 7 migration.

An old site may have accumulated several dozen modules, sometimes essential at the time but no longer maintained or with no direct equivalent in Drupal 11.

You should especially avoid trying to automatically reproduce each module.

For each feature, we look for the most relevant solution instead:

• use a feature now available in Drupal;
• install a contributed module compatible with Drupal 11;
• adapt the existing functionality;
• develop a custom module;
• or remove the feature when it no longer adds value to the project.

This decision-making step is essential to avoid rebuilding in Drupal 11 the technical debt accumulated in Drupal 7.

There is no fixed price for migrating from Drupal 7 to Drupal 11. The budget mainly depends on the complexity of the existing site and of the desired level of progress.

The main factors are:

• the number of items to migrate;
• the complexity of the data model;
• the number of modules;
• the amount of specific development;
• integrations with third-party applications;
• the complexity of the search engine;
• the number of languages;
• the volume of media;
• the complexity of the theme;
• possible UX/UI redesign;
• accessibility requirements;
• SEO challenges;
• the testing and support needs.

A simple Drupal 7 site with little custom development is therefore not the same project as an institutional portal or a highly customized business site.

The best way to estimate the cost of a migration is to start with a technical and functional audit to precisely define the scope.

The duration depends on the same factors as the budget.

A migration from Drupal 7 to Drupal 11 can take a few weeks for a relatively simple site up to several months for a complex project including a lot of content, custom development, integrations, a UX/UI redesign, or strong requirements in terms of SEO and accessibility.

At bluedrop.fr, we specialize in Drupal projects and support organizations in their migrations, redesigns, and growth.

Our expertise covers the entire project: Drupal audits, migration strategy, Drupal development, content and data migration, SEO, hosting, maintenance, and technical support.

We have notably helped organizations migrate Drupal 7 sites to newer versions of Drupal, such as IRP AUTO and Agreenium, as well as on larger migration and redesign projects for groups and institutions like STEF, Elior, the Bordeaux National Opera, Babilou, La Méridionale and the Métropole of Toulon.

Each migration is based on the existing site: we don't simply try to reproduce the Drupal 7 site, but to build a more sustainable, maintainable Drupal project that is better suited to the organization's current needs.

The end of life for Drupal 7 is now effective. If your site still relies on this version, it is best not to wait for a security emergency or a technical impossibility to start your project. Contact us and let’s schedule your technical audit now.