Deine Production Site läuft auf Drupal 7, und seit dem 5. Januar 2025 erhält sie keine Sicherheits-Patches mehr. Keine Emergency-Fixes. Kein Community-Backup. Keine weiteren Extensions. Ich habe in den letzten achtzehn Monaten sechs Enterprise-Teams durch diese Migration begleitet, und das Muster ist klar: Die Teams, die es wie eine Q4-Checkbox behandelten, zahlten 40–60% mehr als diejenigen, die sechs Monate im Voraus planten. Die Verzögerungs-Steuer ist real – nicht nur in Dollar-Begriffen, sondern auch in der technischen Verschuldung, die deine Engineers erben, wenn sie gezwungen werden, eine Migration in acht Wochen statt in zwanzig Wochen zu liefern. Das ist der Leitfaden, den ich jedem VP of Engineering in dem Moment in die Hand gebe, wenn er zugibt, dass Drupal 7 immer noch sein Flaggschiff-Projekt antreibt. Du bist nicht zu spät, aber das Fenster schließt sich schneller, als dein Roadmap zugeben würde.

Inhaltsverzeichnis

Drupal 7 End of Life 2025: Migrations-Leitfaden für Enterprise-Teams

Was Drupal 7 End of Life wirklich bedeutet

Lass mich präzise sein, was "End of Life" in der Praxis bedeutet, denn ich habe hier viel Verwirrung gesehen:

  • Keine Sicherheits-Updates mehr. Das Drupal Security Team wird keine Advisories oder Patches für Drupal 7 Core oder Contrib-Module herausgeben. Wenn morgen eine kritische SQL-Injection-Sicherheitslücke entdeckt wird, bist du auf dich allein gestellt.
  • Keine Bug-Fixes mehr. Alles, was kaputt ist, bleibt kaputt.
  • Contrib-Module-Betreuer ziehen weiter. Die meisten haben das bereits. Viele beliebte Drupal 7-Module haben seit Jahren kein Update gesehen.
  • Hosting-Provider werden Support einstellen. Pantheon, Acquia und Platform.sh haben alle Timelines für die Einstellung von Drupal 7-Hosting-Umgebungen angekündigt. Acquia hat seinen Drupal 7-Support für bestehende Kunden bis 2026 verlängert, aber das ist ein kostenpflichtiges Add-on, keine langfristige Lösung.
  • PHP-Kompatibilitätsprobleme werden sich verschärfen. Drupal 7 wurde für PHP 5.x entwickelt. Es läuft auf PHP 8.1 mit Patches, aber PHP 8.1 selbst erreicht sein End of Life im Dezember 2025. Du wirst ununterstützte Software auf ununterstützte Software stapeln.

Allein das Sicherheitsrisiko sollte genug sein, um Maßnahmen auszulösen. Wenn deine Organisation irgendwelche PII, Finanzdaten oder Gesundheitsinformationen verarbeitet, ist das Betreiben von ungepatchtem Drupal 7 eine Compliance-Haftung. PCI DSS, HIPAA, SOC 2 – sie alle verlangen, dass du gepatchte, unterstützte Software beibehältst.

Warum Enterprise-Teams weiterhin verzögert haben

Ich habe dieses Gespräch dutzende Male geführt. Die Gründe sind immer irgendeine Variation von:

  1. "Unsere Drupal 7-Site funktioniert einwandfrei." Tut sie. Bis sie es nicht mehr tut. Der Code wird am 6. Januar nicht aufhören zu funktionieren, aber das Risikoprofil ändert sich dramatisch.
  2. "Die Migration zu Drupal 8/9/10 ist keine einfache Upgrade." Das ist eigentlich wahr. Im Gegensatz zum Drupal 6→7-Upgrade-Pfad ist die Migration von Drupal 7 zu modernem Drupal im Wesentlichen ein Rebuild. Die Architektur ist grundlegend anders – Symfony-basiert, Configuration Management, Twig-Templates. Deine Custom Modules werden nicht portiert.
  3. "Wir haben 15 Jahre an Content und Custom-Funktionalität." Enterprise Drupal 7-Sites neigen dazu, stark angepasst zu sein. Custom Modules, Views-Konfigurationen, komplexe Taxonomy-Strukturen, Integrationen mit Legacy-Systemen. Der Migrations-Umfang ist wirklich groß.
  4. "Budget wurde nicht genehmigt." Die ehrlichste Antwort und die häufigste.

