If your organization runs a Drupal 7 site, you've probably been hearing about "end of life" for a while. Now it's here. Drupal 7 officially reached end of life on January 5, 2025 — meaning the Drupal community and the Drupal Security Team have stopped issuing official security patches and updates for it.
This isn't a theoretical risk anymore. It's an active one. And if you're not already planning your next step, this post will help you understand exactly what you're dealing with and what your options are.
⚠ What end of life actually means
No more official security patches from the Drupal Security Team. No more updates to core. Contributed modules for Drupal 7 are being abandoned by their maintainers. The longer you wait, the more your site falls behind — and the harder and more expensive a migration becomes.
What "end of life" actually means in practice
End of life doesn't mean your site stops working on January 6th. It means the safety net is gone.
Drupal 7 sites will continue to run. But without official security patches, every new vulnerability that's discovered in Drupal core, contributed modules, or PHP itself will go unaddressed. Attackers know this. They actively target end-of-life software because it's a predictable weak point — and they don't need to find a zero-day when they can just wait for one to become public knowledge with no corresponding fix.
The risk compounds over time in a few specific ways:
Ecosystem decay. Contributed modules — the plugins that extend Drupal's functionality — are maintained by volunteer developers who have now moved on to Drupal 10 and 11. A module that works today may break with the next PHP version update. Custom code that relies on Drupal 7's APIs will have no upgrade path if a dependency changes underneath it.
Hosting pressure. Managed Drupal hosts like Acquia and Pantheon have their own timelines for dropping Drupal 7 support. PHP 8.x has serious compatibility issues with Drupal 7, and PHP 7.x itself is past its own end of life. Your host will eventually force a PHP upgrade that breaks your Drupal 7 site — and at that point you're dealing with an emergency, not a planned migration.
Compliance risk. If your site processes personal data or operates in a regulated industry (healthcare, government, financial services), running unsupported software creates real exposure under HIPAA, FedRAMP, SOC 2, and similar frameworks. An auditor who sees a site running end-of-life software is going to flag it.
The bottom line
Every month you wait on a Drupal 7 site, you accumulate more technical debt, face more security exposure, and make the eventual migration more expensive. The sites that migrate smoothly are the ones that started planning 6–12 months before they had to.
Your three options
You have three realistic paths forward. Here's an honest assessment of each.
For most organizations, migrating to Drupal 10 or 11 is the right call — especially if you've invested significantly in a Drupal 7 content model, custom modules, or integrations. You're not starting from zero; you're upgrading a known platform with a known team.
Extended support makes sense only if you have a genuine constraint that delays migration — a budget cycle, a major site launch in progress, a team in transition. Use that time to plan and fund the migration, not to defer the decision indefinitely.
What a Drupal 7 to Drupal 10 migration actually involves
This is where a lot of organizations have unrealistic expectations. A Drupal 7 to Drupal 10 migration is not a software update — it's a rebuild that uses your existing content and configuration as the foundation. Here's what's actually involved:
Content migration
Drupal's migrate module handles moving most content types, users, taxonomy terms, and file assets from D7 to D10. For standard content types and clean data, this is reliable. For custom entities, complex field configurations, or years of accumulated legacy data, it requires careful mapping and testing.
Configuration migration
Drupal 7 has no configuration management system — everything lives in the database. Drupal 10 has a robust config system (YAML files in version control). That means your views, image styles, permissions, and field configurations need to be rebuilt or carefully migrated, not just copied.
Custom module updates
Drupal 7 modules use a hook-based architecture. Drupal 10 is object-oriented, with plugins, services, and dependency injection. Custom modules almost always need to be rewritten, not ported. This is typically the most time-consuming part of a migration for sites with significant custom functionality.
Theme rebuild
Drupal 7 themes use PHPTemplate. Drupal 10 uses Twig, which is cleaner and more secure but requires a full theme rewrite. Think of this as a site redesign opportunity — most teams use the migration to refresh their frontend as well.
Contributed module equivalents
Most popular Drupal 7 contributed modules have Drupal 10 equivalents — but not all. Part of the pre-migration audit is mapping every contrib module to its D10 equivalent (or replacement), and identifying gaps that need custom development to fill.
How long does it take?
Here's the honest answer — it depends on your site's complexity. But "it depends" isn't useful without a framework, so here's a realistic range:
| Site profile | Typical timeline | Key factors |
|---|---|---|
| Simple informational site | 4–8 weeks | Standard content types, minimal custom modules, off-the-shelf theme |
| Mid-size organizational site | 8–16 weeks | 5–10 content types, 1–3 custom modules, contrib-heavy, some integrations |
| Large enterprise or multi-site | 4–8 months | Complex content model, many custom modules, CRM/ERP integrations, multi-language |
| Government / high-compliance | 6–12 months | Accessibility audits, security reviews, approvals process, stakeholder sign-offs |
These timelines assume a competent team working consistently. Delays usually come from: scope creep discovered during the audit, slow content review and approval cycles, waiting for third-party integrations, and — most commonly — underestimating how much custom code exists.
The audit is everything
The single most important thing you can do before committing to a timeline or budget is a thorough technical audit. In our experience, about 40% of Drupal 7 migrations uncover significant custom code or unusual configurations that weren't in anyone's mental model of the site. You can't scope what you haven't audited.
Common mistakes to avoid
Treating it like a software update
The biggest mistake teams make is assuming "migration" means clicking an upgrade button. It doesn't. Plan for a project, not a patch.
Underestimating contributed module debt
Sites accumulate modules over years. We've audited Drupal 7 sites with 80+ contributed modules, many of which are no longer maintained and have no D10 equivalent. Mapping every module — and deciding what to replace, drop, or build custom — is essential work that happens before a single line of migration code is written.
Big bang vs. iterative migration
For large sites, trying to migrate everything at once is high-risk. An iterative approach — migrating content type by content type, section by section — allows for testing and rollback at each stage. It takes longer on paper but almost always delivers a cleaner result with fewer launch-day surprises.
Not planning for content freeze
Near the end of a migration, content editors need to stop making changes in the old system so the final data sync is clean. For sites with active editorial teams, this needs to be planned and communicated well in advance.
Skipping the post-launch checklist
A Drupal migration isn't done at launch. You need 2–4 weeks of post-launch monitoring: cache warm-up, crawl verification, 404 tracking, performance baselining, and making sure all integrations are firing correctly in production.
Your migration readiness checklist
Before you start any migration conversation with a vendor or internal team, work through this checklist:
- Inventory
- List all content types and the approximate number of nodes in each
- List all contributed modules (use
drush pm-list --type=module --status=enabled) - Identify all custom modules and their primary functions
- Document all third-party integrations (CRM, analytics, payment, SSO, etc.)
- Note multi-language or multi-site requirements
- Risk assessment
- Check each contrib module for a Drupal 10 equivalent
- Identify any contrib modules with no maintained D10 equivalent
- Check current PHP version and hosting environment compatibility
- Note any accessibility or compliance requirements (WCAG, Section 508, FedRAMP)
- Planning
- Establish a realistic budget range (most enterprise migrations: $40k–$200k+)
- Identify internal stakeholders who need to approve content, design, and launch
- Decide: migration-only, or migration + redesign?
- Determine if extended support is needed as a bridge while planning
How to get started
The most useful first step is a technical audit — not a proposal, not a quote, but a genuine assessment of what you have, what it'll take, and what the risks are. A good audit takes 2–5 days of focused work and produces a clear picture of your migration path, timeline, and cost range.
At Sympals, we've been doing Drupal migrations since D6 → D7 — through every major version transition. We know where the surprises hide. If you have a Drupal 7 site and want an honest assessment of where you stand, we offer a free 30-minute audit call to help you understand your options before you commit to anything.