If you're still running Drupal 7 in production, I'm not going to sugarcoat it: you're on borrowed time. Drupal 7 reached its official end of life on January 5, 2025, after multiple extensions dating back to the original November 2021 deadline. That means no more security patches, no more community support, and no more pretending the migration can wait until next quarter. I've helped multiple enterprise teams through this exact situation over the past few years, and the ones who waited until the last minute always paid more — in money, in stress, and in technical debt. This guide is everything I wish I could hand to every VP of Engineering still running Drupal 7.

Table of Contents

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams

What Drupal 7 End of Life Actually Means

Let's be precise about what "end of life" means in practice, because I've seen a lot of confusion here:

  • No more security updates. The Drupal Security Team will not issue advisories or patches for Drupal 7 core or contrib modules. If a critical SQL injection vulnerability is discovered tomorrow, you're on your own.
  • No more bug fixes. Anything broken stays broken.
  • Contrib module maintainers are moving on. Most already have. Many popular Drupal 7 modules haven't seen an update in years.
  • Hosting providers will drop support. Pantheon, Acquia, and Platform.sh have all announced timelines for deprecating Drupal 7 hosting environments. Acquia extended their Drupal 7 support through 2026 for existing customers, but that's a paid add-on, not a long-term solution.
  • PHP compatibility issues will compound. Drupal 7 was built for PHP 5.x. It runs on PHP 8.1 with patches, but PHP 8.1 itself reaches end of life in December 2025. You'll be stacking unsupported software on top of unsupported software.

The security risk alone should be enough to trigger action. If your organization handles any form of PII, financial data, or health information, running unpatched Drupal 7 is a compliance liability. PCI DSS, HIPAA, SOC 2 — they all require you to maintain patched, supported software.

Why Enterprise Teams Kept Delaying

I've had this conversation dozens of times. The reasons are always some variation of:

  1. "Our Drupal 7 site works fine." It does. Until it doesn't. The code won't stop working on January 6, but the risk profile changes dramatically.
  2. "The migration to Drupal 8/9/10 isn't a simple upgrade." This is actually true. Unlike the Drupal 6→7 upgrade path, moving from Drupal 7 to modern Drupal is essentially a rebuild. The architecture is fundamentally different — Symfony-based, configuration management, Twig templates. Your custom modules won't port over.
  3. "We have 15 years of content and custom functionality." Enterprise Drupal 7 sites tend to be heavily customized. Custom modules, Views configurations, complex taxonomy structures, integrations with legacy systems. The migration scope is genuinely large.
  4. "Budget wasn't approved." The most honest answer, and the most common.

None of these reasons went away, but the deadline did arrive. So let's talk about what to actually do.

Your Migration Options in 2025

You have four realistic paths forward. Each has trade-offs. Let me break them down honestly.

Option Timeline Cost Range Best For Risk Level
Drupal 10/11 6-18 months $200K-$1M+ Teams invested in Drupal ecosystem Medium
Headless Frontend + Drupal Backend 4-12 months $150K-$600K Teams wanting modern UX with familiar CMS Medium
Headless CMS Migration 3-9 months $100K-$500K Teams ready to leave Drupal entirely Medium-High
Extended Support Vendor Immediate $30K-$100K/year Teams needing 6-18 months more planning time Low (short-term)

Drupal 7 End of Life 2025: Migration Guide for Enterprise Teams - architecture

Option 1: Migrate to Drupal 10/11

Drupal 10 is the current stable release as of 2025, with Drupal 11 released in mid-2024 and gaining adoption. If your team knows Drupal, your content model is solid, and you want to stay in the ecosystem, this is the most straightforward path.

But "straightforward" doesn't mean "easy."

What the migration actually involves

Drupal provides a Migrate API that can pull content from a Drupal 7 database into a Drupal 10/11 site. In my experience, it handles about 60-70% of a typical migration. The rest is custom migration plugins for:

  • Custom field types
  • Complex entity references
  • Paragraphs (if you used the Paragraphs module)
  • File and media assets
  • URL aliases and redirects
  • User accounts and roles

Your custom modules need to be rewritten. Not ported — rewritten. Drupal 10/11 uses a completely different architecture. If you had a custom module that hooked into hook_node_view(), you're now writing event subscribers and plugins.

// Drupal 7 - hook-based
function mymodule_node_view($node, $view_mode, $langcode) {
  if ($node->type == 'article') {
    $node->content['custom_field'] = array(
      '#markup' => '<div>' . custom_logic($node) . '</div>',
      '#weight' => 10,
    );
  }
}

// Drupal 10/11 - OOP, Symfony-based
namespace Drupal\mymodule\EventSubscriber;

