What a Drupal 7 to Drupal 11 migration involves
A Drupal 6 or 7 site cannot be updated in place to Drupal 10 or 11. Drupal.org documentation describes the work as a migration into a new Drupal site, carried out with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush. Content, users, files and the parts of configuration that map across are moved by migration definitions, while the theme must be rebuilt because Drupal 7 themes cannot be migrated. Plan for the theme as a separate build stream, not a by-product of the content move.
The usual trigger is that Drupal 7 security support ended on January 5, 2025, according to Drupal.org. A site that has moved to an extended security support provider, such as one of the vendors listed by the Drupal Association's Extended Security Support Provider Program, has bought time but not an exemption. Confirm the end date of that contract with the provider and treat it as the migration deadline, not the date you hope to finish.
Teams with recent Drupal 8 or later experience and a small, well-documented site, with few contributed modules and simple content, can often run the migration themselves. A partner is usually worth the cost when the site has many custom modules, complex content relationships, multiple languages or compliance obligations. In those cases the audit of modules without migration paths and the cutover plan, including content freeze and DNS switch, are where an outside team tends to reduce risk. Ask any partner to show how the audit output feeds the scope.
What the work includes and what you receive
A Drupal 7 to Drupal 11 migration runs as a sequence of work packages, each ending in a deliverable you keep. The cards below show what is done, what you receive, and what to check before signing off.
Content and configuration audit
We inventory content types, fields, taxonomies, users, roles, permissions, text formats, Views and every contributed module in use on the Drupal 7 site. The audit report is the baseline for scope, so confirm it lists the custom code and the Views that pages depend on, not only the content.
Module disposition list
Each module on the source site is marked keep, replace, rebuild or drop. Modules without a Drupal 11 equivalent or migration path are the main schedule risk, so ask for the reason behind every replace or rebuild entry and confirm the owner of each decision.
Target design on Drupal 11
The target site is designed on Drupal 11, which requires PHP 8.3 or later, so the hosting platform must be confirmed for that runtime before build starts. The design covers content model, roles, text formats and the contributed modules selected in the disposition list.
Migration mappings and scripts
Source-to-target field and entity mappings are built with the core Migrate modules or Drush and kept in version control. Ask how custom source plugins are tested and how mappings handle fields whose types changed between Drupal 7 and Drupal 11.
Theme rebuild in Twig
Drupal 7 themes cannot be migrated, so the front end is rebuilt as a Drupal 11 theme using Twig templates. Confirm which page templates, components and responsive behaviors are in scope and who signs off visual parity.
Test migrations on production copies
Repeated trial runs execute against copies of production data so that errors surface before cutover. Ask for the number of trial runs included in the fixed scope and how timing, failed rows and rerun behavior are recorded for each run.
Reconciliation report
The reconciliation report compares source and target counts for nodes, users, terms, files and other migrated entities, with exceptions explained row by row. Require it for every trial run and for the final migration, since counts alone do not prove that field values carried over correctly.
Redirect and URL mapping
A URL map links each Drupal 7 path and alias to its Drupal 11 destination, so search rankings, bookmarks and inbound links keep working. Check that the redirect rules are tested against a list of high-traffic legacy URLs before cutover.
Cutover and rollback plan
The cutover runbook lists the freeze window, final migration steps, DNS or load balancer changes, verification checks and the rollback trigger with its procedure. Ask who holds authority to call a rollback and how long the Drupal 7 site stays available for it.
Handover documentation and support
Handover covers the migration code, runbooks, environment details and the post-launch support period, with any ongoing retainer defined separately. Confirm the documentation is in your repositories and that your own team can rerun the migration and maintain the modules afterward.
What drives cost and duration
This table lists the factors that change cost and duration in a Drupal 7 to Drupal 11 migration, why each one matters and how to limit it, and because cost is set by the written scope, the table gives no fixed figures.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Contributed modules without a Drupal 11 path | Each module that needs replacing, reworking or a custom port adds design, build and test effort. | Inventory every module, check its Drupal 11 release status, and choose a maintained replacement early. |
| Custom modules using Drupal 7 APIs | Hooks and procedural code that changed in later core versions must be rewritten and retested. | Keep custom code small, document its behavior, and remove features nobody uses before migration. |
| Content types, fields and paragraph-like structures | Each content type, field and nested structure needs a mapping, a migration definition and validation. | Consolidate redundant content types and fields during the audit, and agree the target model in writing first. |
| Content volume, revisions and URL redirects | Node count, revision history and attachments drive run time, storage and reconciliation checks, and redirect volume drives routing work. | Decide which old revisions to keep, archive stale content, and limit redirects to pages that still receive traffic. |
| Theme rebuild and page templates | Drupal 7 themes cannot be migrated, so each template and component is rebuilt in the new theme layer. | Reuse a base theme or existing components where they fit, and reduce the number of page templates in scope. |
| Multilingual content | Each language, translation set and translation workflow adds mapping, testing and editorial review effort. | Confirm which languages and translated fields must move, and retire unused translations before migration. |
| Integrations, data feeds and external services | Each API, feed or import needs a rebuilt connector, credentials and test data on the new platform. | List every feed with its owner and status, and remove feeds that no longer serve a purpose. |
| User accounts, roles and SSO requirements | Role mapping, password handling and SAML or OpenID Connect sign-in require design decisions and identity testing. | Map Drupal 7 roles to a short target list, and confirm the identity provider details before the build starts. |
| Hosting target, environments and compliance evidence | Kubernetes, air-gapped networks, the PHP 8.3 minimum for Drupal 11, and evidence requests each add setup and documentation work. | Confirm the hosting target and environment count early, and agree the evidence list in the written scope. |
Project phases and outputs
The phases run in a fixed order so that each one hands a checked output to the next, from inventory through cutover to a stabilized Drupal 11 site.
Audit the Drupal 7 site and inventory
We inventory the site's content types, fields, views, users, files, contributed modules, themes and data volumes, then classify each module as replaced by core, replaced by a maintained contributed module, rebuilt as custom code, or dropped. The output is a written inventory and a module disposition list that your content owners and our team both sign off before design starts.
Decide target architecture and content model
We set the Drupal 11 starting point, either bare core or Drupal CMS, and map the Drupal 7 content model to the target content types, fields, taxonomy, roles and workflows. Starting point and content model are covered in the sibling pages on implementation and Drupal CMS, so this step records only the decisions that affect migration. The output is an approved architecture and content model document with the mapping table.
Build the new site and custom code
We set up the Drupal 11 codebase with Composer, install the chosen contributed modules, and build custom modules for functionality without a maintained equivalent. Migration mappings are written alongside the build so that the content model is tested as it is created. The output is a version-controlled codebase that installs cleanly on a supported PHP version and passes the agreed automated checks.
Rebuild the theme
Drupal 7 themes cannot be migrated, so we rebuild the front end in the Drupal 11 theme system and carry over the design, templates and accessibility requirements from the approved inventory. Content owners review the templates on representative pages. The output is a theme approved for the content types and layouts in scope.
Rehearse migration and reconcile data
We run the core Migrate modules or Drush migrations repeatedly against copies of production data, not the live site. Each run is reconciled by comparing record counts, node and file totals, user and role counts, and sampled content against the source. The output is a rehearsal report that lists every mismatch, its cause and its fix, and a repeatable migration script.
Run user acceptance testing with content owners
Content owners test the migrated content, editorial workflows, forms, search and integrations against written acceptance criteria. Defects are logged, fixed and retested in the rehearsal environment. The output is signed acceptance from the named content owners and a closed defect list.
Review security and harden the site
We review roles and permissions, file system and settings protection, trusted host patterns, authentication, and the dependency list against Drupal Security Team advisories. Findings are fixed before launch and recorded. The output is a hardening report with each finding closed or accepted in writing.
Cut over with freeze, delta and redirects
We freeze editing on the Drupal 7 site, run a final migration of content changed since the last rehearsal, confirm reconciliation totals, switch DNS or the load balancer, and activate redirects from old URLs to new ones. Post-launch stabilization then covers monitoring, defect triage and handover of runbooks. The output is a launched site with a checked redirect map and a documented rollback path.
What to keep in-house and what to outsource
This table shows who usually owns each part of a Drupal 7 to Drupal 11 migration, the skills each part needs, and where the split tends to fall for teams without recent Drupal migration experience.
| Work part | Usual owner | Skills needed |
|---|---|---|
| Content and editorial workflow decisions | Keep in-house. Your content owners decide what moves, merges or retires. | Editorial process knowledge, content governance, sign-off authority |
| Contributed module disposition | Shared. Your team decides keep, replace or drop, with outside input on migration paths. | Drupal module ecosystem knowledge, mapping of business requirements to modules |
| Content inventory and cleanup | Shared. Content owners approve cleanup, while the build team produces counts and reports. | Drupal 7 database structure, content auditing, data analysis |
| Migration scripting in PHP and Drush | Outsource. The build team writes migrations and runs test loads. | PHP 8.3, Drush, core Migrate API, Drupal 7 field mapping |
| Drupal 11 custom module development | Outsource. Custom Drupal 7 code is rebuilt as Drupal 11 modules. | Drupal 11 APIs, hooks and services, PHP unit testing |
| Theme rebuild in Twig and CSS | Outsource. Drupal 7 themes cannot be migrated and must be rebuilt. | Twig, CSS, accessibility testing, Drupal theme layers |
| Environment, infrastructure and security review | Shared. Your platform team owns hosting, while the outside team hardens and reviews. | PHP 8.3 runtime, Apache or Nginx, MariaDB, MySQL or PostgreSQL, Security Team advisories |
| Cutover and rollback execution | Outsource, with your sign-off. Freeze, final sync and rollback steps are rehearsed first. | Deployment runbooks, DNS and TLS changes, database backup and restore |
| Post-launch support | Keep in-house or retain. Decide whether your team or a support retainer handles fixes. | Monitoring, bugfix and security release handling, incident response |
What usually goes wrong and how to prevent it
Most failed Drupal 7 to Drupal 11 migrations trace back to decisions made late or never tested. Treat extended security support as a bridge, and set a dated plan for Drupal 12 (scheduled for the week of December 7, 2026, requiring PHP 8.5) from the start.
Contributed modules with no Drupal 11 path
Some Drupal 7 contributed modules have no Drupal 11 release or no migration path, and teams often discover this late. Build a module inventory during discovery that lists every contributed project, its Drupal 11 status, and whether a maintained replacement or core feature covers the same need. Confirm each decision with the project page or maintainer before the build begins.
Custom code built on Drupal 7 APIs
Custom modules that use Drupal 7 hooks, procedural database calls and retired functions must be rewritten for Drupal 11 services, plugins and the current database layer. Scope this from a code inventory agreed with the team that owns the code, then run deprecation checks against the target version. Ask any proposal to list each custom module, its dependencies and its test coverage.
Silent data loss in fields and revisions
A migration can finish without errors while content is wrong. Field storage has changed, text format mappings differ, and revisions and translations may not carry over as the team expects. Reconcile record counts per content type, language and revision against the source, then spot-check rendered pages for formatting, embedded media and internal links.
Theme rebuild scoped as a reskin
Drupal 7 themes cannot be migrated, so templates, preprocess logic, layouts and responsive behavior are rebuilt for the target theme system. Budgets that treat this as a visual refresh often miss navigation, search, forms and editorial previews. Inventory every template, view and form, and agree which page types are designed, approved and tested before cutover.
Redirect gaps that erase search visibility
New URL patterns, aliases and node paths can break inbound links and search rankings at cutover. Map every indexed Drupal 7 path to a target, including taxonomy terms, files and paginated listings, and load that map as redirects. Test a sample of old URLs from analytics and search data on staging before go-live.
Cutover without rehearsal, rollback or sign-off
A cutover that has never been rehearsed usually fails on the first live run. Repeat the full migration on fresh copies of production data, time each step, and write a rollback procedure covering the database, files and DNS. Name one content owner who signs off reconciliation results, and confirm with hosting that the target runs PHP 8.3 or later, as Drupal 11 requires.
How the work differs by starting point
A site with few contributed modules and a simple theme is the most direct case. The audit is short, and most of the effort goes into rebuilding the theme and checking migrated content.
- Audit: inventory every enabled module and confirm that each has a Drupal 11 equivalent, a core replacement or a planned retirement.
- Migration method: the core Migrate modules or Drush can carry content, users and configuration into a new site. The theme is rebuilt separately because Drupal 6 and 7 themes cannot be migrated.
- Cutover: a short content freeze and one final incremental migration may be enough. Ask the partner to state the freeze window in the written scope.
- Confirm: check whether each contributed module's maintainer has released Drupal 11 support, and confirm that the hosting platform provides PHP 8.3 or later.
Heavy custom code and several languages widen the audit considerably. Each custom module needs a decision, and translations must be mapped before content moves.
- Audit: list every custom module, hook and plugin, then classify each as rewrite, port or retire. The migration tools do not carry custom code forward.
- Migration method: plan content migrations per entity type and per language, and confirm that each translation links to the correct source entity on the Drupal 11 side.
- Cutover: run repeated test migrations against a copy of production until translation counts and URL patterns match the source. The freeze window often depends on translation volume.
- Confirm: ask who will own translation workflows after launch, and whether the test plan covers the URL pattern of every language.
A site already enrolled with an extended security support provider needs security patches while the migration runs. The plan then has two tracks: the bridge that keeps Drupal 7 patched, and the new Drupal 11 build.
- Audit: record which core and contributed projects the provider covers, so the team knows which Drupal 7 code may still change during the project.
- Migration method: build the new site as normal. Do not copy bridge patches into the Drupal 11 codebase, because the migration has to be reviewed on its own.
- Cutover: keep the bridged Drupal 7 site online until cutover, and retire it only after the provider confirms the end of coverage in writing.
- Confirm: with HeroDevs or Tag1 Consulting, confirm the covered projects, the delivery method for patches and the end date of the agreement. Also check the current listing in the Drupal Association's Extended Security Support Provider Program.
A site hosted on Kubernetes or on servers in a private data center changes the build and the cutover, because the platform team controls images, storage and the network path.
- Audit: record the PHP version, web server (Apache or Nginx) and database (MariaDB, MySQL, PostgreSQL or SQLite) that the platform supports, and check each against Drupal 11 requirements.
- Migration method: run the Drupal 11 site as a separate deployment with its own database. Keep the Drupal 7 deployment reachable as a read source during the migration.
- Cutover: plan the DNS or ingress switch, the sync of uploaded public files and the rollback steps. On Kubernetes, confirm how persistent volumes for public files are mounted in both deployments.
- Confirm: ask whether the platform team's image includes the PHP extensions Drupal 11 needs, and who owns the database backup schedule during cutover.
In an air-gapped network, Composer packages, contributed modules and security updates must be mirrored in advance. The site cannot reach Drupal.org during the build or after go-live.
- Audit: list every contributed module and its dependencies, then mirror them with their metadata before build work starts.
- Migration method: host the dependencies in an internal package repository so the Migrate modules and Drush run without internet access.
- Cutover: move data through the approved transfer channel. Confirm the approval steps and transfer limits with the security team before the freeze.
- Operations: Drupal Security Team advisories arrive in Wednesday security windows, so the internal mirror needs a planned process for bringing each patch inside.
- Confirm: ask the bridge provider whether patches can be delivered into an offline network, and in what format.
What you need to provide before work starts
The migration cannot be scoped until your team hands over the Drupal 7 source, data and environment details, and names who decides what the new site looks like. Start with read-only access to the Drupal 7 codebase, a copy of the production database, the files directory and the current environment details, including web server, PHP version and database engine. Add a list of every contributed and custom module with its installed version, because modules without a Drupal 10 or 11 successor change the plan more than anything else.
Name three decision makers before kickoff: a content owner who understands the editorial model, an approver who signs off each migration phase, and a technical contact who can answer questions about the existing code. Decisions still open at that point usually concern content model changes, URL structure and the redirect map that keeps existing links working. Ask for written decisions on each, because Drupal 11 does not carry the Drupal 7 content model forward automatically. Also confirm the DNS, certificate and target hosting access needed for staging and cutover, and the identity provider details if single sign-on is in scope.
If your organization must meet a compliance framework, list the requirements and name an evidence owner for each control area before work starts. DeployOpen prepares systems, configuration and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations, so confirm early which evidence they will require. Finally, agree a cutover window with the business owners, since the window sets when the final content sync, redirect activation and rollback plan are rehearsed.
Questions buyers ask before hiring help
Can a Drupal 7 site be upgraded in place to Drupal 11?
No. Drupal 7 cannot be updated in place to Drupal 11, because Drupal.org documentation says Drupal 6 and 7 sites are migrated into a new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or with Drush. Content, files and users are mapped into a fresh Drupal 11 installation. Themes cannot be migrated, so they must be rebuilt. The cutover plan has to cover the content transfer, the new front end, and the DNS and redirect work at the end of the project.
Can our own team migrate a Drupal 7 site to Drupal 11?
Yes, a team with Drupal and PHP skills can do it with the core Migrate modules or Drush, but the hard parts decide whether the project stays on schedule. The difficult areas are usually the content model mapping, contributed modules that have no migration path, custom code written against Drupal 7 APIs, and the theme rebuild. Ask your team to audit those four areas first, then decide which parts to keep in house and which to scope to a partner in writing.
How much does it cost and how long does it take to migrate?
Cost follows the written scope, and DeployOpen does not publish a price list. Drupal has no license fee, since Drupal.org licenses core and derivative contributed projects under GPL-2.0-or-later, so a quote covers labor and testing. The main drivers are the number of content types and fields to map, the contributed modules and custom code to disposition, the theme rebuild and integrations. Duration follows the same audit findings, and the written plan sets the schedule. Ask each quote to separate one-time migration work from recurring hosting and support.
What happens to our contributed modules during a Drupal 7 migration?
Each contributed module is dispositioned as keep, replace, rebuild or drop. Keep means a Drupal 11 compatible release exists and the module can be installed and tested. Replace means a maintained alternative covers the same need. Rebuild means custom code is written where no migration path exists. Drop means the site no longer needs the feature. Check each module's Drupal 11 status on its project page before the audit closes, because modules without a migration path need an early decision.
Is extended security support a valid option for Drupal 7?
Extended support is a stopgap from providers listed in the Drupal Association's Extended Security Support Provider Program, which lists HeroDevs and Tag1 Consulting as certified vendors. It keeps a Drupal 7 site receiving security patches while the migration is planned. It does not move the site to a supported version or change its PHP platform. Use it to buy time for the cutover, and budget the migration as a separate project. Confirm current terms, coverage and duration directly with any provider before signing.
What changes with Drupal 12 for our migration target?
Drupal 12 is scheduled for the week of December 7, 2026, and it requires PHP 8.5 or later, so the target version should be chosen with that in mind. Drupal 11 requires PHP 8.3 or later, and Drupal 10 reaches end of life on December 9, 2026. Pick a target your hosting can run now, confirm its PHP upgrade path, and plan the next major version upgrade after launch, since major versions typically arrive every three years.
How DeployOpen scopes and delivers this migration
DeployOpen plans and delivers Drupal 7 to Drupal 11 migrations as fixed-scope projects inside infrastructure you control. The work moves content and configuration into a new Drupal site, rebuilds the theme, and is documented and handed over to your team.
How we scope
- Audit content types, fields, views, users and contributed modules on the Drupal 7 site before any build starts.
- Identify contributed modules that have no migration path and agree on a replacement, custom code or removal for each.
- Record the scope, deliverables and timelines in writing, with a quote that follows from that written scope.
How we build
- Map Drupal 7 content into the new site with the core Migrate, Migrate Drupal and Migrate Drupal UI modules or Drush.
- Rebuild the theme on the newer Drupal version, since Drupal 7 themes cannot be migrated and must be rebuilt.
- Test migrated content, URLs, users and permissions in a staging environment, then rehearse the cutover before go-live.
How we hand over
- Document the content mapping, module decisions, configuration and deployment steps so your team can maintain the site.
- Provide a cutover runbook covering DNS, redirects, backups and rollback steps agreed with your operations team.
- Walk your administrators and developers through the new site and the handover documentation before closing the project.
How we support
- Offer ongoing support, upgrades and security monitoring as a retainer after the migration is complete.
- Plan the path from Drupal 11 onward, including PHP version requirements and the scheduled Drupal 12 release.
- Confirm with your team which support level, release window responsibilities and access model apply after handover.
