Ihr Staging-Server beendet den TYPO3-Cache-Rebuild — dreiundvierzig Sekunden für eine Inhaltsänderung, die zwei Sekunden dauern sollte. Ihr Frontend-Dev aktualisiert den Browser, sieht die Änderung und murmelt etwas über TypoScript, das Sie wahrscheinlich nicht in der Standup wiederholen sollten. Diese Szene spielt sich täglich in Unternehmen in ganz Europa ab, wo TYPO3 zwei Jahrzehnte lang Regierungsportale und Corporate Sites betrieben hat. Das CMS funktioniert technisch immer noch. Aber Drupals komponentenorientierte Architektur, sein Headless-Toolkit und eine zehnmal größere Contributor-Basis machen das Migrations-Gespräch unvermeidlich. Die Frage ist nicht, ob man umsteigen sollte — sondern wie man 8.000 Seiten migriert, zwanzig Jahre URL-Equity bewahrt und die Content-Editoren während der Umstellung bei Verstand hält. Wir haben dieses Szenario in den letzten achtzehn Monaten sechsmal durchgespielt, und der Unterschied zwischen einer sauberen Migration und einer Katastrophe hängt von vier Entscheidungen ab, die Sie in der ersten Woche treffen.

Ich habe mich in den letzten Jahren in einigen TYPO3-zu-Drupal-Migrationen bis zum Hals eingegraben und war ganz schön überrascht, echte Content-Modelle zu entwirren. Sie sind normalerweise ein wirres Durcheinander. Diese Anleitung ist das, was ich mir vor meiner ersten Migration hätte geben wollen. Ich werde alle technischen Details, wichtige Planungsschritte und jene nervigen Fallstricke abdecken, die Ihren Zeitplan torpedieren können, wenn Sie nicht aufpassen.

Inhaltsverzeichnis

TYPO3 zu Drupal Migration: Ein praktischer Leitfaden für Entwickler

Warum Organisationen TYPO3 verlassen

Sein wir ehrlich: TYPO3 ist kein schlechtes CMS. Es ist unglaublich flexibel, handhabt Multi-Site und mehrsprachige Setups nativ und rühmt sich einer treuen Anhängerschaft, besonders in der DACH-Region. Warum springen die Leute also ab?

Ich höre pretty much immer die gleichen Gründe:

Verfügbarkeit von Entwicklern. Außerhalb von Mitteleuropa ist es genauso schwierig, TYPO3-Entwickler zu finden, wie eine Nadel im Heuhaufen zu suchen. Drupal hingegen beansprucht etwa 1,3 Millionen Entwickler weltweit, laut Drupal.org's 2024-Bericht. TYPO3? Nicht so sehr. Wenn Ihre Senior-TYPO3-Devs ihre Sachen packen und gehen, könnte es eine Ewigkeit dauern, diese Stellen zu besetzen.

Ökosystem-Momentum. Mit der Veröffentlichung von Drupal 11 Ende 2024 gab es riesige Fortschritte in der Admin UI, ein neues Recipes-System und erstklassige API-First-Fähigkeiten. Sicher, TYPO3 v13 ist solide, aber die Innovationsrate in Drupal, besonders rund um Headless-Setups, ist deutlich schneller.

Headless/Decoupled-Architektur. Planen Sie, Inhalte einem schicken Next.js oder Astro Frontend zu servieren? Drupals JSON:API und GraphQL Plugins sind bewährte Profis. TYPO3 hat seine eigene Headless-Extension, aber sie ist weniger reif und hat weniger Unterstützung.

Gesamtkostenaufwand. TYPO3 zu hosten kostet normalerweise mehr. Die spezialisierte Infrastruktur bedeutet, dass Sie am Ende mehr bezahlen könnten. Drupal läuft pretty much überall von Pantheon bis Acquia, sogar ein einfaches LAMP Stack lässt es schnurren.

TYPO3 vs Drupal: Ein ehrlicher Vergleich

