Most engineering teams treat a Drupal migration like a software upgrade. They expect a defined path, a compatibility checklist, and a finish line. That expectation is where the pain starts.
We recently completed a Drupal migration for a high-traffic family media platform: hundreds of thousands of active users, tens of thousands of content items, a Commerce-based subscription stack, and over 20 custom modules built across years of D7 development. The target was Drupal 11, hosted on Pantheon. We delivered with virtually zero downtime.
This post breaks down what that migration actually required, where the real complexity lives, and what D7 teams should know before they start.
Why Drupal 7 to Drupal 11 is not an upgrade. It is a rebuild
Drupal 8 introduced a paradigm shift that many teams still underestimate. The move to Symfony components, a fully object-oriented architecture, and a configuration management system built on YAML was not incremental. It was a replatform disguised as a version bump.
If your application was built on Drupal 7, it has no upgrade path to Drupal 11 in the traditional sense. Every custom module must be rewritten. Your theme does not carry over. Your data model may need to be restructured before migration tooling can even touch it.
The good news: the core migration framework in Drupal 11 is mature. Migrate API, Migrate Plus, and Migrate Tools give you a structured pipeline for moving content, users, and taxonomy from a running D7 source database. But that tooling only handles the data layer. The application layer is yours to rebuild.
For the platform we worked on, that meant:
- Rewriting 20+ custom modules from procedural PHP to Drupal 11's plugin-based, service-oriented architecture
- Rebuilding the entire front-end theme from scratch (Twig, not PHPTemplate)
- Modernizing a Commerce subscription stack to align with Drupal Commerce 2.x patterns
- Configuring a Pantheon-optimized deployment pipeline that could support a high-availability relaunch
None of that is configuration work. All of it is engineering work.
The part that always breaks: custom modules and contrib dependencies
In a greenfield Drupal 11 build, module selection is straightforward. In a D7 migration, you inherit a dependency tree that was assembled over years, often by multiple teams, against a completely different architectural foundation.
On this project, the custom module audit was the first critical gate. We catalogued every module, mapped its functionality, and made a deliberate decision for each one: port it, replace it with a modern equivalent, or deprecate it entirely.
Several modules that had been load-bearing in the D7 site had direct Drupal 11 equivalents that worked differently enough to require data model changes. That cascaded into migration script adjustments. A change in how a field was stored in D7 versus how it needed to be structured in D11 meant writing custom migration process plugins to handle the transformation in transit.
This is the work that blows up timelines on teams that do not account for it upfront. Dependency mapping and module-by-module decision logs are not optional steps. They are the foundation of any realistic project estimate.
What we did differently on this project
Before writing a single line of migration code, we ran a full content audit alongside the module audit. We categorized content types by volume, complexity, and relationship density. The types with the highest relationship complexity got dedicated migration scripts with explicit rollback logic.
We also built a staging migration pipeline early, so the client's editorial team could validate content fidelity on real data before launch. That feedback loop caught field mapping errors that would have been painful to fix post-launch at scale.
Migrating content at scale: what "virtually zero downtime" actually required
Hundreds of thousands of users and tens of thousands of content items is not a volume problem. It is a sequencing problem.
On Pantheon, we used a multi-environment strategy: a dedicated migration environment for iterative dry runs, a staging environment for client validation, and production protected behind a carefully timed cutover window. Each dry run surfaced edge cases in the migration scripts that we resolved before the next run.
By the time we ran the final production migration, we had executed the full pipeline more than a dozen times. The cutover window was short because the process was rehearsed, not because we got lucky.
A few specifics worth noting:
- User account migration required careful handling of Commerce subscription data to preserve billing state and prevent access disruption for paying subscribers
- File migrations were batched and pre-staged to avoid filesystem bottlenecks during cutover
- Redirects from legacy D7 URL patterns to D11 path aliases were generated programmatically and loaded into the CDN layer before the DNS switch
That last point matters more than most teams realize. A major platform migration that breaks thousands of inbound links is not a technical success, regardless of how clean the codebase is.
What D7 teams should assess before starting a migration
If you are running Drupal 7 today, end-of-life is behind you. Official support ended in January 2025. Security patches are no longer guaranteed. The question is not whether to migrate but how to scope it honestly. For more context, see our post on whether you should update Drupal.
Here is the assessment framework we use before scoping any D7 to D11 project:
- Module inventory. How many custom modules exist? What do they do? Can any be replaced with core or contrib functionality in D11?
- Content model complexity. How many content types, fields, and relationships need to migrate? Are there entity references, paragraphs, or nested structures?
- Commerce or membership dependencies. Subscription and commerce logic in D7 often requires significant rearchitecting in D11. Budget for this separately.
- Traffic and uptime requirements. High-traffic sites need rehearsed cutover plans and rollback procedures. Low-traffic sites have more flexibility.
- Theme investment. If the current theme is complex, assume a full rebuild. Do not estimate a port.
Skipping any of these leads to mid-project scope expansion, which is the primary reason Drupal migrations run over budget and timeline.
The honest trade-off: time invested now versus risk carried forward
Drupal 7 sites running without security coverage are a liability. The longer a team waits, the more technical debt compounds, and the more risk sits on infrastructure that no one is actively patching.
The migration we completed was not a small project. It required senior engineering capacity, careful planning, and iterative execution. But the result was a modern, maintainable Drupal 11 platform on a managed hosting stack, with a codebase that can be extended and maintained without fighting legacy architecture every step of the way.
The teams we see struggle most are the ones who underscope the initial estimate to make the project easier to approve. That trade-off almost always reverses itself during execution.
Conclusion
A Drupal migration from D7 to D11 is a rebuild project. The teams that execute it successfully are the ones who treat it that way from day one: auditing dependencies honestly, building rehearsable migration pipelines, and protecting the end user experience through a carefully managed cutover.
weKnow has been executing Drupal migrations and builds since 2009. We are the number one Drupal contributor in Latin America, and our senior engineers have handled migrations at every scale, from small editorial platforms to high-traffic media properties. You can see examples of this work in our project portfolio.
If you are scoping a Drupal migration and want a straight conversation about what it actually takes, reach out at yes@weknowinc.com. We will tell you what the estimate should include, even if it makes the number harder to approve.