Migrating Drupal 7 to 11 without downtime

Drupal 7 reached end of life in January 2025. Most organizations still running it aren't behind because they lack resources — they're behind because every migration approach they've considered feels too risky. The platform is doing real work. It can't go offline for a week while a team rebuilds it.

Here's how we approach D7 → D11 migrations at heydru: treating them as parallel systems, not upgrades.

Why this isn't an upgrade

The instinct is to treat a major version jump as an upgrade — export the database, run some scripts, fix the errors. That works between minor Drupal versions. It does not work between Drupal 7 and Drupal 11.

The underlying architecture is fundamentally different. Drupal 7 uses a hook-based system with procedural PHP. Drupal 8 introduced an object-oriented kernel built on Symfony components, and that foundation has carried through to D11. The content structure, the routing system, the configuration management, the theming layer — all of it changed.

When we take on a D7 migration, the first thing we tell the client is: you are rebuilding your platform, not upgrading it. That reframe matters because it changes how you plan, how you staff, and how you manage risk.

The parallel-run strategy

The safest migration approach we've found is running D7 and D11 in parallel until D11 is ready to take over fully.

Phase 1 — Audit and content modeling

Before writing a single line of new code, we do a complete audit of the D7 site: every content type, every field, every view, every module, every integration. We document what's actually being used versus what was installed and forgotten. Legacy Drupal sites routinely have 80+ contributed modules enabled, and in practice 30% of them are doing nothing useful.

This audit becomes the migration spec. We don't migrate everything — we migrate what matters. That distinction alone has saved clients weeks of work.

Phase 2 — Build D11 in isolation

We stand up the D11 platform in a separate environment, completely decoupled from D7. Same database server, different database. We rebuild content types in D11 using configuration management from the start — no clicking in the UI, everything in YAML. This means the D11 build is fully reproducible from day one.

Custom module code gets rewritten as Drupal 8+ plugins and services. There's no shortcut here, but the new code is substantially cleaner and more testable than most D7 module code.

Phase 3 — Content migration with Drupal's Migrate API

The Migrate API, stable since Drupal 8.1, is the right tool for this. It provides a structured pipeline: source plugins read data from D7, process plugins transform it, destination plugins write it to D11.

// Example: simple node migration source
source:
  plugin: d7_node
  node_type: article
process:
  title: title
  body: body/0/value
  field_category:
    plugin: migration_lookup
    migration: d7_taxonomy_term_tags
    source: field_tags
destination:
  plugin: entity:node
  default_bundle: article

We run migrations iteratively, not once. The first run will expose field mapping issues, missing taxonomies, broken file references. We fix those, wipe the D11 content tables, and run again. By the fifth or sixth iteration the migration runs cleanly in under an hour for most sites.

Phase 4 — Continuous sync

This is the part most teams skip, and it's the most important one. Once D11 content is in good shape, we set up a sync job that runs the migration daily. Every new node, every content update, every taxonomy change in D7 gets migrated to D11 automatically.

This keeps D11 current. It means the cutover isn't a one-time data dump — it's just turning off the sync and flipping DNS.

Phase 5 — The cutover

When D11 has been running in parallel for long enough that the team is confident in it, the cutover is straightforward:

1. Put D7 in maintenance mode
2. Run a final full migration to catch any content updated since the last sync
3. Update DNS to point to D11
4. Monitor for 48 hours
5. Keep D7 accessible internally for one month as a fallback

Total downtime: the time it takes to flip DNS — minutes, not hours, not days.

Common failure modes

Trying to do it all at once. Teams that try to migrate content, rebuild features, upgrade infrastructure, and launch all in one go almost always blow past their timeline. Phase it.

Underestimating custom module rewrites. A 500-line D7 module doesn't become a 500-line D11 module. The concepts are different. Budget more time than you think you need.

Skipping the audit. The client thinks they know what their site does. They are never fully right. The audit always surfaces something — usually a niche feature that two people use and three people have forgotten exists, with no documentation.

Not running migrations repeatedly. Running the migration once early and not touching it again means you'll hit a wall of data issues during the real cutover. Run it weekly at minimum throughout the project.

What a realistic timeline looks like

For a mid-size Drupal 7 site (15–30 content types, 50,000–200,000 nodes, 5–10 custom modules), we typically budget:

• Audit and scoping: 2–3 weeks
• D11 build: 8–16 weeks (varies heavily by custom functionality)
• Migration pipeline development and iteration: 4–6 weeks, running in parallel with build
• User acceptance testing: 3–4 weeks
• Cutover and stabilization: 1–2 weeks

Total: 4–6 months for a well-scoped project. Teams that rush this to 2–3 months usually end up doing a second migration a year later.

The upside

D11 is meaningfully better than D7 in ways that aren't obvious until you're in it. Configuration management makes deployments predictable. The service container makes testing realistic. JSON:API and GraphQL come standard. The performance baseline is higher.

The migration is real work. But the platform you end up with is substantially more maintainable, more secure, and more capable than what you're leaving behind.

If you're still on D7 and trying to figure out where to start, the answer is the audit. Everything else follows from there.