Keiner dieser Gründe ist verschwunden, aber die Deadline kam an. Also lass mich darüber sprechen, was du wirklich tun solltest.

Deine Migrations-Optionen 2026

Du hast vier realistische Wege nach vorne. Jeder hat Trade-offs. Lass mich sie ehrlich aufschlüsseln.

| Option | Timeline | Kostenbereich | Best für | Risiko-Level | |--------|----------|-----------|----------|------------|| | Drupal 10/11 | 6-18 Monate | $200K-$1M+ | Teams, die im Drupal-Ökosystem investiert sind | Mittel | | Headless Frontend + Drupal Backend | 4-12 Monate | $150K-$600K | Teams, die modernes UX mit vertrautem CMS wollen | Mittel | | Headless CMS-Migration | 3-9 Monate | $100K-$500K | Teams, die Drupal ganz verlassen wollen | Mittel-Hoch | | Extended Support Vendor | Sofort | $30K-$100K/Jahr | Teams, die 6-18 Monate mehr Planungszeit brauchen | Niedrig (kurzfristig) |

Drupal 7 End of Life 2025: Migrations-Leitfaden für Enterprise-Teams - Architektur

Option 1: Migration zu Drupal 10/11

Drupal 10 ist ab 2026 die aktuelle Stable Release, mit Drupal 11, das Mitte 2024 veröffentlicht wurde und starke Akzeptanz gewinnt. Wenn dein Team Drupal kennt, dein Content-Modell solid ist und du im Ökosystem bleiben möchtest, ist das der direkteste Weg.

Aber "direktest" bedeutet nicht "einfach".

Was die Migration wirklich beinhaltet

Drupal bietet eine Migrate API, die Content aus einer Drupal 7-Datenbank in eine Drupal 10/11-Site ziehen kann. Nach meiner Erfahrung behandelt sie etwa 60-70% einer typischen Migration. Der Rest sind Custom Migration Plugins für:

  • Custom Field Types
  • Komplexe Entity References
  • Paragraphs (falls du das Paragraphs-Modul benutzt hast)
  • File und Media Assets
  • URL-Aliase und Redirects
  • User Accounts und Roles

Deine Custom Modules müssen neu geschrieben werden. Nicht portiert – neu geschrieben. Drupal 10/11 nutzt eine völlig andere Architektur. Wenn du ein Custom Module hattest, das in hook_node_view() gehakt hat, schreibst du jetzt Event Subscriber und Plugins.

// Drupal 7 - hook-basiert
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-basiert
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') {
      // Deine Logik hier
    }
  }
}

Die Twig-Templating-Schicht ist auch völlig anders als PHPTemplate. Jedes Custom Theme muss neu gebaut werden.

Realistische Timeline

Für eine mittelgroße Enterprise-Site (500-5.000 Seiten, 10-20 Content Types, 5-10 Custom Modules) rechne mit 9-15 Monaten. Das beinhaltet Discovery, Content Modeling, Development, Content Migration, QA und Launch.

Option 2: Headless mit modernem Frontend

Hier wird es interessant, und ehrlich gesagt ist das der Ansatz, den ich 2026 für die meisten Enterprise-Teams empfehle. Halte Drupal als dein Content-Backend (aktualisiert auf Drupal 10/11), baue aber das Frontend mit einem modernen JavaScript-Framework.

Drupal 10/11 hat ausgezeichnete JSON:API-Unterstützung, die in Core eingebaut ist. Du kannst deinen Content als strukturierte Daten exponieren und ihn mit Next.js, Astro oder einem beliebigen Frontend-Framework nutzen.

Warum dieser Ansatz gut funktioniert

  • Dein Editorial-Team behält die Drupal-Admin-Schnittstelle. Sie kennen sie. Sie sind produktiv darin. Das abzureißen verursacht organisatorische Schmerzen.
  • Dein Frontend wird dramatisch schneller. Static Generation, Edge Caching, moderne Bild-Optimierung – Dinge, die schmerzhaft sind, auf Drupals Rendering-Schicht zu montieren.
  • Du kannst inkrementell migrieren. Stelle das neue Frontend neben der alten Site auf und migriere Abschnitte nacheinander.

