WEBEVRA

The Drupal 7 to Drupal 11 Migration Checklist

A step-by-step audit and execution plan for moving a Drupal 7 site safely to Drupal 11. Written by senior Drupal engineers who run these migrations as a fixed-price productized offer.

Version: 1.0 · May 2026
Audience: Site owners, in-house developers, agency partners
Estimated read: 20 minutes
From: WebEvra LLP · webevra.com · [email protected]

Why this checklist exists

Drupal 7 reached End of Life on January 5, 2025. The community no longer issues security advisories. Hosts are deprecating the PHP versions D7 needs. Contributed modules are dropping their D7 branches. If your site is still on Drupal 7 in 2026, every month is a compounding risk.

You have three real options: stay on D7 with extended commercial security support and pay forever; rebuild on a different CMS and lose institutional knowledge encoded in your content model; or migrate to Drupal 11 and keep what works while shedding what does not. This document is for the third option.

It is the same internal checklist WebEvra works through on every D7-to-D11 engagement. Use it to estimate your own scope, brief an internal team, or evaluate proposals from agencies. If you would rather hand the whole thing to a senior team and get a fixed-price quote, the cover page has our address.

Phase 1 · Pre-flight (Week 0)

Before any migration code runs. The point of this phase is to fail early on the cheap things.

Get current on D7 patches first. The latest D7 patch release (7.103+ as of early 2026) closes the public security gaps. Migrating from a stale D7 multiplies the surface area you have to defend during cutover.
Take three backups. Database (full SQL dump, compressed), files directory (sites/default/files plus any private file path), and a Git snapshot of code+config. Store off-host.
Document third-party integrations. Any service the site talks to (payment gateway, CRM, marketing automation, analytics, search, email). For each, note: where the credential lives, what triggers a call, what breaks if the call fails.
Inventory hosting. PHP version, database engine and version, filesystem layout, deploy mechanism, cron source, SSL certificate handling, CDN if any. Drupal 11 needs PHP 8.3+ and MySQL 8.0+ or MariaDB 10.6+. If your current host can't provide that, the hosting decision is part of the migration.
Get traffic baseline metrics. Page views, top pages, top referrers, slowest pages, error rate. You will use these to verify nothing regressed after cutover.

Phase 2 · Module audit (Week 1)

This is where most migrations go off-rails. Modules carry the business logic. Some have direct D11 paths, some need a swap, some need to be rewritten.

Get the full enabled-module list. drush pml --status=enabled. Export to a spreadsheet. Add columns: D11 status, replacement, owner, decision.
Check D11 status for each contrib module. Visit drupal.org/project/[name] and look for an 11.x branch. If there is one, it is usually a clean port. If not, search issues for "Drupal 11" or "Drupal 10" support to find the state of the work.
Identify modules with no D11 path. Three sub-cases:
- Functionality is now in core. Many D7 contrib modules (Date, Entity Reference, Views) are core in modern Drupal. You drop the module and migrate the data.
- Replacement module exists. Common: address replaces addressfield; paragraphs often replaces field_collection; commerce 2.x replaces commerce 1.x with substantial schema changes.
- No replacement. Decide: drop the feature, custom rewrite, or use a different approach. Get this decision in writing before the migration starts.
Estimate custom-module rewrite hours. Custom D7 modules will not run on D11 unmodified. Hooks, field APIs, render arrays, services, and the configuration system are all different. Plan for full rewrite or substantial port for each custom module.
Theme audit. The D7 theme will not work on D11. Either rebuild on a modern base theme (Olivero, Claro for admin, or a custom subtheme) or use the migration as the moment to refresh the design.

Phase 3 · Content and taxonomy

The content model on D7 sometimes has accumulated cruft. The migration is your chance to clean it without doing a separate content audit project.

Map every content type. Field machine names, types, widgets, formatters. Note where formatting is wrong because of a field that should have been split.
Map vocabularies and term hierarchies. If terms have fields, document those too. Term references on nodes are now entity references in D11.
Hunt for PHP filter and tokens. The PHP input format is gone. Anywhere it was used is a rewrite as a custom block, computed field, or admin tool.
Document file usage. Public versus private files, image styles in use, file fields versus media entities. D11 uses Media everywhere; old file fields will be re-bridged during migration.
Identify dead content. Old node types not used in years, terms with zero references, pages no human visits. The migration is the moment to leave them behind.

Phase 4 · Data migration mechanics

This is the engineering core. Done well it is boring; done badly it is a months-long mess.

Decide between core migrate_drupal and custom Migrate API plugins. Core covers the common case. Custom plugins are needed when the source schema has been customized or when content types map non-trivially.
Spin up a clean D11 with the production database as source. Configure migration in source/process/destination YAML or Migrate Plus config entities. Run idempotent imports.
Verify users. Email addresses, password hashes (D11 imports D7 hashes and rehashes on next login), roles, custom fields. Test a few accounts in a staging environment before you tell anyone the migration is real.
Verify dates and timezones. D7 stored some dates as Unix timestamps and some as ISO strings depending on the field. D11 has a single Date field. Off-by-an-hour bugs after migration are usually a timezone setting on the migration process plugin.
Verify entity references. Term references, node references, user references, file references. If any source ID changes during migration the references break silently.
Run the migration twice. The first run finds the bugs. The second run from a fresh D11 should be clean.

