Drupal 7 End of Life 2025: Migratiegids voor Enterprise Teams

Als je nog steeds Drupal 7 in productie gebruikt, ik zal het je niet mooier maken dan het is: je leeft op geleend tijd. Drupal 7 heeft op 5 januari 2025 het officiële einde van zijn levensduur bereikt, na meerdere verlengingen teruggaande tot de oorspronkelijke deadline van november 2021. Dat betekent geen beveiligingspatches meer, geen ondersteuning van de community, en niet langer doen alsof de migratie tot volgende kwartaal kan wachten. Ik heb in de afgelopen jaren meerdere enterprise teams door deze exacte situatie geholpen, en degenen die tot het laatste moment wachtten, betaalden altijd meer — in geld, in stress, en in technische schuld. Deze gids is alles wat ik zou willen overhandigen aan elke VP of Engineering die nog steeds Drupal 7 gebruikt.

Inhoudsopgave

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

Wat Drupal 7 End of Life echt betekent

Laten we precies zijn over wat "einde van levensduur" in de praktijk betekent, want ik heb hier veel verwarring over gezien:

  • Geen beveiligingsupdates meer. Het Drupal Security Team zal geen adviezen of patches meer uitgeven voor Drupal 7 core of contrib modules. Als morgen een kritieke SQL injection-kwetsbaarheid wordt ontdekt, ben je op jezelf aangewezen.
  • Geen bugfixes meer. Alles wat kapot is, blijft kapot.
  • Contrib module-onderzoekers gaan verder. De meeste hebben dat al gedaan. Veel populaire Drupal 7 modules hebben jaren geen update gehad.
  • Hostingproviders zullen ondersteuning stopzetten. Pantheon, Acquia en Platform.sh hebben allemaal timeline aangekondigd voor het afschaffen van Drupal 7 hosting-omgevingen. Acquia heeft zijn Drupal 7-ondersteuning voor bestaande klanten verlengd tot 2026, maar dat is een betaalde add-on, geen langetermijnoplossing.
  • PHP-compatibiliteitsproblemen zullen toenemen. Drupal 7 was gebouwd voor PHP 5.x. Het draait op PHP 8.1 met patches, maar PHP 8.1 zelf bereikt einde van leven in december 2025. Je stapelt niet-ondersteunde software op niet-ondersteunde software.

Het beveiligingsrisico alleen zou al voldoende moeten zijn om actie in te stellen. Als je organisatie enig vorm van PII, financiële gegevens of gezondheidsgegevens verwerkt, is het uitvoeren van niet-gepatched Drupal 7 een compliance-aansprakelijkheid. PCI DSS, HIPAA, SOC 2 — ze vereisen allemaal dat je ondersteunde software bijhoudt.

Waarom Enterprise Teams Bleven Uitstellen

Ik heb dit gesprek tientallen keren gevoerd. De redenen zijn altijd een variatie van:

  1. "Onze Drupal 7-site werkt prima." Dat doet het. Tot het niet meer doet. De code stopt niet met werken op 6 januari, maar het risicoprofiel verandert drastisch.
  2. "De migratie naar Drupal 8/9/10 is geen eenvoudige upgrade." Dit is eigenlijk waar. Anders dan het Drupal 6→7 upgrade-pad is het overstappen van Drupal 7 naar modern Drupal eigenlijk een herbouw. De architectuur is fundamenteel anders — op Symfony gebaseerd, configuration management, Twig-templates. Je aangepaste modules zullen niet overgaan.
  3. "We hebben 15 jaar inhoud en aangepaste functionaliteit." Enterprise Drupal 7-sites zijn meestal zwaar aangepast. Aangepaste modules, Views-configuraties, complexe taxonomiestructuren, integraties met legacy-systemen. Het migratiebereik is echt groot.
  4. "Budget was niet goedgekeurd." Het meest eerlijke antwoord, en het meest voorkomende.

Geen van deze redenen is wegegaan, maar de deadline is wel aankomst. Dus laten we het hebben over wat je echt moet doen.