Wir haben mehrere Headless Drupal Frontends mit Next.js und Astro gebaut, und die Performance-Verbesserungen sind erheblich. Ein Client sah seinen Largest Contentful Paint von 4,2s auf 0,8s fallen, nachdem er zu einem Next.js-Frontend mit ISR (Incremental Static Regeneration) umgestiegen war.

// Next.js-Seite abrufen von Drupals 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: regeneriere alle 60 Sekunden
  };
}

Das next-drupal-Paket (gepflegt von Chapter Three) macht das noch einfacher mit eingebauter Unterstützung für Preview-Modus, Authentifizierung und Content Type Mapping.

Der Haken

Du musst immer noch Drupal 7 auf Drupal 10/11 auf dem Backend migrieren. Du vermeidest diese Arbeit nicht. Aber du entkoppelst sie vom Frontend-Rebuild, was dir mehr Flexibilität in der Sequenzierung gibt.

Option 3: Kompletter Wechsel zu Headless CMS

Manchmal ist der richtige Schritt, Drupal komplett zu verlassen. Wenn dein Team keine starke Drupal-Expertise hat, wenn du Mühe hast, Drupal-Entwickler zu finden (und das tust du – der Drupal-Talent-Pool ist seit 2020 erheblich geschrumpft), oder wenn dein Content-Modell über das hinausgegangen ist, was Drupal gut macht, könnte ein Headless CMS der richtige Weg sein.

Beliebte Migrations-Ziele

| CMS | Preise (2026) | Best für | Content API | Learning Curve | |-----|----------------|----------|-------------|----------------|| | Contentful | $300-$2.500+/mo | Große Editorial-Teams | GraphQL + REST | Mittel | | Sanity | $99-$949+/mo (custom enterprise) | Developer-led Teams | GROQ + GraphQL | Low-Mittel | | Storyblok | $109-$449+/mo | Visual Editing Needs | REST + GraphQL | Niedrig | | Strapi (self-hosted) | Kostenlos (self-hosted) / $29+/mo (cloud) | Teams, die Kontrolle wollen | REST + GraphQL | Mittel | | Payload CMS | Kostenlos (self-hosted) / $35+/mo (cloud) | TypeScript-First Teams | REST + GraphQL | Mittel |

Wir arbeiten über unsere Headless CMS Development Practice mit mehreren davon. Die richtige Wahl hängt von den technischen Fähigkeiten deines Teams, Content-Komplexität und Budget ab.

Content-Migration von Drupal 7 zu einem Headless CMS

Das ist in mancher Hinsicht tatsächlich einfacher als die Migration zu Drupal 10/11. Du bist nicht durch Drupals Migration Framework beschränkt. Der typische Ansatz:

  1. Exportiere Drupal 7-Content über Drush oder direkte Datenbank-Abfragen
  2. Transformiere die Daten in dein Ziel-CMS-Content-Modell mit Scripts (Python und Node.js funktionieren beide gut)
  3. Importiere über die API des CMS Management
  4. Verifiziere und fixe References, Media und Relationships
# Einfacher Drupal 7-Content-Export via Datenbank
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")

Die schwierige Aufgabe ist nicht der Export. Es ist, Drupals Content-Modell (mit seinem Field-System, Entity References, Taxonomy Terms und Paragraphs) zu den Datenstrukturen eines neuen CMS zu mappen. Plane, dass das bedeutende Analyse-Zeit braucht.

Option 4: Extended Support Vendors (Zeit kaufen)

Wenn du wirklich mehr Zeit brauchst – und manchmal tust du das, besonders bei Budget-Zyklen und organisatorischen Prioritäten – können Extended Support Vendors deine Drupal 7-Site gepatchet halten, während du planst.

Wichtige Vendors mit Drupal 7 Extended Support

  • Tag1 Consulting – Einer der etabliertesten. Sie portieren Sicherheits-Patches zurück und bieten laufende Wartung. Die Preise variieren je nach Site-Komplexität, aber erwarte $30K-$80K/Jahr.
  • Acquia – Bietet Extended Drupal 7-Support über ihre Plattform an, aktuell bis 2026 für Enterprise-Kunden.
  • mySociety / D7 LTS Contributors – Community-driven Extended Support über das Drupal 7 Extended Support Programm.