Phase 5 · URLs, redirects, and SEO

This is the part where most agencies leave money on the table. A clean migration with broken URLs loses you ranking that took years to build.

Export every D7 alias and redirect. drush sqlq "SELECT source, alias FROM url_alias" on D7. Save as CSV.
Replicate aliases on D11. The Pathauto patterns may have been different. Make sure the new aliases match the old aliases for every existing piece of content.
Set up 301s for any URL that must change. Use the Redirect module. Anything that pointed at a path that no longer exists in D11 needs a 301 to its new home.
Sitemap regeneration. Use Simple XML Sitemap. Validate the new sitemap has every URL you expect, no orphans.
Metatags and Schema.org. Re-create node-level metatag overrides. Verify Schema.org JSON-LD is unchanged or improved (this is also a chance to add Organization, BreadcrumbList, FAQ, Service schema).
Re-submit sitemap to Google Search Console after cutover. Watch the Coverage report for the first 30 days.

Phase 6 · Performance and security

D11 is faster than D7 by default but you have to wire the cache layers correctly.

Enable Drupal core page cache and dynamic page cache. Anonymous-visible pages should be served from cache for the first request after a content change.
Add Redis or Memcached for the cache backend. Faster than database cache, especially under load.
Add Varnish or a CDN for HTML caching. Cloudflare in front of Drupal works well; Varnish on the host works better but needs care for authenticated users.
Configure responsive image styles. WebP output, smart srcset, lazy loading. Image weight is the single biggest performance lever for content-heavy sites.
Force HTTPS, HSTS, secure cookies. If the D7 site was not on HTTPS-only, this is the moment.
Set up Drupal security advisory subscription. Email notifications for the modules you have installed. Patch within one business day for critical advisories.
Backups. Daily database, weekly files. Off-host. Test restore once a quarter.

Phase 7 · Hosting decision

The migration is also when you decide where the new site lives. Three options.

Stay with the same host. Cheapest if the host already supports D11. Verify PHP 8.3, MySQL 8 or MariaDB 10.6, Composer 2, deployable as a Composer-managed Drupal install.
Move to a managed Drupal host. Pantheon, Acquia, Platform.sh, or specialist Drupal hosts (WebEvra and others). Spend more, get less ops work. Check pricing carefully — managed Drupal hosts can run $400–$2000/mo for sites that would cost $50/mo on a generic VPS.
Self-host on a Hetzner or DigitalOcean VPS. Cheapest by far at scale, but you (or someone) own the server, the OS, the PHP-FPM, the MySQL, the backups, the patches. Reasonable if you have an SRE in-house.

Phase 8 · Cutover

This is the day. Most stress, least engineering. The work has been done; now it has to land cleanly.

Lower DNS TTL 24 hours before. If the TTL was 1 hour, drop it to 5 minutes the day before so post-switch propagation is fast.
Final D7 backup, frozen. Do not let any new content land between this snapshot and cutover.
Run the migration on production-equivalent infrastructure. Time it. The actual cutover migration should take less time than your DNS TTL.
Smoke test before flip. Login, view homepage, view a node of each content type, search, contact form, payment flow if any. From a real browser, not from curl.
Switch DNS. Watch error logs in real time for the first 30 minutes.
Monitor 48 hours. Error rate, page-load p95, sitemap-submit response, contact-form deliveries. Roll back is hours-not-days if something breaks badly.

Phase 9 · Post-launch (Week 1 to Week 12)

The migration is not done at cutover. The first three months are when latent bugs surface.

Drupal core update schedule. Drupal 11 minor releases every six months; security releases as needed. Decide who applies them and when.
Module update schedule. Same cadence. Patches within one business day for security advisories on installed modules.
Daily backup verification. Backup running is not the same as backup working. Restore one to a sandbox quarterly and verify integrity.
Monitoring and alerting. Uptime check, error-rate dashboards, log aggregation. PagerDuty, Better Stack, or whatever your team uses.
Decide on the support model. In-house Drupal hire, freelance retainer, or productized care plan. The right answer depends on the size of the team and the rate at which the site changes.

If you want a senior team to do this

WebEvra runs Drupal 7 to Drupal 11 migrations as a fixed-price productized offer. Three tiers, anchored to the risk calculator on our site:

Small migration: $500–$1,000. Mostly contrib, low custom code, no integrations to remap. 2–4 weeks.
Medium migration: $1,500–$2,500. Some custom modules to rewrite, integrations to remap, more QA. 8–12 weeks.
Large or complex: $3,000–$6,000+. Heavy custom code, multiple integrations, large content volume, custom theme rebuild. 12–20 weeks.

The price is fixed before code moves. Audit is free, 30 minutes, no commitment. After the migration we hand off to a care plan that handles the patching and updates so the site does not slowly turn back into a maintenance debt.

Get a free 30 minute audit: webevra.com/get-in-touch · [email protected] · cal.com/webevra

WebEvra LLP · CIN: ACV-3421 · Laplace, Hazratganj, Lucknow 226001, India · May 2026