Drupal 7 reached end of life on January 5, 2025. Sites still running it have now gone more than a year without security patches, PHP support, or community bug fixes; every day in production adds known, unpatched vulnerabilities with no official remedy. That is technical debt accruing in real time, and for organizations bound by compliance, data protection, or accessibility regulations, it is a defensibility problem as much as a security one.
The deadline that should drive your planning in 2026, though, is the next one. Drupal 10 reaches end of life on December 9, 2026, and Drupal 12 ships the same week. For an organization still on Drupal 7, that timeline settles a question that used to be open: not whether to migrate, but what to migrate to and how ready you actually are to do it well.
A Drupal 7 migration is not an update. It is a rebuild on a different core architecture, theme engine, and module ecosystem. It is also not a replication of the old site ; it is a chance to relearn what the site is for and evolve it. This readiness checklist breaks down what to evaluate before you sign a statement of work, so the rebuild is approached strategically rather than reactively.
A Drupal 7 migration readiness checklist covers seven evaluations before scoping: content inventory, module inventory, theme, third-party integrations, AI strategy, digital transformation alignment, and content cleanup. Drupal 7 reached end of life on January 5, 2025, and a migration to Drupal 11 is a full rebuild, typically taking 7 to 12 months for enterprise sites.
What The Version Timeline Means for Your Target
Because a Drupal 7 migration is a full rebuild regardless of destination, the instinct to wait for the newest version points the wrong way. Drupal 11 is the current stable major release and the right target for a D7 rebuild today: it is supported, it is what the contributed-module ecosystem is building against, and landing on it now turns the eventual move to Drupal 12 into a routine minor upgrade rather than another rebuild. Drupal upgrades are handled sequentially, not leapfrogged, so jumping from Drupal 7 straight to Drupal 12 was never on the table. Target 11, treat 11-to-12 as planned maintenance, and stop measuring readiness against a version number you cannot reach in one move. (For the cost side of this timing question, see why Q4 2026 is the most expensive time to migrate.)
Where We Land: Readiness is an Ownership Problem, Not a Code Problem
Here is the position we hold, drawn from the migrations we run. The Drupal 7 projects that stall do not stall on code; the code path is well-trodden and tooled. They stall on ownership.
Over a decade or more, a D7 site quietly encodes hundreds of undocumented decisions: why a content type has the fields it has, which integration feeds which downstream system, and what an editorial workflow is actually protecting. A rebuild surfaces every one of those at once, and on most projects, nobody inside the organization currently owns the answers. That is the real readiness gap. The technical inventory is the easy half; the hard half is naming, for each part of the old site, who decides what it becomes. The checklist below is organized to close that gap before scoping, not during it.
Drupal 7 Migration Readiness Checklist
1. Audit your existing Drupal
Evaluate content inventory: Decide what should be migrated, archived, or restructured. A migration is the cheapest moment you will ever have to retire content that no longer earns its place, and the URLs of your top-performing pages are assets, so map redirects deliberately for anything that must move.
Evaluate module inventory: Identify which contributed modules are still genuinely needed and whether each has a Drupal 11 equivalent. Custom modules will need to be rewritten, usually the largest, most underestimated line in the budget.
Evaluate theme: A D7 PHPTemplate theme does not carry over; the front end is rebuilt in Twig. Decide whether this is the moment for a UX refresh, a redesign, or a faithful facelift and price each differently.
Evaluate integrations: Review every third-party connection (CRM, ERP, eCommerce, SSO, marketing automation) and confirm which are still in use and who owns each.
Define top priorities: Security, performance, scalability, integration, workflow, or editorial experience. Name the few that matter most.
Consider user expectations: Does your audience expect new functionality, multilingual support, or accessibility upgrades?
Define your AI strategy: This is no longer a forward-looking line item. With the Drupal AI module now at stable release, decide deliberately whether and how AI fits your platform search, content workflows, personalization, and whether you will rely on commercial AI providers or open models for data-residency reasons. A migration is the right time to make the platform AI-ready rather than retrofitting later. (Our view of the Drupal AI landscape goes deeper into the trade-offs.)
Align to your digital transformation roadmap: A migration framed only as "get off D7" produces a like-for-like copy; framed as a step in a roadmap, it produces a platform that supports what the organization is trying to become.
3. Plan content strategy
Clean up content: Audit for duplicates and outdated material, and migrate high-quality content with its integrity intact.
Improve taxonomy: Restructure information architecture for navigation, searchability, and editor experience. Don't just recreate the old menu.
Ensure SEO and accessibility compliance: Preserve ranking URLs and align to current accessibility standards (WCAG 2.2 AA is the current benchmark for public-sector and enterprise sites).
4. Build a module-functionality matrix
Drupal 11 has a different module ecosystem, and some Drupal 7 modules were never ported.
Map essential features to Drupal 11 modules: Match each piece of existing functionality to a supported Drupal 11 module.
Plan custom development: Allocate resources to rebuild or extend features that have no off-the-shelf equivalent.
Replace deprecated functionality: Find modern alternatives where the original approach no longer exists.
5. Prepare your team and infrastructure
Validate expertise: Is the team proficient with Symfony, Twig, Composer, and modern Drupal architecture?
Review hosting: Is the environment ready for PHP 8.3+, optimized for modern caching, and are CI/CD pipelines configured?
Prepare onboarding: Have content editors and admins been trained on the new Drupal admin experience?
6. Map the migration roadmap
Break the process into phases that fit your organization. We generally use six:
Phase
Goal
1. Discovery & Planning
Define your goals, assess the current Drupal website, and create a migration strategy with a timeline.
2. Content & Data Migration
Audit, cleanup, and migrate content and data structures, while ensuring SEO preservation and content integrity.
3. Design & Theme
Redesign or refresh, and rebuild on Drupal 11 with Twig, while ensuring accessibility standards and brand guidelines are met.
4. Custom Development & Integration
Rebuild custom functionality to replace deprecated modules and re-establish third-party integration.
5. Testing (functional, performance, security)
Test all features, site performance, and security before launch.
6. Launch and support
Deploy Drupal 11 Website, monitor post-launch metrics, and establish period maintenance processes.
For a partner-led version of this roadmap, our guide to evaluating a Drupal migration partner covers the questions that separate experienced partners from transactional vendors, and an enterprise distribution like Varbase can compress phases 3 and 4 by giving you a hardened Drupal 11 starting point.
What Readiness Buys You
Planning thoroughly is what keeps risk, downtime, and cost contained. A Drupal 7 to Drupal 11 migration is a substantial project, typically 7 to 12 months for an enterprise site, depending on content volume, custom code, and integrations. A clear readiness checklist ensures the work is approached strategically: security and data integrity first, downtime minimized, and the organization walking into scoping with its decisions already made rather than discovered mid-project.
If you want a second set of eyes on where your D7 site actually stands, a structured migration readiness audit is the lowest-risk first step and far cheaper than discovering the gaps after the statement of work is signed.
Start with a comprehensive audit, evaluate content inventory, module compatibility, theme requirements, and third-party integrations. Use the Upgrade Status module to assess readiness.
Yes, migrate directly, but it is not a simple "upgrade." It is a migration-based re-platforming because D7 and D11 have entirely different architectures.
All custom D7 modules must be completely rewritten due to architectural differences (Symfony, Twig, modern PHP). Use Drupal Rector and drupal-check to identify deprecated code.