TYPO3 zu Drupal Migration: Ein praktischer Leitfaden für Entwickler
TYPO3 zu Drupal Migration: Ein praktischer Leitfaden für Entwickler
Wenn du jemals auf ein TYPO3-Backend gestarrt hast und gedacht hast: „Es muss doch einen besseren Weg geben", vertrau mir, du bist lange nicht allein. TYPO3 hat seine Stärken – ich will das nicht bestreiten. Es ist seit über zwanzig Jahren der CMS-Favorit für unzählige europäische Unternehmen und Regierungsseiten gewesen. Aber seien wir ehrlich: Die Entwicklerlandschaft hat sich massiv verändert. Viele Organisationen stellen fest, dass Drupal ein moderneres Setup, eine stärkere Community und einen leichteren Weg zu Headless/Decoupled-Architekturen bietet.
Ich bin in den letzten Jahren tief in einige TYPO3-zu-Drupal-Migrationen verwickelt gewesen, und es war ganz schön abenteuerlich, reale Content-Modelle zu entwirren. Sie sind normalerweise ein echtes Durcheinander. Dieser Leitfaden ist das, das ich mir vor meiner ersten Migration hätte geben sollen. Ich werde alle technischen Details, die Planungs-Must-Dos und diese heimtückischen Fallstricke behandeln, die deine Timeline sprengen können, wenn du nicht aufpasst.
Inhaltsverzeichnis
- Warum Organisationen TYPO3 verlassen
- TYPO3 vs. Drupal: Ein ehrlicher Vergleich
- Vor-Migrations-Audit und Planung
- Content-Modellierung: TYPO3 zu Drupal abbilden
- Migrations-Tools und technischer Ansatz
- TYPO3 TypoScript und Extensions handhaben
- URL-Struktur und SEO-Erhaltung
- Nach der Migration zu Headless
- Zeitplan, Kosten und Personalausstattung
- Post-Migrations-Checkliste
- Häufig gestellte Fragen
Warum Organisationen TYPO3 verlassen
Seien wir ehrlich: TYPO3 ist kein schlechtes CMS. Es ist unglaublich flexibel, bewältigt Multi-Site und Multi-Language-Setups nativ und verfügt über eine treue Fangemeinde besonders in der DACH-Region. Aber warum springen Leute ab?
Ich höre jedes Mal ziemlich die gleichen Gründe:
Verfügbarkeit von Entwicklern. Außerhalb Zentraleuropas ist es schwierig, TYPO3-Entwickler zu finden – wie eine Nadel im Heuhaufen. Drupal hingegen kann weltweit etwa 1,3 Millionen Entwickler verzeichnen, laut Drupal.org's Community-Bericht 2024. TYPO3? Nicht so sehr. Wenn deine erfahrenen TYPO3-Devs die Koffer packen und gehen, diese Positionen zu besetzen könnte eine Ewigkeit dauern.
Ecosystem-Momentum. Mit dem Release von Drupal 11 Ende 2024 gab es enorme Fortschritte in der Admin-UI, ein neues Rezepte-System und großartige API-First-Funktionen. Sicher, TYPO3 v13 ist solid, aber die Innovationsrate in Drupal, besonders rund um Headless-Setups, ist merklich schneller.
Headless/Decoupled-Architektur. Planst du, Content an ein schickes Next.js oder Astro Frontend zu liefern? Drupal's JSON:API und GraphQL-Plugins sind alte Hasen. TYPO3 hat seine eigene Headless-Extension, aber sie ist weniger ausgereift mit kleinerem Support.
Gesamtkostenaufwand. TYPO3 zu hosten kostet normalerweise mehr. Seine spezialisierte Infrastruktur bedeutet, dass du am Ende mehr auslegen könntest. Drupal läuft gemütlich praktisch überall von Pantheon bis Acquia, sogar ein einfacher LAMP-Stack hält es schnurrend.
TYPO3 vs. Drupal: Ein ehrlicher Vergleich
Bevor du kopfüber in einen Wechsel springst, stelle sicher, dass Drupal wirklich deine Schmerzen lindern wird. Hier die Übersicht ab 2025:
| Funktion | TYPO3 v13 | Drupal 11 |
|---|---|---|
| Content-Modellierung | Flexibel, lehnt sich an TCA an | Entity/Field-System mit Field-Verwaltungs-UI |
| Mehrsprachigkeit | Hervorragende native Unterstützung | Gleich hervorragende native Unterstützung |
| Multi-Site | Standard Multi-Site mit Content-Bäumen | 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 (Auffrischung in v13) | Elegant und modern in Drupal 11 |
| Entwickler-Community | ~500 aktive Contributor | 8.000+ aktive Contributor |
| Hosting-Optionen | Selbst-gehostet oder spezialisiert | Selbst-gehostet, Pantheon, Acquia, Platform.sh, Lagoon |
| PHP-Anforderung | PHP 8.2+ | PHP 8.3+ |
| Typische Agentur-Rate | €100-180/Stunde (DACH-Region) | $80-200/Stunde (global) |
TYPO3's Page-Tree-Modell ist ein seltenes Juwel. Redakteure, die an der Verwaltung aufwendiger Seiten-Hierarchien in TYPO3 hängen, könnten Drupal's Stil – die Kombination aus Content-Typen und Taxonomie – etwas Gewöhnung erfordern. Plane etwas Editor-Training ein, um den Übergang zu erleichtern.
Vor-Migrations-Audit und Planung
Diese Phase bestimmt das Schicksal der meisten Migrationen. Der Erfolg liegt in der Planung, nicht in den technischen Zeiten.
Content-Inventar
Beginne damit, alles in deinem TYPO3-Setup zu prüfen:
- Seiten: Hole dir den Page Tree, dokumentiere jeden
doktype(Seitentyp), den du im Einsatz hast. - Content-Elemente: Jeder
CType(Content-Typ) braucht Aufmerksamkeit – sei es Text, Text mit Bild, HTML oder Custom-Sachen viamaskodercontent_defender. - Extensions: Notiere jede Extension, die du hast. Finde heraus, ob es ein Drupal-Äquivalent gibt.
- Datei-Referenzen: TYPO3's FAL (File Abstraction Layer) kümmert sich um Medien. Bilde diese auf Drupal's Media-Stellen ab.
- Backend-Benutzer und Berechtigungen: TYPO3's aufwendige Backend-Benutzergruppen mit Seiten- und Feld-Level-Zugriff sollten ordentlich zu Drupal-Rollen und Berechtigungen übersetzt werden.
Hier ist eine hilfreiche SQL-Query für einen Content-Element-Überblick aus deiner TYPO3-Datenbank:
SELECT CType, COUNT(*) as count
FROM tt_content
WHERE deleted = 0 AND hidden = 0
GROUP BY CType
ORDER BY count DESC;
Damit bekommst du einen schnellen Überblick über die Content-Typen, mit denen du es zu tun hast. In einem Fall habe ich eine TYPO3-Instanz mit 40+ Custom-Content-Element-Typen entdeckt, von denen nur ein Dutzend aktiv genutzt wurde. Schleppe kein totes Gewicht mit.
Was behalten, was eliminieren
Das ist deine Chance, aufzuräumen. Nutze ein Content-Audit-Tool wie Screaming Frog oder Sitebulb, um zu ermitteln:
- Seiten ohne Traffic im letzten Jahr
- Duplizierte oder nahezu identische Inhalte
- Gebrochene interne Links
- Verwaiste Media-Dateien
Typischerweise gibt es bei großen TYPO3-Migrationen einen Content-Cut von 30-50%. Weniger Seiten bedeuten schnellere Migrationen.
Content-Modellierung: TYPO3 zu Drupal abbilden
Krempel deine Ärmel auf. Das ist die schwere intellektuelle Arbeit. TYPO3 und Drupal handhaben Content sehr unterschiedlich.
TYPO3's Modell
TYPO3 dreht sich um Seiten. Alles sitzt in einem Page-Tree. Content-Elemente (Records in tt_content) sitzen auf Seiten in Spalten (colPos). Custom Records, die über Extbase-Modelle oder TCA definiert sind, sitzen in separaten Tabellen, sind aber normalerweise von Seiten aus verlinkt.
Drupal's Modell
Drupal dreht sich alles um Entities. Du erstellst Content-Typen (Node Bundles), jeder mit dedizierten Feldern. Seiten sind nur einer unter vielen Content-Typen. Taxonomie, Paragraphen (mit dem Paragraphs-Modul) und Layout Builder beherrschen die strukturierte Content-Zusammensetzung.
Die Abbildung
Hier ist eine typische Abbildungs-Tabelle, die ich als Kompass nutze:
| 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-Typ oder Body-Feld |
| Content Element (CType: image) | Media-Entity-Referenz |
| Content Element (CType: textpic) | Paragraph-Typ mit Text + Media |
| Content Element (CType: gridelements) | Layout Builder-Abschnitt |
| FAL-Datei-Referenz | Media-Entity |
| sys_category | Taxonomy-Term |
| fe_users | Drupal-Benutzer-Entity |
| be_users | Drupal-Benutzer-Entity mit Admin-Rolle |
| TypoScript-Template | Twig-Template |
| Extbase-Plugin | Custom-Drupal-Modul |
| Mask/DCE-Content-Elemente | Paragraph-Typen |
Der größte Wechsel? Content-Elemente in Paragraphen verschieben. TYPO3 stapelt Content-Elemente in Seiten-Spalten, was gut zu Drupal's Paragraphs-Modul passt. Redakteure stapeln Seiten aus wiederverwendbaren Paragraph-Typen – es ist überraschend nahtlos.
Migrations-Tools und technischer Ansatz
Drupal's Migrate API rockt. Aber Kopf hoch, es fehlt ein natives TYPO3-Source-Plugin. Du musst dir custom Source-Plugins basteln, um aus TYPO3's Datenbank zu ziehen.
Ansatz 1: Direkte Datenbank-Migration
Stöpsel Drupal's Migrate API direkt in deine 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('Zusammenfassung/Zusammenfassung'),
];
}
public function getIds() {
return ['uid' => ['type' => 'integer']];
}
public function prepareRow(Row $row) {
// Lade zugehörige 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 TYPO3's Besonderheiten (wie Soft-Deletes und Workspace-Overlays) in deinem Codebase zu handhaben.
Ansatz 2: Export/Import via JSON oder XML
Einige Teams entscheiden sich dafür, TYPO3-Content in strukturierte Formate zu exportieren (sagen wir, durch Custom-TYPO3-Extensions oder CLI-Befehle) und dann in Drupal zu importieren. Klar, das fügt eine weitere Ebene hinzu, ist aber praktisch, wenn du dir Sorgen um die Aufrechterhaltung direkter Datenbankverbindungen während der Migration machst.
Ansatz 3: Hybrid mit manueller Überprüfung
Hast du eine kleinere Website (unter 500 Seiten)? Eine strukturierte Daten-Migration automatisch durchführen, während du wichtige Landing Pages handwerklich erstellst, kann wunderbar funktionieren. Es mag primitiv klingen, aber wenn Content mit TYPO3-spezifischer Rendering-Logik verwoben ist, führt automatische Migration oft zu Unsinn.
TYPO3 TypoScript und Extensions handhaben
TypoScript
Schneiden wir zur Sache: TypoScript migriert nicht. Es ist eine TYPO3-spezifische Konfig-Sprache ohne echtes Äquivalent anderswo. Deine Aufgabe ist es, zu dokumentieren, was jedes TypoScript-Template in Laienbegriffen tut, und dann als Twig-Templates und Drupal-Config neu zu erstellen. Es ist mühsam, aber notwendig.
Extensions
Hier ist ein praktischer Vergleich von häufigen TYPO3-Extensions und ihren Drupal-Äquivalenten:
| TYPO3-Extension | Drupal-Äquivalent |
|---|---|
| news | Core Content Type + Views |
| powermail | Webform-Modul |
| 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-Modul + Custom |
| cal/events | Custom Content Type + Views |
Custom Extbase-Extensions müssen als Drupal-Module neu geschrieben werden. Keine Abkürzungen – stelle sicher, dass du dafür budgetierst.
URL-Struktur und SEO-Erhaltung
Vermass das, und du verlierst organischen Traffic. Ich habe Organisationen beobachtet, die aufgrund fehlbehandelter Umleitungen nach der Migration bis zu 40% ihres Search-Traffics verloren haben.
Schritte
- Exportiere alle URLs aus TYPO3. Nutze ein CLI-Tool oder einen Crawler für jede indexierte URL.
- Bilde diese auf Drupal-URLs ab. Nutze Drupal's Pathauto für URL-Alias-Generierung, halte dich nah an bestehende URLs.
- Erstelle Umleitungen für alles, das sich ändert. Setze Drupal's Redirect-Modul ein. Für Berge von Umleitungen, importiere via CSV.
- Handhabe Sprach-Präfixe. TYPO3 nutzt
/de/,/en/,/fr/- stelle sicher, dass Drupal's Spracheinstellungen das widerspiegeln. - Reiche aktualisierte Sitemaps bei Google Search Console sofort ein.
# Beispiel-Umleitung-Import-CSV-Format für Drupal's Redirect-Modul
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: Halte die alte TYPO3-Instanz live, jedoch nur Lesen, für mindestens drei Monate nach der Migration. Du wirst verpasste URLs entdecken.
Nach der Migration zu Headless
Drupal glänzt mit seinem Weg zu einem entkoppelten Frontend. Mit Drupal 11 ist das JSON:API-Modul solide wie ein Fels, und das Headless-Drupal-Ökosystem gedeiht.
Wenn du eine Headless-Annäherung erwägst – und 2025, für die meisten Content-getriebenen Seiten, lohnt es sich zu überlegen – sind wir ausführlich darauf eingegangen unter /solutions/headless-cms-development.
Beliebte Frontends mit Drupal paaren:
- Next.js — Der Frontrunner.
next-drupalvon Chapter Three macht's leichter. Wir diskutieren das ausführlich unter /capabilities/nextjs-development. - Astro — Perfekt für Content-lastige Seiten, die nicht zu Client-schwer sind. Siehe /capabilities/astro-development.
- Nuxt — Falls Vue dein Spielplatz ist.
Die Schönheit der Migration zuerst zu Drupal ist der Launch mit Drupal's Standard-Twig-Frontend. Später kannst du zu einem entkoppelten wechseln. Versuche nicht, beide Wechsel gleichzeitig zu machen – das ist Projekt-Chaos auf Anfrage.
Zeitplan, Kosten und Personalausstattung
Echte Zahlen aus Projekten, an denen ich beteiligt war, oder aus denen ich genaue Daten habe (2024-2025):
| Website-Größe | Seiten | Zeitplan | Budget-Spanne | Team |
|---|---|---|---|---|
| Klein | <500 Seiten | 2-3 Monate | $30.000-60.000 | 2-3 Entwickler |
| Mittel | 500-5.000 Seiten | 4-6 Monate | $60.000-150.000 | 3-5 Entwickler |
| Groß | 5.000-50.000 Seiten | 6-12 Monate | $150.000-400.000 | 5-8 Entwickler |
| Enterprise | 50.000+ Seiten | 12-18 Monate | $400.000-1.000.000+ | 8-15 Entwickler |
Diese beinhalten alles von Discovery, Content-Modellierung, 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-Website mit 30 Custom-Content-Typen und 4 Sprachen wird teurer als eine einfache 10.000-Seiten-Website.
Interessierst dich für Details für deinen Fall? Schau dir /pricing an oder kontaktiere uns direkt.
Post-Migrations-Checkliste
Überspringe diese Checkliste nicht. Vertrau mir.
- Verifiziere alle Umleitungen. Stelle sicher, dass es 301s sind.
- Aktualisiere Google Search Console mit deiner neuen Sitemap.
- Teste alle Formulare: Kontakt, Newsletter, Login.
- Stelle sicher, dass mehrsprachige Content-Genauigkeit für jede Sprache stimmt.
- Migriere Media-Dateien genau mit Alt-Text und Metadaten.
- Prüfe Editor-Berechtigungen für jede Rolle.
- Erfasse Performance-Metriken (Core Web Vitals).
- Verifiziere Analytics-Tracking (GA4-Events, Ziele).
- Konfiguriere und teste CDN/Caching.
- Aktiviere Security-Header (CSP, HSTS).
- Teste Backup- und Disaster-Recovery-Systeme.
- Vervollständige Editor-Training und liefere Dokumentation.
- Halte die alte TYPO3-Instanz im Nur-Lesen-Modus verfügbar.
Häufig gestellte Fragen
Wie lange dauert typischerweise eine TYPO3-zu-Drupal-Migration?
Für mittelgroße Websites (500-5.000 Seiten) dauert es etwa 4-6 Monate vom Start bis zum Launch. Der erste Monat? Rein Discovery und Content-Modellierung. Migration-Scripting bedeutet normalerweise 6-8 Wochen Arbeit. QA und Editor-Training? Rechne noch einen Monat ein. Wenn es ein komplexes Multi-Language-, Multi-Site-Setup mit Custom-Extensions ist, schaust du auf 9-12 Monate.
Kann ich TYPO3-Content automatisch migrieren, oder ist es manuell?
Strukturierte Content wie Seiten, News-Records oder Kategorien? Absolut ein automatisierter Job mit Drupal's Migrate API. Aber TYPO3's komplexe Rendering-Logik-Content könnte etwas manuelle Pflege brauchen. Die meisten Migrationen? Etwa 70-80% automatisch, 20-30% manuell.
Werde ich meine Google-Rankings während der Migration verlieren?
Nicht, wenn du dich mit deinen Umleitungen anstrengst. Setzt diese 301s für alle URL-Änderungen, halte deine URL-Struktur so gut wie möglich, reiche diese aktualisierten Sitemaps sofort ein. Du wirst wahrscheinlich einen Rückgang sehen, sagen wir 2-6 Wochen. Aber eine Erholung ist typisch – Websites springen normalerweise in 4-8 Wochen zu Pre-Migrations-Leveln zurück und sehen oft Verbesserungen in drei Monaten aufgrund besserer Performance.
Ist Drupal schwerer zu lernen als TYPO3 für Content-Redakteure?
Unterschiedlich, nicht schwerer. Die an TYPO3's Page-Tree-Modell gewöhnt sind, könnten Zeit mit Drupal's Entity-Zentrierter Annäherung brauchen. Das Paragraphs-Modul bietet eine etwas ähnliche Content-Erstellungs-Erfahrung. Vergiss nicht, etwa 2-3 Tage Training für Redakteure zu budgetieren und ihnen Content-Typ- und Workflow-spezifische Dokumentation zur Verfügung zu stellen.
Was passiert mit meinen TYPO3-Extensions während der Migration?
Jede Extension verdient individuelle Bewertung. Viele haben direkte Drupal-Äquivalente (z.B. powermail → Webform, ext:news → Custom Content Type + Views, ext:solr → Search API + Solr). Custom Extbase-Extensions? Sie müssen als Drupal-Module komplett neu geschrieben werden. Es gibt keinen Konverter – du musst anpassen.
Sollte ich bei der Migration von TYPO3 zu Drupal zu Headless gehen?
Das hängt von deinen Zielen und deiner Timeline ab. Wenn dein Wechsel durch Developer- oder Wartbarkeitsprobleme motiviert wird, fang einfach mit Drupal's Twig-Theming an, ziele später auf Headless. Aber wenn dein Frontend-Team React oder ein ähnliches Setup liebt, und du moderne Delivery-Architektur sehnst, erwäge eine Planung für Headless von Tag eins. Vergiss nur nicht: Beide Migrationen und Frontend-Änderungen gleichzeitig zu machen? Das ist hochriskant.
Wie handhabe ich mehrsprachige Content in der Migration?
TYPO3's Sprachsetup (sys_language_uid, l10n_parent) passt gut zu Drupal's Content Translation-Modul. Der Trick? Language-zu-Language-Abbildung in deinen Scripts nageln und sicherstellen, dass Fallback deinen Erwartungen entspricht. Sei vorsichtig mit teilweise übersetztem Content – TYPO3's Language-Overlay-Modi (frei, verbunden, streng) haben keine genauen Drupal-Pendants. Editorial-Entscheidungen über unvollständige Übersetzungen könnten notwendig sein.
Wie ist der ROI der Migration von TYPO3 zu Drupal?
Wo liegt der ROI? Hauptsächlich aus der Reduktion von Developer-Ausgaben und schnellerer Feature-Rollout. Historisch sehen die Teams, die ich geführt habe, etwa einen 20-40% Cut in Development-Kosten im ersten Jahr, hauptsächlich dank leichterer Talentgewinnung und einem größeren Modul-Pool, der die Notwendigkeit für Custom-Development reduziert. Erste Migrations-Kosten können heftig sein, aber die meisten sollten sich innerhalb von 18-24 Monaten amortisieren.