Je Migratieopties in 2025

Je hebt vier realistische paden vooruit. Elk heeft compromissen. Laat me ze eerlijk uiteenzetten.

Optie Tijdlijn Kostenbereik Geschikt voor Risiconiveau
Drupal 10/11 6-18 maanden $200K-$1M+ Teams geïnvesteerd in Drupal-ecosysteem Gemiddeld
Headless Frontend + Drupal Backend 4-12 maanden $150K-$600K Teams die moderne UX willen met vertrouwd CMS Gemiddeld
Headless CMS-migratie 3-9 maanden $100K-$500K Teams klaar om volledig Drupal te verlaten Gemiddeld-Hoog
Extended Support Vendor Onmiddellijk $30K-$100K/jaar Teams die 6-18 maanden meer planningtijd nodig hebben Laag (korte termijn)

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

Optie 1: Migreren naar Drupal 10/11

Drupal 10 is de huidige stabiele release vanaf 2025, met Drupal 11 uitgebracht midden 2024 en dat wint aan adoptie. Als je team Drupal kent, je content model is goed en je wilt in het ecosysteem blijven, dit is het meest directe pad.

Maar "direct" betekent niet "gemakkelijk".

Wat de migratie echt inhoudt

Drupal biedt een Migrate API die content van een Drupal 7-database naar een Drupal 10/11-site kan trekken. In mijn ervaring handelt het ongeveer 60-70% van een typische migratie. De rest is aangepaste migratieplug-ins voor:

  • Aangepaste veldtypen
  • Complexe entity-referenties
  • Paragraphs (als je de Paragraphs module gebruikte)
  • Bestand- en mediabestanden
  • URL-aliassen en omleidingen
  • Gebruikersaccounts en rollen

Je aangepaste modules moeten herschreven worden. Niet overgezet — herschreven. Drupal 10/11 gebruikt een volledig ander architectuur. Als je een aangepaste module had die in hook_node_view() haakte, schrijf je nu event subscribers en plug-ins.

// Drupal 7 - hook-gebaseerd
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, op Symfony gebaseerd
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') {
      // Jouw logica hier
    }
  }
}

De Twig-template-laag is ook volledig anders dan PHPTemplate. Elke aangepaste theme moet opnieuw worden opgebouwd.

Realistische tijdlijn

Voor een middelgrote enterprise-site (500-5.000 pagina's, 10-20 content types, 5-10 aangepaste modules), verwacht 9-15 maanden. Dit omvat ontdekking, content modeling, development, content migratie, QA en lancering.

Optie 2: Headless met een Modern Frontend

Dit is waar het interessant wordt, en eerlijk gezegd is het de benadering die ik voor de meeste enterprise teams in 2025 aanbeveel. Behoud Drupal als je content backend (geüpgrade naar Drupal 10/11), maar bouw de frontend met een modern JavaScript-framework.

Drupal 10/11 heeft uitstekende JSON:API-ondersteuning ingebouwd in core. Je kunt je inhoud als gestructureerde gegevens blootstellen en ermee consumeren met Next.js, Astro of elk frontend-framework.

Waarom deze benadering goed werkt

  • Je redactionele team houdt Drupal's admin-interface. Ze kennen het. Ze zijn productief ermee. Het wegnemen ervan veroorzaakt organisatorische pijn.
  • Je frontend wordt dramatisch sneller. Statische generatie, edge caching, moderne imageoptimalisatie — dingen die pijnlijk zijn om vast te zetten op Drupal's rendering-laag.
  • Je kunt stap voor stap migreren. Zet de nieuwe frontend naast de oude site neer en migreer secties één voor één.

We hebben verschillende headless Drupal-frontends gebouwd met Next.js en Astro, en de prestatieverbetering is substantieel. Een klant zag hun Largest Contentful Paint dalen van 4,2s naar 0,8s na het overstappen naar een Next.js-frontend met ISR (Incremental Static Regeneration).

// Next.js-pagina die opgehaald wordt uit 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: regenereer elke 60 seconden
  };
}