Vor dem kopflosen Sprung stellen Sie sicher, dass Drupal wirklich Ihre Probleme lösen wird. Hier die Fakten ab 2026:

Feature TYPO3 v13 Drupal 11
Content Modeling Flexibel aber orientiert sich an TCA Entity/Field System mit Field Management UI
Mehrsprachigkeit Hervorragende native Unterstützung Gleichfalls hervorragende native Unterstützung
Multi-Site Standard Multi-Site mit Content Trees Möglich, oft besser mit Domain Access oder separaten Instanzen
Headless/API Hat eine Headless-Extension JSON:API Core, GraphQL Contrib
Templating Fluid Templates + TypoScript Twig Templates
Extension/Module Ökosystem ~1.800 Extensions auf TER ~50.000+ Module auf Drupal.org
Admin UI Stark, aber veraltet (bekommt in v13 ein Makeover) Elegant und modern in Drupal 11
Developer Community ~500 aktive Contributors 8.000+ aktive Contributors
Hosting-Optionen Self-hosted oder spezialisiert Self-hosted, Pantheon, Acquia, Platform.sh, Lagoon
PHP Anforderung PHP 8.2+ PHP 8.3+
Typische Agenturrate €100-180/Std (DACH-Region) $80-200/Std (global)

TYPO3s Page-Tree-Modell ist ein seltener Edelstein. Editoren, die an der Verwaltung aufwändiger Page-Hierarchien in TYPO3 hängen, könnten Drupals Stil — die Kombination von Content Types und Taxonomie — als gewöhnungsbedürftig empfinden. Planen Sie einige Editor-Trainings, um den Übergang zu glätten.

Pre-Migration Audit und Planung

Diese Phase bestimmt das Schicksal der meisten Migrationen. Die Planung, nicht die technischen Zeiten, entscheidet alles.

Content-Bestand

Beginnen Sie mit der Prüfung alles in Ihrem TYPO3-Setup:

  • Seiten: Extrahieren Sie den Page Tree und dokumentieren Sie jeden doktype (Seitentyp), den Sie haben.
  • Content-Elemente: Jeden CType (Content Type) müssen Sie beachten — sei es Text, Text mit Bild, HTML oder Custom-Zeug via mask oder content_defender.
  • Extensions: Notieren Sie jede Extension, die Sie haben. Finden Sie heraus, ob es ein Drupal-Äquivalent gibt.
  • Dateireferenzen: TYPOs FAL (File Abstraction Layer) handhabt Medien. Mappen Sie diese zu Drupals Media-Spots.
  • Backend-Benutzer und Berechtigungen: TYPOs intricate Backend-Benutzergruppen mit Seite und Feld-Level Zugriff sollten ordentlich zu Drupal-Rollen und Berechtigungen übersetzt werden.

Hier ist eine hilfreiche SQL-Abfrage für einen Content-Element-Überblick aus Ihrer TYPO3-Datenbank:

SELECT CType, COUNT(*) as count 
FROM tt_content 
WHERE deleted = 0 AND hidden = 0 
GROUP BY CType 
ORDER BY count DESC;

Damit bekommen Sie einen schnellen Überblick über die Content Types, mit denen Sie es zu tun haben. In einem Fall entdeckte ich eine TYPO3-Instanz mit über 40 Custom Content Element Types, von denen nur ein Dutzend aktiv genutzt wurde. Ziehen Sie nicht tote Last über.

Was behalten, was löschen

Hier ist Ihre Chance, Haus zu machen. Verwenden Sie ein Content Audit Tool wie Screaming Frog oder Sitebulb, um zu finden:

  • Seiten ohne Traffic in den letzten Jahr
  • Doppelte oder quasi-identische Inhalte
  • Fehlerhafte interne Links
  • Verwaiste Media-Dateien

Typischerweise gibt es einen 30-50% Content-Cut bei großen TYPO3-Migrationen. Weniger Seiten bedeuten schnellere Migrationen.