use Drupal\core_event\NodeViewEvent;
use Symfony\Component\EventDispatcher\EventSubscriberInterface;

class NodeViewSubscriber implements EventSubscriberInterface {
  public static function getSubscribedEvents() {
    return [NodeViewEvent::class => 'onNodeView'];
  }
  
  public function onNodeView(NodeViewEvent $event) {
    $node = $event->getNode();
    if ($node->bundle() === 'article') {
      // Your logic here
    }
  }
}

The Twig templating layer is also completely different from PHPTemplate. Every custom theme needs rebuilding.

Realistic timeline

For a mid-sized enterprise site (500-5,000 pages, 10-20 content types, 5-10 custom modules), expect 9-15 months. That includes discovery, content modeling, development, content migration, QA, and launch.

Option 2: Go Headless with a Modern Frontend

This is where things get interesting, and frankly, it's the approach I recommend most often for enterprise teams in 2025. Keep Drupal as your content backend (upgraded to Drupal 10/11), but build the frontend with a modern JavaScript framework.

Drupal 10/11 has excellent JSON:API support built into core. You can expose your content as structured data and consume it with Next.js, Astro, or any frontend framework.

Why this approach works well

  • Your editorial team keeps Drupal's admin interface. They know it. They're productive in it. Ripping that away causes organizational pain.
  • Your frontend gets dramatically faster. Static generation, edge caching, modern image optimization — things that are painful to bolt onto Drupal's rendering layer.
  • You can migrate incrementally. Stand up the new frontend alongside the old site and migrate sections one at a time.

We've built several headless Drupal frontends with Next.js and Astro, and the performance improvements are substantial. One client saw their Largest Contentful Paint drop from 4.2s to 0.8s after moving to a Next.js frontend with ISR (Incremental Static Regeneration).

// Next.js page fetching from Drupal's JSON:API
export async function getStaticProps({ params }) {
  const res = await fetch(
    `${process.env.DRUPAL_BASE_URL}/jsonapi/node/article?filter[field_slug]=${params.slug}&include=field_image,field_tags`
  );
  const data = await res.json();
  
  return {
    props: {
      article: data.data[0],
      included: data.included,
    },
    revalidate: 60, // ISR: regenerate every 60 seconds
  };
}

The next-drupal package (maintained by Chapter Three) makes this even easier with built-in support for preview mode, authentication, and content type mapping.

The catch

You still need to migrate Drupal 7 to Drupal 10/11 on the backend. You're not avoiding that work. But you are decoupling it from the frontend rebuild, which gives you more flexibility in sequencing.

Option 3: Move to a Headless CMS Entirely

Sometimes the right move is to leave Drupal completely. If your team doesn't have strong Drupal expertise, if you're struggling to hire Drupal developers (and you are — the Drupal talent pool has shrunk significantly since 2020), or if your content model has outgrown what Drupal does well, a headless CMS might be the right call.

CMS Pricing (2025) Best For Content API Learning Curve
Contentful $300-$2,500+/mo Large editorial teams GraphQL + REST Medium
Sanity $99-$949+/mo (custom enterprise) Developer-led teams GROQ + GraphQL Low-Medium
Storyblok $109-$449+/mo Visual editing needs REST + GraphQL Low
Strapi (self-hosted) Free (self-hosted) / $29+/mo (cloud) Teams wanting control REST + GraphQL Medium
Payload CMS Free (self-hosted) / $35+/mo (cloud) TypeScript-first teams REST + GraphQL Medium

We work with several of these through our headless CMS development practice. The right choice depends on your team's technical skills, content complexity, and budget.

Content migration from Drupal 7 to a headless CMS

This is actually easier than migrating to Drupal 10/11 in some ways. You're not constrained by Drupal's migration framework. The typical approach:

  1. Export Drupal 7 content via Drush or direct database queries
  2. Transform the data into your target CMS's content model using scripts (Python and Node.js both work well)
  3. Import via the CMS's management API
  4. Verify and fix references, media, and relationships
# Simple Drupal 7 content export via database
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="yourpassword",
    database="drupal7_db"
)

cursor = db.cursor(dictionary=True)
cursor.execute("""
    SELECT n.nid, n.title, n.created, n.changed, n.status,
           fdb.body_value, fdb.body_summary
    FROM node n
    LEFT JOIN field_data_body fdb ON n.nid = fdb.entity_id
    WHERE n.type = 'article' AND n.status = 1
    ORDER BY n.created DESC
""")

articles = cursor.fetchall()

with open('articles_export.json', 'w') as f:
    json.dump(articles, f, default=str, indent=2)

print(f"Exported {len(articles)} articles")