Das ist eine legitime Brücken-Strategie, nicht eine langfristige Lösung. Ich würde sie auf maximal 12-18 Monate begrenzen. Mit jedem Monat, den du auf Drupal 7 bleibst, wird deine Migrations-Komplexität größer, da die Lücke zwischen D7 und modernen Plattformen wächst.

Migrations-Planung: Ein Schritt-für-Schritt-Framework

Hier ist das Framework, das ich bei jeder Enterprise-Migration nutze. Es ist nicht glamourös, aber es funktioniert.

Phase 1: Audit (2-4 Wochen)

  • Content Audit: Wie viele Content Types? Wie viele Nodes pro Type? Wie komplex ist das Content-Modell? Nutzt du Paragraphs, Field Collections, Entity Reference?
  • Module Audit: Liste jedes Contrib und Custom Module auf. Kategorisiere als: hat D10 Äquivalent, braucht Custom Replacement, kann eliminiert werden. Ich nutze drush pm:list --status=enabled und cross-reference mit drupal.org.
  • Integration Audit: Mit welchen externen Systemen spricht Drupal? Payment Gateways, CRMs, Marketing Automation, SSO Providers?
  • Traffic und Performance Baseline: Dokumentiere aktuelle Performance-Metriken. Du brauchst diese zum Vergleich.
  • User Role Audit: Wie viele Editorial Workflows existieren? Welche Berechtigungen sind wichtig?

Phase 2: Architecture Decision (2-3 Wochen)

Basierend auf deinem Audit, entscheide, welche der vier Optionen richtig ist. Das ist eine echte Architektur-Entscheidung, die Engineering Leadership, Content Stakeholder und wer immer das Budget kontrolliert, einbeziehen sollte.

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

Vor der Verpflichtung zu einer vollständigen Migration, baue einen Proof of Concept, der abdeckt:

  • 2-3 Content Types migriert zur neuen Plattform
  • Der komplexeste Editorial Workflow reproduziert
  • Eine kritische Integration verbunden
  • Performance-Benchmarks auf dem neuen Stack

Hier entdeckst du die Dinge, die niemand während des Audits erwähnt hat. Es gibt immer etwas.

Phase 4: Full Migration (3-12 Monate)

Das ist die echte Arbeit. Priorisiere rücksichtslos. Nicht alles von Drupal 7 muss mitkommen. Nach meiner Erfahrung können 20-30% des Contents und der Funktionalität auf einer typischen Enterprise Drupal 7-Site während der Migration eliminiert werden.

Phase 5: QA und Launch (2-4 Wochen)

Redirects sind kritisch. Jede URL auf deiner Drupal 7-Site, die Search-Equity hat, braucht einen 301-Redirect zur neuen Site. Nutze path_redirect und globalredirect-Modul-Exporte als Anfang, dann crawl die alte Site mit Screaming Frog, um eine komplette Redirect-Map zu bauen.

Content-Migrations-Strategie

Content-Migration verdient seinen eigenen Abschnitt, denn hier gehen die meisten Migrationen schief.

Das Body-Field-Problem

Drupal 7 Body-Fields sind typisch ein Chaos aus HTML. Du findest Inline-Styles, hardcodierte Bild-Pfade, eingebettete iframes und gelegentlich roh PHP (falls jemand das PHP-Filter-Modul aktiviert hat – ein echtes Security-Horror). Vor der Migration musst du entscheiden: bereinigen oder das Chaos portieren?

Meine Empfehlung: bereinige es. Schreibe Transformation-Scripts, die:

  • Inline Styles strippen
  • <img>-Tags zu proper Media References konvertieren
  • Interne Links zur neuen URL-Struktur fixieren
  • Beliebige WYSIWYG-Embed-Tokens ins neue Format konvertieren

Media-Migration

Drupal 7-Sites behandeln Media auf wildly unterschiedliche Weisen. Einige nutzen das Media-Modul (1.x oder 2.x), einige nutzen plain File Fields, einige nutzen eingebettete Media Tokens in Body-Fields. Mappe jedes Media-Handling-Pattern, bevor du anfängst, Migration-Code zu schreiben.

Wenn du zu einem Headless CMS ziehst, musst du auch entscheiden, wo Media-Files leben. Die meisten Headless CMSs haben eingebaute Asset Management oder du kannst ein DAM wie Cloudinary oder imgix nutzen.