TYPO3 zu Drupal Migration: Ein praktischer Leitfaden — Architektur

Content Modeling: TYPO3 zu Drupal mappen

Krempeln Sie die Ärmel hoch. Das ist die schwere intellektuelle Arbeit. TYPO3 und Drupal handhaben Inhalte sehr unterschiedlich.

TYPOs Modell

TYPO3 dreht sich um Seiten. Alles ist in einem Page Tree versteckt. Content-Elemente (Records in tt_content) sitzen auf Seiten in Spalten (colPos). Custom Records, die durch Extbase-Modelle oder TCA definiert sind, sitzen in separaten Tabellen, werden aber normalerweise von Seiten verlinkt.

Drupals Modell

Drupal ist alles über Entities. Sie erstellen Content Types (Node Bundles), jeweils mit dedizierten Feldern. Seiten sind nur einer unter vielen Content Types. Taxonomie, Paragraphen (mit dem Paragraphen-Modul) und Layout Builder beherrschen die strukturierte Content-Zusammenstellung.

Das Mapping

Hier ist eine typische Zuordnungstabelle, die ich als Kompass verwende:

TYPO3-Konzept Drupal-Äquivalent
Page (doktype: standard) Node (Content Type: Page)
Page (doktype: shortcut) URL-Umleitung
Page (doktype: link) Node mit Link-Feld oder Umleitung
Content Element (CType: text) Paragraph Type oder Body Field
Content Element (CType: image) Media Entity Reference
Content Element (CType: textpic) Paragraph Type mit Text + Media
Content Element (CType: gridelements) Layout Builder Section
FAL Dateireferenz Media Entity
sys_category Taxonomy Term
fe_users Drupal User Entity
be_users Drupal User Entity mit Admin-Rolle
TypoScript Template Twig Template
Extbase Plugin Custom Drupal Module
Mask/DCE Content Elements Paragraph Types

Die größte Verschiebung? Content-Elemente zu Paragraphen verschieben. TYPO3 stapelt Content-Elemente in Seiten-Spalten, was sich gut zum Drupal-Paragraphen-Modul abbildet. Editoren stapeln Seiten aus wiederverwendbaren Paragraph-Typen — es ist überraschend nahtlos.

Migration Tooling und technischer Ansatz

Drupals Migrate API rockt. Aber Heads-up, es fehlt ein natives TYPO3-Source-Plugin. Sie müssen benutzerdefinierte Source-Plugins zusammenbauen, um aus TYPO3s Datenbank zu ziehen.

Ansatz 1: Direkte Datenbankmigration

Stöpseln Sie Drupals Migrate API direkt in Ihre TYPO3 MySQL/MariaDB Datenbank:

// Beispiel Migrate Source Plugin für TYPO3 Seiten
namespace Drupal\typo3_migrate\Plugin\migrate\source;

use Drupal\migrate\Plugin\migrate\source\SqlBase;
use Drupal\migrate\Row;

/**
 * @MigrateSource(id = "typo3_pages")
 */
class Typo3Pages extends SqlBase {

  public function query() {
    return $this->select('pages', 'p')
      ->fields('p', ['uid', 'title', 'slug', 'abstract', 'doktype', 'crdate', 'tstamp'])
      ->condition('p.deleted', 0)
      ->condition('p.hidden', 0)
      ->condition('p.doktype', [1, 4], 'IN');
  }

  public function fields() {
    return [
      'uid' => $this->t('Seiten-ID'),
      'title' => $this->t('Seitentitel'),
      'slug' => $this->t('URL-Slug'),
      'abstract' => $this->t('Abstract/Zusammenfassung'),
    ];
  }

  public function getIds() {
    return ['uid' => ['type' => 'integer']];
  }

  public function prepareRow(Row $row) {
    // Lade assoziierte Content-Elemente
    $pid = $row->getSourceProperty('uid');
    $content = $this->select('tt_content', 'tt')
      ->fields('tt')
      ->condition('tt.pid', $pid)
      ->condition('tt.deleted', 0)
      ->orderBy('tt.sorting')
      ->execute()
      ->fetchAll();
    $row->setSourceProperty('content_elements', $content);
    return parent::prepareRow($row);
  }
}