The hard part isn't the export. It's mapping Drupal 7's content model (with its field system, entity references, taxonomy terms, and Paragraphs) to a new CMS's data structures. Plan for this to take significant analysis time.

Option 4: Extended Support Vendors (Buy Time)

If you genuinely need more time — and sometimes you do, especially with budget cycles and organizational priorities — extended support vendors can keep your Drupal 7 site patched while you plan.

Key vendors offering Drupal 7 extended support

  • Tag1 Consulting — One of the most established. They backport security patches and provide ongoing maintenance. Pricing varies by site complexity but expect $30K-$80K/year.
  • Acquia — Offers extended Drupal 7 support through their platform, currently through 2026 for enterprise customers.
  • mySociety / D7 LTS Contributors — Community-driven extended support through the Drupal 7 Extended Support program.

This is a legitimate bridge strategy, not a long-term solution. I'd cap it at 12-18 months maximum. Every month you stay on Drupal 7 increases your migration complexity as the gap between D7 and modern platforms widens.

Migration Planning: A Step-by-Step Framework

Here's the framework I use with every enterprise migration. It's not glamorous, but it works.

Phase 1: Audit (2-4 weeks)

  • Content audit: How many content types? How many nodes per type? What's the content model complexity? Are you using Paragraphs, Field Collections, Entity Reference?
  • Module audit: List every contrib and custom module. Categorize as: has D10 equivalent, needs custom replacement, can be eliminated. I use drush pm:list --status=enabled and cross-reference with drupal.org.
  • Integration audit: What external systems does Drupal talk to? Payment gateways, CRMs, marketing automation, SSO providers?
  • Traffic and performance baseline: Document current performance metrics. You'll need these for comparison.
  • User role audit: How many editorial workflows exist? What permissions matter?

Phase 2: Architecture Decision (2-3 weeks)

Based on your audit, decide which of the four options is right. This is a genuine architectural decision that should involve engineering leadership, content stakeholders, and whoever controls the budget.

Phase 3: Proof of Concept (3-6 weeks)

Before committing to a full migration, build a proof of concept that covers:

  • 2-3 content types migrated to the new platform
  • The most complex editorial workflow reproduced
  • One critical integration connected
  • Performance benchmarks on the new stack

This is where you'll discover the things nobody mentioned during the audit. There's always something.

Phase 4: Full Migration (3-12 months)

This is the actual work. Prioritize ruthlessly. Not everything from Drupal 7 needs to come along. In my experience, 20-30% of content and functionality on a typical enterprise Drupal 7 site can be eliminated during migration.

Phase 5: QA and Launch (2-4 weeks)

Redirects are critical. Every URL on your Drupal 7 site that has search equity needs a 301 redirect to the new site. Use path_redirect and globalredirect module exports as a starting point, then crawl the old site with Screaming Frog to build a complete redirect map.

Content Migration Strategy

Content migration deserves its own section because it's where most migrations go sideways.

The body field problem

Drupal 7 body fields are typically a mess of HTML. You'll find inline styles, hardcoded image paths, embedded iframes, and occasionally raw PHP (if someone enabled the PHP filter module — a genuine security horror). Before migrating, you need to decide: clean it up, or port the mess?

My recommendation: clean it up. Write transformation scripts that:

  • Strip inline styles
  • Convert <img> tags to proper media references
  • Fix internal links to use the new URL structure
  • Convert any WYSIWYG embed tokens to the new format

Media migration

Drupal 7 sites handle media in wildly different ways. Some use the Media module (1.x or 2.x), some use plain file fields, some use embedded media tokens in body fields. Map every media handling pattern before you start writing migration code.

If you're moving to a headless CMS, you'll also need to decide where media files live. Most headless CMSs have built-in asset management, or you can use a DAM like Cloudinary or imgix.

Multilingual content

If your Drupal 7 site uses i18n, entity_translation, or content_translation, the migration complexity roughly doubles. Drupal 7's multilingual system was... let's call it "creative." The data structures are inconsistent and require careful mapping.

Cost and Timeline Estimates

I'll give you real numbers based on projects I've been involved with or have direct knowledge of.

Site Complexity Drupal 10/11 Migration Headless CMS Migration Headless Frontend + Drupal Backend
Small (5-10 content types, <1K pages, 2-3 custom modules) $80K-$150K, 3-6 months $60K-$120K, 2-4 months $100K-$180K, 3-6 months
Medium (10-20 content types, 1K-10K pages, 5-10 custom modules) $200K-$500K, 6-12 months $150K-$350K, 4-8 months $200K-$450K, 5-10 months
Large (20+ content types, 10K+ pages, 10+ custom modules, multilingual) $500K-$1.5M+, 12-24 months $300K-$800K, 6-14 months $400K-$1M+, 8-18 months