Mehrsprachiger Content

Wenn deine Drupal 7-Site i18n, entity_translation oder content_translation nutzt, verdoppelt sich die Migrations-Komplexität ungefähr. Drupals Multilingual System war... nennen wir es "kreativ". Die Datenstrukturen sind inkonsistent und erfordern sorgfältiges Mapping.

Kosten- und Timeline-Schätzungen

Ich gebe dir echte Zahlen basierend auf Projekten, die ich beteiligt war oder direktes Wissen von habe.

| Site-Komplexität | Drupal 10/11 Migration | Headless CMS Migration | Headless Frontend + Drupal Backend | |----------------|----------------------|----------------------|-----------------------------------|| | Klein (5-10 Content Types, <1K Seiten, 2-3 Custom Modules) | $80K-$150K, 3-6 Monate | $60K-$120K, 2-4 Monate | $100K-$180K, 3-6 Monate | | Mittel (10-20 Content Types, 1K-10K Seiten, 5-10 Custom Modules) | $200K-$500K, 6-12 Monate | $150K-$350K, 4-8 Monate | $200K-$450K, 5-10 Monate | | Groß (20+ Content Types, 10K+ Seiten, 10+ Custom Modules, Mehrsprachig) | $500K-$1,5M+, 12-24 Monate | $300K-$800K, 6-14 Monate | $400K-$1M+, 8-18 Monate |

Das sind voll beladene Kosten inklusive Discovery, Development, Migration, QA und Project Management. Deine Ergebnisse variieren basierend auf Team-Zusammensetzung (in-house vs. Agency), geografischer Lage und wie viel Cleanup du machst vs. As-Is portierst.

Möchtest du eine spezifischere Schätzung für deine Situation erhalten? Wir machen Migrations-Assessments, die dir ein klares Bild von Umfang und Kosten geben.

Häufige Fehler, die ich Teams machen sehe

Versuchung einer 1:1 Rekonstruktion. Deine Drupal 7-Site hat über 10+ Jahre Müll angesammelt. Migriere nicht alles davon. Nutze die Migration als Gelegenheit zu vereinfachen.

Unterschätzung des Redirect-Aufwands. Ich arbeitete bei einer Migration, wo das Team Redirects bis zwei Wochen vor dem Launch vergaß. Sie hatten 45.000 URLs zu mappen. Sei nicht dieses Team.

Editorial Stakeholder nicht früh genug einbeziehen. Die Leute, die das CMS täglich nutzen, werden starke Meinungen über das neue System haben. Beziehe sie in Phase 1 ein, nicht Phase 4.

Platform basierend auf Features wählen, nicht Team-Fähigkeit. Das beste CMS ist das, das dein Team wirklich maintainnen kann. Falls du keine Drupal-Expertise hast, zu Drupal 10/11 zu migrieren ohne dafür einzustellen ist Setup für ein Repeat dieser Situation in 5 Jahren.

Parallele Systeme zu lange laufen. Setze ein hartes Cutover-Datum. Alte und neue parallel zu laufen ist teuer und verwirrend.

Content Freeze überspringen. Während der finalen Migrations-Push brauchst du einen Content Freeze auf der alten Site. Plane dafür. Kommuniziere es. Content Authors hassen es, aber es ist notwendig, um sicherzustellen, dass nichts verloren geht.

FAQ

Was passiert, wenn ich Drupal 7 nach dem End of Life weiter betreibe?

Deine Site wird nicht plötzlich aufhören zu funktionieren. Aber du erhältst keine Sicherheits-Patches, was bedeutet, dass alle neu entdeckten Sicherheitslücken für immer ungepatchted bleiben. Das ist ein echtes Risiko – Drupal-Sites sind häufige Ziele für automatisierte Angriffe. Du wirst auch zunehmende Kompatibilitätsprobleme erfahren, wenn PHP-Versionen vorankommen und Hosting Provider Support für ältere PHP-Versionen einstellen. Für jede Organisation mit Compliance-Anforderungen (PCI, HIPAA, SOC 2, GDPR) ist das Betreiben von ununterstützter Software eine direkte Violation.

Kann ich direkt von Drupal 7 zu Drupal 11 upgraden?