Ich mag diesen Ansatz. Es geht darum, volle Kontrolle zu haben und erlaubt Ihnen, TYPOs Eigenheiten (wie Soft-Deletes und Workspace Overlays) in Ihrem Code zu handhaben.

Ansatz 2: Export/Import via JSON oder XML

Einige Teams wählen den Export von TYPO3-Inhalten in strukturierte Formate (etwa durch benutzerdefinierte TYPO3-Extensions oder CLI-Befehle) und importieren sie dann in Drupal. Sicher, es fügt eine weitere Schicht hinzu, aber es ist praktisch, wenn Sie Bedenken haben, während der Migration direkte Datenbankverbindungen zu pflegen.

Ansatz 3: Hybrid mit manuellem Review

Haben Sie eine kleinere Site (unter 500 Seiten)? Automatische Migration von strukturierten Daten durchführen während Sie Key Landing Pages von Hand erstellen, kann wunderbar funktionieren. Es mag simpel klingen, aber wenn Inhalte mit TYPOs spezifischer Rendering-Logik verflochten sind, führt automatisierte Migration oft zu Nonsense.

Umgang mit TYPO3 TypoScript und Extensions

TypoScript

Lasst mich klar werden: TypoScript wird nicht migriert. Es ist eine TYPO3-spezifische Konfigurationssprache ohne wirkliches Äquivalent anderswo. Ihre Aufgabe ist es, zu dokumentieren, was jedes TypoScript-Template in Laiensprache macht, und es dann als Twig-Templates und Drupal-Config wieder aufzubauen. Es ist mühsam aber notwendig.

Extensions

Hier ist ein praktischer Vergleich häufiger TYPO3-Extensions und ihrer Drupal-Äquivalente:

TYPO3 Extension Drupal Äquivalent
news Core Content Type + Views
powermail Webform Module
solr (ext:solr) Search API + Solr
realurl / routing Pathauto + Core Routing
gridelements Layout Builder oder Paragraphs
mask Paragraphs
tt_address Custom Content Type oder CiviCRM
ke_search Search API
femanager User Module + Custom
cal/events Custom Content Type + Views

Benutzerdefinierte Extbase-Extensions müssen als Drupal-Module umgeschrieben werden. Es gibt keine Abkürzungen — budgetieren Sie dafür.

URL-Struktur und SEO-Erhaltung

Wenn Sie das vermasseln, verlieren Sie organischen Traffic. Ich habe Organisationen gesehen, die aufgrund von missghandelten Umleiterungen bis zu 40% ihres Suchverkehrs nach der Migration verloren haben.

Schritte

  1. Exportieren Sie alle URLs aus TYPO3. Verwenden Sie ein CLI-Tool oder Crawler für jede indexierte URL.
  2. Mappen Sie diese zu Drupal-URLs. Verwenden Sie Drupals Pathauto für URL-Alias-Generierung, bleiben Sie nah bei bestehenden URLs.
  3. Erstellen Sie Umleitungen für alles, das sich ändert. Deployen Sie das Redirect Module in Drupal. Für Berge von Umleitungen, importieren via CSV.
  4. Handhaben Sie Sprachpräfixe. TYPO3 benutzt /de/, /en/, /fr/ — stellen Sie sicher, dass Drupals Spracheinstellungen dies widerspiegeln.
  5. Unterbreiten Sie aktualisierte Sitemaps sofort an Google Search Console.
# Beispiel Umleitung Import CSV Format für Drupals Redirect Module
source,redirect,status_code,language
/alte-seite,/new-page,301,de
/old-page/subpage,/new-page/subpage,301,en
/kontakt,/contact,301,de

Pro Tipp: Halten Sie die alte TYPO3-Instanz live, wenn auch Read-Only, für mindestens drei Monate nach der Migration. Sie werden verpasste URLs entdecken.