Het next-drupal-pakket (onderhouden door Chapter Three) maakt dit nog gemakkelijker met ingebouwde ondersteuning voor preview-modus, authenticatie en content type-mapping.

Het voorbehoud

Je moet nog steeds Drupal 7 naar Drupal 10/11 op de backend migreren. Je vermijdt dat werk niet. Maar je scheidit het wel van de frontend-herbouw, wat je meer flexibiliteit in sequencing geeft.

Optie 3: Helemaal naar een Headless CMS

Soms is de juiste zet om Drupal helemaal te verlaten. Als je team geen sterke Drupal-expertise heeft, als je moeite hebt met het inhuren van Drupal-ontwikkelaars (en dat heb je — de Drupal-talentpool is sinds 2020 aanzienlijk gekrompen), of als je content model is uitgegroeid naar wat Drupal goed doet, kan een headless CMS de juiste keuze zijn.

Populaire migratiedoelen

CMS Prijzen (2025) Geschikt voor Content API Leerbare curva
Contentful $300-$2.500+/ma Grote redactionele teams GraphQL + REST Gemiddeld
Sanity $99-$949+/ma (aangepast enterprise) Developer-geleide teams GROQ + GraphQL Laag-Gemiddeld
Storyblok $109-$449+/ma Visueel bewerkingsbehoeften REST + GraphQL Laag
Strapi (zelf-gehost) Gratis (zelf-gehost) / $29+/ma (cloud) Teams die controle willen REST + GraphQL Gemiddeld
Payload CMS Gratis (zelf-gehost) / $35+/ma (cloud) TypeScript-first teams REST + GraphQL Gemiddeld

We werken met verschillende hiervan via onze headless CMS-practicepraktijk. De juiste keuze hangt af van de technische vaardigheden van je team, content-complexiteit en budget.

Content migratie van Drupal 7 naar een headless CMS

Dit is in sommige opzichten eigenlijk gemakkelijker dan migreren naar Drupal 10/11. Je bent niet beperkt door Drupal's migratie-framework. De typische benadering:

  1. Exporteer Drupal 7-inhoud via Drush of directe databasequery's
  2. Transformeer de gegevens naar het content model van je doel-CMS met scripts (Python en Node.js werken allebei goed)
  3. Importeer via de CMS's management API
  4. Verifieer en fix referenties, media en relaties
# Eenvoudige Drupal 7-contentexport via database
import mysql.connector
import json