These are fully loaded costs including discovery, development, migration, QA, and project management. Your mileage will vary based on team composition (in-house vs. agency), geographic location, and how much cleanup you do versus port as-is.

Want to get a more specific estimate for your situation? We do migration assessments that give you a clear picture of scope and cost.

Common Mistakes I've Seen Teams Make

Trying to do a 1:1 recreation. Your Drupal 7 site has accumulated 10+ years of cruft. Don't migrate all of it. Use the migration as an opportunity to simplify.

Underestimating the redirect effort. I worked on a migration where the team forgot about redirects until two weeks before launch. They had 45,000 URLs to map. Don't be that team.

Not involving editorial stakeholders early enough. The people who use the CMS daily will have strong opinions about the new system. Get them involved in Phase 1, not Phase 4.

Choosing a platform based on features, not team capability. The best CMS is the one your team can actually maintain. If you don't have Drupal expertise, migrating to Drupal 10/11 without hiring for it is setting up for a repeat of this situation in 5 years.

Running parallel systems too long. Set a hard cutover date. Running old and new in parallel is expensive and confusing.

Skipping the content freeze. During the final migration push, you need a content freeze on the old site. Plan for it. Communicate it. Content authors hate it, but it's necessary to ensure nothing gets lost.

FAQ

What happens if I keep running Drupal 7 after end of life? Your site won't suddenly stop working. But you'll receive no security patches, which means any newly discovered vulnerabilities will remain unpatched indefinitely. This is a real risk — Drupal sites are frequent targets for automated attacks. You'll also face increasing compatibility issues as PHP versions advance and hosting providers drop support for older PHP versions. For any organization with compliance requirements (PCI, HIPAA, SOC 2, GDPR), running unsupported software is a direct violation.

Can I upgrade directly from Drupal 7 to Drupal 11? Yes, the Migrate API supports direct migration from Drupal 7 to Drupal 10 or 11. You don't need to step through Drupal 8 and 9. However, this isn't an "upgrade" in the traditional sense — it's a rebuild of your site on the new platform with content migrated over. Your themes, custom modules, and configurations don't carry over directly.

How long does a typical Drupal 7 migration take? For a mid-sized enterprise site, plan for 6-12 months from kickoff to launch. Smaller sites with limited custom functionality can be done in 3-4 months. Large, complex sites with multilingual content, extensive integrations, and heavy customization can take 12-24 months. The audit phase will give you a much more accurate estimate for your specific situation.

Is it worth migrating to Drupal 10/11, or should I switch CMS platforms? It depends on your team and your needs. If you have Drupal expertise in-house, your content model is well-suited to Drupal's entity system, and you need Drupal's strengths (complex permissions, multilingual, multi-site), then staying in the ecosystem makes sense. If you're struggling to hire Drupal developers, your site is primarily a marketing site without complex editorial workflows, or you want to move to a headless architecture, a different CMS might be the better investment.

What's the cheapest option for migrating off Drupal 7? Extended support from a vendor like Tag1 ($30K-$80K/year) is the cheapest short-term option, but it doesn't solve the underlying problem. For actual migration, moving to a headless CMS like Sanity or Storyblok with a static frontend tends to be the most cost-effective path for simpler sites, starting around $60K-$120K. Check our pricing page for more details on how we structure migration projects.

Will my SEO rankings be affected by the migration? They can be, but proper planning minimizes the impact. The critical factors are: maintaining URL structures (or implementing proper 301 redirects for every indexed URL), preserving meta data and structured data markup, ensuring the new site loads at least as fast as the old one (ideally faster), and submitting updated sitemaps to Google Search Console. I've seen well-executed migrations result in SEO improvements due to better page speed and mobile experience. I've also seen botched migrations tank traffic by 50% because someone forgot the redirects.

Can I migrate content incrementally or does it have to be all at once? Incremental migration is possible and often preferable for large sites. With a headless architecture, you can stand up the new frontend and migrate sections of the site one at a time, using reverse proxy rules to route traffic to the appropriate backend. This reduces risk and lets you validate each section before moving on. The trade-off is increased operational complexity during the migration period.

Should I consider WordPress as a migration target? WordPress is a viable option for simpler sites, but I'd be cautious for enterprise use cases. If your Drupal 7 site has complex content types, granular permissions, or sophisticated editorial workflows, WordPress will feel like a downgrade. WordPress's content model (posts, pages, and custom post types) is simpler than Drupal's entity system. For enterprise teams, I'd look more seriously at Drupal 10/11 or a proper headless CMS. That said, WordPress with ACF Pro and a headless frontend can work well for marketing-focused sites.