Nach der Migration Headless gehen

Drupal leuchtet mit seinem Weg zu einem decoupled Frontend. Mit Drupal 11 ist das JSON:API Module solide wie ein Stein, und das Headless Drupal Ökosystem floriert.

Wenn Sie über einen Headless-Ansatz nachdenken — und 2026, für die meisten inhaltsgesteuerten Sites, ist es einen Überlegung wert — haben wir das gründlich bei /solutions/headless-cms-development behandelt.

Verkupplung beliebter Frontends mit Drupal:

Die Schönheit des ersten Migrierens zu Drupal ist das Launch mit Drupals Standard Twig Frontend. Später können Sie zu einem decoupled wechseln. Versuchen Sie nicht, beide Moves gleichzeitig — das ist eine Aufforderung zu Projekt-Chaos.

Timeline, Kosten und Personalbudget

Echte Zahlen aus Projekten, an denen ich beteiligt war, oder von denen ich genaue Daten habe (aktuelle Jahre):

Site-Größe Seiten Timeline Budget-Range Team
Klein <500 Seiten 2-3 Monate €25.000-50.000 2-3 Entwickler
Mittel 500-5.000 Seiten 4-6 Monate €50.000-120.000 3-5 Entwickler
Groß 5.000-50.000 Seiten 6-12 Monate €120.000-320.000 5-8 Entwickler
Enterprise 50.000+ Seiten 12-18 Monate €320.000-800.000+ 8-15 Entwickler

Diese umfassen alles von Discovery, Content Modeling, Migration, Frontend Theming, QA und Editor-Training. Laufende Wartung ist hier nicht enthalten.

Der große Kostenfaktor ist nicht nur die Seitenzahl — es ist die Komplexität. Eine 2.000-Seiten-Site mit 30 benutzerdefinierten Content Types und 4 Sprachen wird mehr kosten als eine einfache 10.000-Seiten-Site.

Details für Ihren Fall berücksichtigen? Sehen Sie sich /pricing an oder kontaktieren Sie uns direkt.

Post-Migration Checkliste

Überspringen Sie diese Checkliste nicht. Vertrau mir.

  • Verifizieren Sie alle Umleitungen. Stellen Sie sicher, dass sie 301s sind.
  • Aktualisieren Sie Google Search Console mit Ihrer neuen Sitemap.
  • Testen Sie alle Formulare: Kontakt, Newsletter, Login.
  • Stellen Sie Mehrsprachige Content-Genauigkeit für jede Sprache sicher.
  • Migrieren Sie Media-Dateien ordnungsgemäß mit Alt-Text und Metadaten.
  • Überprüfen Sie Editor-Berechtigungen für jede Rolle.
  • Erfassen Sie Performance Metriken (Core Web Vitals).
  • Verifizieren Sie Analytics Tracking (GA4 Events, Goals).
  • Konfigurieren und testen Sie CDN/Caching.
  • Aktivieren Sie Security Headers (CSP, HSTS).
  • Testen Sie Backup- und Disaster Recovery Systeme.
  • Schließen Sie Editor-Training ab und liefern Sie Dokumentation.
  • Halten Sie die alte TYPO3-Instanz im Read-Only-Modus verfügbar.

FAQ

Wie lange dauert typischerweise eine TYPO3-zu-Drupal-Migration?


Für mittelgroße Sites (500-5.000 Seiten) sind es etwa 4-6 Monate von Start bis Launch. Der erste Monat? Rein Discovery und Content Modeling. Migration Scripting dauert normalerweise 6-8 Wochen Arbeit. QA und Editor-Training? Rechnen Sie mit einem weiteren Monat. Wenn es ein komplexes mehrsprachiges, Multi-Site Setup mit benutzerdefinierten Extensions ist, rechnen Sie mit 9-12 Monaten.

Kann ich TYPO3-Inhalte automatisch migrieren, oder ist es manuell?