db = mysql.connector.connect(
    host="localhost",
    user="drupal",
    password="jouwwachtwoord",
    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")

Het moeilijke deel is niet de export. Het gaat om het toewijzen van Drupal 7's content model (met het veld-systeem, entity-referenties, taxonomietermen en Paragraphs) aan de data-structuren van een nieuw CMS. Plan dat dit aanzienlijke analysetijd kost.

Optie 4: Extended Support Vendors (Tijd Kopen)

Als je echt meer tijd nodig hebt — en soms heb je dat, vooral met budget-cycli en organisatorische prioriteiten — kunnen extended support vendors je Drupal 7-site gepatched houden terwijl je plant.

Belangrijkste vendors die Drupal 7 extended support aanbieden

  • Tag1 Consulting — Een van de meest gevestigde. Ze porteer beveiligingspatches en bieden voortdurende ondersteuning. Prijzen variëren per site-complexiteit maar verwacht $30K-$80K/jaar.
  • Acquia — Biedt extended Drupal 7-ondersteuning via hun platform, momenteel tot 2026 voor enterprise-klanten.
  • mySociety / D7 LTS Contributors — Community-gestuurde extended support via het Drupal 7 Extended Support-programma.

Dit is een legitieme brug-strategie, geen langetermijnoplossing. Ik zou het op maximaal 12-18 maanden stellen. Elke maand dat je op Drupal 7 blijft, verhoogt je migratie-complexiteit naarmate de kloof tussen D7 en moderne platforms groeit.

Migratieplanning: Een Stap-voor-Stap Framework

Hier is het framework dat ik met elke enterprise-migratie gebruik. Het is niet glamoureus, maar het werkt.

Fase 1: Audit (2-4 weken)

  • Content audit: Hoeveel content types? Hoeveel nodes per type? Hoe complex is het content model? Gebruik je Paragraphs, Field Collections, Entity Reference?
  • Module audit: Maak een lijst van elke contrib en aangepaste module. Categoriseer als: heeft D10 equivalent, heeft aangepaste vervanging nodig, kan worden geëlimineerd. Ik gebruik drush pm:list --status=enabled en kruisverwijzing met drupal.org.
  • Integratie audit: Met welke externe systemen praat Drupal? Payment gateways, CRM's, marketing automation, SSO-providers?
  • Traffic- en prestatiebasislijnen: Documenteer huidige prestatiegegevens. Je hebt deze nodig voor vergelijking.
  • Gebruikersrol-audit: Hoeveel redactionele workflows bestaan er? Welke machtigingen zijn belangrijk?

Fase 2: Architectuur Beslissing (2-3 weken)

Bepaal op basis van je audit welke van de vier opties geschikt is. Dit is een echte architectuurbeslissing die engineering-leiderschap, content-stakeholders en wie ook controle over het budget moet betrekken.

Fase 3: Proof of Concept (3-6 weken)

Voordat je je aan een volledige migratie verbindt, bouw je een proof of concept die omvat:

  • 2-3 content types gemigreerd naar het nieuwe platform
  • De meest complexe redactionele workflow gereproduceerd
  • Één kritieke integratie aangesloten
  • Prestatiegrafieken op de nieuwe stack

Dit is waar je dingen ontdekt die niemand tijdens de audit noemde. Er is altijd iets.

Fase 4: Volledige Migratie (3-12 maanden)

Dit is het werkelijke werk. Prioriteer genadeloos. Niet alles van Drupal 7 hoeft mee te gaan. In mijn ervaring kunnen 20-30% van de inhoud en functionaliteit op een typische enterprise Drupal 7-site tijdens migratie worden geëlimineerd.

Fase 5: QA en Lancering (2-4 weken)

Omleidingen zijn cruciaal. Elke URL op je Drupal 7-site die zoekwaarde heeft, moet een 301 omleiding naar de nieuwe site hebben. Gebruik path_redirect en globalredirect module-exports als uitgangspunt, crawl vervolgens de oude site met Screaming Frog om een volledige omleiding-kaart te bouwen.

Content Migratiestrategie

Content migratie verdient een eigen sectie omdat het is waar de meeste migraties scheefgaan.

Het body field-probleem

Drupal 7 body fields zijn meestal een chaos van HTML. Je vindt inline-stijlen, gecodeerde afbeeldingspaden, ingebedde iframes, en soms raw PHP (als iemand de PHP filter module inschakelde — een echte beveiligingsnachtmerrie). Voordat je migreert, moet je beslissen: opschonen, of de chaos meenemen?

Mijn aanbeveling: schoon het op. Schrijf transformatiescripts die:

  • Inline-stijlen verwijderen
  • <img>-tags converteren naar juiste media-referenties
  • Interne links fixeren om de nieuwe URL-structuur te gebruiken
  • Elke WYSIWYG embed-token converteren naar het nieuwe formaat

Media-migratie

Drupal 7-sites gaan op wilde manieren met media om. Sommige gebruiken de Media module (1.x of 2.x), sommige gebruiken gewone file fields, sommige gebruiken ingebedde media tokens in body fields. Map elk media-afhandelingpatroon voordat je migratiecode gaat schrijven.

Als je naar een headless CMS beweegt, moet je ook beslissen waar media-bestanden wonen. De meeste headless CMS's hebben ingebouwde asset management, of je kunt een DAM als Cloudinary of imgix gebruiken.

Meertalige inhoud

Als je Drupal 7-site i18n, entity_translation of content_translation gebruikt, verdubbelt de migratiecomplexiteit ruwweg. Drupal 7's meertalig systeem was... laten we zeggen "creatief". De datastructuren zijn inconsistent en vereisen zorgvuldige toewijzing.

Kosten- en Tijdschattingen

Ik zal je echte nummers geven op basis van projecten die ik erbij betrokken ben geweest of rechtstreekse kennis van heb.

Site-complexiteit Drupal 10/11 Migratie Headless CMS Migratie Headless Frontend + Drupal Backend
Klein (5-10 content types, <1K pagina's, 2-3 aangepaste modules) $80K-$150K, 3-6 maanden $60K-$120K, 2-4 maanden $100K-$180K, 3-6 maanden
Gemiddeld (10-20 content types, 1K-10K pagina's, 5-10 aangepaste modules) $200K-$500K, 6-12 maanden $150K-$350K, 4-8 maanden $200K-$450K, 5-10 maanden
Groot (20+ content types, 10K+ pagina's, 10+ aangepaste modules, meertalig) $500K-$1,5M+, 12-24 maanden $300K-$800K, 6-14 maanden $400K-$1M+, 8-18 maanden

Dit zijn volledig belaste kosten inclusief ontdekking, development, migratie, QA en projectmanagement. Je ervaring zal variëren op basis van teamsamenstelling (in-house vs. bureau), geografische locatie, en hoeveel opschoning je doet versus porteren zoals-is.

Wil je een meer specifieke schatting voor je situatie? We doen migratie assessments die je een duidelijk beeld geven van bereik en kosten.

Veelgemaakte Fouten die Teams Maken

Proberen een 1:1 recreatie te doen. Je Drupal 7-site heeft 10+ jaar rotzooi verzameld. Migreer het niet allemaal. Gebruik de migratie als kans om te vereenvoudigen.

De omleiding-inspanning onderschatten. Ik werkte aan een migratie waar het team omleidingen tot twee weken voor lancering vergat. Ze hadden 45.000 URL's om in kaart te brengen. Wees niet dat team.

Redactionele stakeholders niet vroeg genoeg betrekken. De mensen die de CMS dagelijks gebruiken, zullen sterke meningen hebben over het nieuwe systeem. Betrek ze in Fase 1, niet Fase 4.

Een platform kiezen op basis van functies, niet team-capaciteit. De beste CMS is degene die je team daadwerkelijk kan onderhouden. Als je geen Drupal-expertise hebt, migreren naar Drupal 10/11 zonder daarvoor aan te nemen is jezelf instellen voor herhaling van deze situatie in 5 jaar.

Parallelle systemen te lang uitvoeren. Stel een harde cutover-datum vast. Oud en nieuw parallel uitvoeren is duur en verwarrend.

De content freeze overslaan. Tijdens de laatste migratie-push heb je een content freeze op de oude site nodig. Plan ervoor. Communiceer erover. Content auteurs haten het, maar het is nodig om niets verloren te laten gaan.

Veelgestelde Vragen

Wat gebeurt er als ik Drupal 7 na het einde van leven blijf gebruiken? Je site stopt niet plotseling met werken. Maar je ontvangt geen beveiligingspatches, wat betekent dat nieuw ontdekte kwetsbaarheden oneindig ongepatched blijven. Dit is een echt risico — Drupal-sites zijn frequente doelen voor geautomatiseerde aanvallen. Je zult ook toenemende compatibiliteitsproblemen ondervinden naarmate PHP-versies vorderen en hostingproviders ondersteuning voor oudere PHP-versies stopzetten. Voor elke organisatie met compliance-vereisten (PCI, HIPAA, SOC 2, GDPR) is het uitvoeren van niet-ondersteunde software een directe schending.

Kan ik direct van Drupal 7 naar Drupal 11 upgraden? Ja, de Migrate API ondersteunt directe migratie van Drupal 7 naar Drupal 10 of 11. Je hoeft niet door Drupal 8 en 9 te gaan. Dit is echter geen "upgrade" in de traditionele zin — het is een herbouw van je site op het nieuwe platform met gemigreerde inhoud. Je themes, aangepaste modules en configuraties gaan niet rechtstreeks over.

Hoe lang duurt een typische Drupal 7-migratie? Voor een middelgrote enterprise-site, plan je 6-12 maanden van kickoff tot lancering. Kleinere sites met beperkte aangepaste functionaliteit kunnen in 3-4 maanden gedaan zijn. Grote, complexe sites met meertalige inhoud, uitgebreide integraties en zware aanpassingen kunnen 12-24 maanden duren. De audit-fase geeft je een veel nauwkeurigere schatting voor je specifieke situatie.

Is het waard om naar Drupal 10/11 te migreren, of moet ik CMS-platforms wisselen? Het hangt af van je team en je behoeften. Als je Drupal-expertise in-house hebt, je content model is goed geschikt voor Drupal's entity-systeem, en je hebt Drupal's sterktes nodig (complexe machtigingen, meertalig, multi-site), dan heeft het zin om in het ecosysteem te blijven. Als je moeite hebt met het inhuren van Drupal-ontwikkelaars, je site is primair een marketing-site zonder complexe redactionele workflows, of je wilt naar een headless-architectuur gaan, kan een ander CMS de betere investering zijn.

Wat is de goedkoopste optie voor migratie weg van Drupal 7? Extended support van een vendor als Tag1 ($30K-$80K/jaar) is de goedkoopste korte-termijnoptie, maar het lost het onderliggende probleem niet op. Voor werkelijke migratie neigt het overstappen naar een headless CMS als Sanity of Storyblok met een static frontend de meest kosteneffectieve weg voor eenvoudiger sites, beginnend rond $60K-$120K. Bekijk onze prijspagina voor meer details over hoe we migratieprojecten structureren.

Zal mijn SEO-ranking door de migratie worden beïnvloed? Ze kunnen het zijn, maar juiste planning minimaliseert de impact. De kritieke factoren zijn: URL-structuren behouden (of juiste 301-omleidingen implementeren voor elke geïndexeerde URL), metadata en gestructureerde datamarkeringen behouden, ervoor zorgen dat de nieuwe site minstens zo snel laadt als de oude (idealiter sneller), en bijgewerkte sitemaps naar Google Search Console indienen. Ik heb goed uitgevoerde migraties gezien die resulteerden in SEO-verbeteringen door betere paginasnelheid en mobiele ervaring. Ik heb ook slecht uitgevoerde migraties gezien die het verkeer met 50% afkalten omdat iemand de omleidingen vergat.

Kan ik inhoud stap voor stap migreren of moet het allemaal tegelijk? Stap-voor-stap migratie is mogelijk en vaak voorkeurig voor grote sites. Met een headless-architectuur kun je de nieuwe frontend naast de oude site zetten en secties van de site één voor één migreren, gebruikmakend van reverse proxy-regels om verkeer naar de juiste backend te routeren. Dit vermindert risico en laat je elke sectie valideren voordat je verder gaat. Het compromis is verhoogde operationele complexiteit tijdens de migratieperiode.

Moet ik WordPress als migratiedoel in overweging nemen? WordPress is een levensvatbare optie voor eenvoudiger sites, maar ik zou voorzichtig zijn voor enterprise-usecases. Als je Drupal 7-site complexe content types, granulaire machtigingen of geavanceerde redactionele workflows heeft, voelt WordPress als een downgrade. WordPress's content model (posts, pages en custom post types) is eenvoudiger dan Drupal's entity-systeem. Voor enterprise teams zou ik serieuzer kijken naar Drupal 10/11 of een juiste headless CMS. Dat gezegd, WordPress met ACF Pro en een headless frontend kan goed werken voor marketing-gerichte sites.