Ja, die Migrate API unterstützt direkte Migration von Drupal 7 zu Drupal 10 oder 11. Du musst nicht Drupal 8 und 9 durchlaufen. Allerdings ist das kein "Upgrade" im traditionellen Sinne – es ist ein Rebuild deiner Site auf der neuen Plattform mit Content migriert. Deine Themes, Custom Modules und Konfigurationen tragen nicht direkt über.

Wie lange dauert eine typische Drupal 7-Migration?

Für eine mittelgroße Enterprise-Site, plane 6-12 Monate vom Kickoff zum Launch. Kleinere Sites mit limitierter Custom-Funktionalität können in 3-4 Monaten erledigt sein. Große, komplexe Sites mit mehrsprachigem Content, umfangreichen Integrationen und schwerer Customization können 12-24 Monate dauern. Die Audit-Phase gibt dir eine viel genauere Schätzung für deine spezifische Situation.

Ist es der Wert wert, zu Drupal 10/11 zu migrieren, oder sollte ich CMS-Plattformen wechseln?

Es kommt auf dein Team und deine Bedürfnisse an. Falls du Drupal-Expertise im Haus hast, dein Content-Modell ist gut für Drupals Entity-System geeignet, und du brauchst Drupals Stärken (komplexe Berechtigungen, mehrsprachig, Multi-Site), dann im Ökosystem zu bleiben ergibt Sinn. Falls du Mühe hast, Drupal-Entwickler zu finden, deine Site ist primär eine Marketing-Site ohne komplexe Editorial-Workflows, oder du möchtest zu einer Headless-Architektur wechseln, könnte ein anderes CMS die bessere Investition sein.

Was ist die billigste Option, um von Drupal 7 wegzumigrieren?

Extended Support von einem Vendor wie Tag1 ($30K-$80K/Jahr) ist die billigste kurzfristige Option, aber löst das untergeordnete Problem nicht. Für echte Migration, zu einem Headless CMS wie Sanity oder Storyblok mit statischem Frontend zu wechseln, ist tendenziell der kosteneffektivste Weg für einfachere Sites, startend bei $60K-$120K. Checke unsere Pricing-Seite für mehr Details darauf, wie wir Migrations-Projekte strukturieren.

Werden meine SEO-Rankings von der Migration beeinflusst?

Sie können sein, aber proper Planung minimiert den Impact. Die kritischen Faktoren sind: URL-Strukturen behalten (oder proper 301-Redirects für jede indexed URL implementieren), Meta Data und Structured Data Markup bewahren, sicherstellen, dass die neue Site mindestens so schnell lädt wie die alte (idealerweise schneller), und aktualisierte Sitemaps zu Google Search Console submittieren. Ich habe gut ausgeführte Migrationen erlebt, die zu SEO-Verbesserungen führten wegen besserer Page Speed und Mobile Experience. Ich habe auch botched Migrationen erlebt, die Traffic um 50% tanken, weil jemand die Redirects vergaß.

Kann ich Content inkrementell oder muss es alles auf einmal sein?

Inkrementelle Migration ist möglich und oft vorzuziehen für große Sites. Mit einer Headless-Architektur, kannst du das neue Frontend aufstellen und Site-Abschnitte nacheinander migrieren, mit Reverse Proxy Regeln zum Routen von Traffic zum geeigneten Backend. Das reduziert Risiko und lässt dich jeden Abschnitt vor dem Weitermachen validieren. Der Trade-off ist erhöhte Operational Komplexität während der Migrationsperiode.

Sollte ich WordPress als Migrations-Ziel betrachten?

WordPress ist eine viable Option für einfachere Sites, aber ich würde bei Enterprise-Use Cases vorsichtig sein. Falls deine Drupal 7-Site komplexe Content Types, granular Berechtigungen oder anspruchsvolle Editorial-Workflows hat, wird WordPress sich wie ein Downgrade anfühlen. Drupals Entity-System ist komplexer als das Content-Modell von WordPress (Posts, Pages und Custom Post Types). Für Enterprise-Teams würde ich ernstlicher auf Drupal 10/11 oder ein proper Headless CMS schauen. Das gesagt, kann WordPress mit ACF Pro und einem Headless Frontend gut für Marketing-fokussierte Sites funktionieren.