Strukturierte Inhalte wie Seiten, News-Records oder Kategorien? Absolut ein automatisiertes Vorhaben mit Drupals Migrate API. Aber TYPOs komplexe Rendering-Logik Inhalte könnten etwas manuelle TLC benötigen. Die meisten Migrationen? Etwa 70-80% automatisch, 20-30% manuell.

Verliere ich meine Google-Rankings während der Migration?


Nicht, wenn Sie gewissenhaft mit Ihren Umleitungen sind. Setzen Sie diese 301s für URL-Änderungen, bleiben Sie so gut wie möglich bei Ihrer URL-Struktur, reichen Sie diese aktualisierten Sitemaps stat ein. Sie werden wahrscheinlich einen Dip sehen, sagen 2-6 Wochen. Aber ein Rebound ist typisch — Sites-Bounces normalerweise zu Pre-Migration Niveaus in 4-8 Wochen und sehen oft Verbesserungen in drei Monaten aufgrund besserer Performance.

Ist Drupal schwerer zu lernen als TYPO3 für Content-Editoren?


Anderes, nicht schwerer. Diejenigen, die an TYPOs Page-Tree-Modell gewöhnt sind, könnten Zeit mit Drupals Entity-Zentrischem Ansatz brauchen. Das Paragraphs Module bietet eine irgendwie ähnliche Content-Building-Erfahrung. Denken Sie daran, etwa 2-3 Tage Training für Editoren zu budgetieren und ihnen mit Content Type und Workflow-spezifischer Dokumentation zu versorgen.

Was passiert mit meinen TYPO3-Extensions während der Migration?


Jede Extension verdient einzelne Bewertung. Viele haben direkte Drupal-Äquivalente (z.B. powermail → Webform, ext:news → Custom Content Type + Views, ext:solr → Search API + Solr). Benutzerdefinierte Extbase-Extensions? Sie benötigen ein vollständiges Umschreiben als Drupal Module. Es gibt keinen Converter — Sie müssen anpassen.

Sollte ich bei der Migration von TYPO3 zu Drupal Headless gehen?


Es hängt von Ihren Zielen und dem Zeitplan ab. Wenn Ihre Verschiebung durch Entwickler- oder Wartbarkeitsprobleme motiviert ist, starten Sie einfach mit Drupals Twig Theming, zielen Sie später auf Headless. Aber wenn Ihr Frontend Team React oder einen ähnlichen Setup liebt und nach moderner Delivery-Architektur dürstet, planen Sie von Anfang an für Headless. Denken Sie nur daran: Beide Migrationen und Frontend-Änderungen auf einmal machen? Das ist Hochrisikogebiet.

Wie handhabe ich mehrsprachige Inhalte bei der Migration?


TYPOs Sprach-Setup (sys_language_uid, l10n_parent) stimmt gut mit Drupals Content Translation Module überein. Der Trick? Das Knacken des Sprache-zu-Sprache-Mappings in Ihren Scripts und Sicherstellen, dass Fallback Ihre Erwartungen erfüllt. Seien Sie vorsichtig mit teilweise übersetzten Inhalten — TYPOs Sprachüberlagerungsmodi (Frei, Verbunden, Streng) haben keine präzisen Drupal-Parallelen. Redaktionelle Entscheidungen über unvollständige Übersetzungen könnten notwendig sein.

Wie ist der ROI bei einer Migration von TYPO3 zu Drupal?


Wo ist der ROI? Hauptsächlich von der Reduzierung von Entwickler-Ausgaben und der Beschleunigung von Feature-Rollouts. Historisch gesehen haben die Teams, die ich beraten habe, etwa eine 20-40% Reduzierung der Entwicklungskosten in Jahr eins gesehen, hauptsächlich aufgrund leichteren Talentrekrutierung und größeren Module-Pool, der die Notwendigkeit für Custom Development reduziert. Anfängliche Migrationskosten können heftig sein, aber die meisten sollten sich innerhalb von 18-24 Monaten amortisieren.