Anonymisierte Case Study

Vertrauliche TYPO3-zu-WordPress-Migration

Der Kunde darf nicht genannt werden. Veröffentlichbar sind die Engineering-Entscheidungen: wie eine fragile, stark angepasste TYPO3-Installation abgelöst, Redakteure mitgenommen und SEO-Equity über den Cutover hinweg erhalten wurden.

Ausgangslage

TYPO3 war über ein Jahrzehnt das Unternehmens-CMS. Redakteure kannten die Tastatur. Die Site war an Rechtsprüfung, Übersetzung und ein Brand Book angebunden, das älter ist als die meisten heutigen Mitarbeiter.

Die Migration war kein Redesign. Visuelle Identität, jede URL, die mehrsprachige Matrix und der Redaktionskalender mussten erhalten bleiben, während sich die Plattform änderte.

Inhaltsmodell-Audit

Der erste Monat bedeutete Lesen des TYPO3-Seitenbaums, kein Code. Jedes TYPO3-Inhaltselement musste klassifiziert werden: nativer WordPress-Core-Pendant, Kandidat für ACF oder Block-Pattern, Archivkandidat als statischer Inhalt oder Kandidat für Stilllegung.

Das Audit produzierte eine 1:1-Map. Ohne diese Map wird Migration zur Vermutung.

URL- und Schema-Kontinuität

Jede URL blieb erhalten. Wo TYPO3 RealURL oder Pfadsegmente hatte, die nicht mehr passten, wurde eine 301-Map generiert und vor dem Launch validiert. Sprachvarianten blieben auf denselben Pfaden.

Article- und Organization-Schema migrierten mit dem Inhalt. Hreflang-Kontinuität wurde pro Locale vor dem DNS-Cutover geprüft.

Redakteurs-Onboarding

Redakteure hatten Freitags-Schulung, Montag Parallelpublishing und Cutover am Mittwoch. Der Block-Editor wurde lokalisiert, Patterns nach der Sprache der Redakteure benannt, und ein kleines Custom-Plugin ersetzte die drei wichtigsten TYPO3-Makros.

Niemand musste das Brand Book neu lernen. Das Brand Book ersetzte die Plattform, nicht umgekehrt.

Ergebnisbereiche

Exakte Zahlen sind vertraulich. Veröffentlichbar: Editorial Throughput verbesserte sich im ersten Monat, das Gewicht der Unternehmens-Templates sank deutlich, und die Sichtbarkeit für deutschsprachige Head-Terms hielt durch den Cutover ohne Recovery-Dip.

Wiederverwendbare Lektion: TYPO3 zu WordPress ist weniger Code- als Inhaltsmodell-Migration. Es gewinnt das Team, das prüft, bevor es baut.

Häufig gestellte Fragen

Warum 2026 von TYPO3 weg?

Zwei Gründe wiederholen sich. Der TYPO3-Talentpool in Mitteleuropa ist enger geworden, und die Redakteurs-Erfahrung liegt deutlich hinter dem WordPress-Block-Editor für nicht-technische Mitarbeiter. WordPress eröffnet zudem einen schnelleren Weg zu Headless und KI-gestützter Redaktion.

Sank das SEO nach dem Cutover?

In diesem Projekt nicht. Die 301-Map wurde vor DNS validiert, Hreflang blieb kontinuierlich, Schema migrierte mit dem Inhalt. Die meisten TYPO3-zu-WordPress-Regressionen entstehen durch übersprungenes URL-Audit, nicht durch WordPress.

Wie lange dauerte das?

Vertraulich. Form: ein Monat Audit und Inhaltsmodell-Mapping, zwei Monate Build und parallele Redakteursarbeit, eine Launchwoche mit fertigem Rollback. Die Audit-Phase wird in den meisten Projekten unterversorgt.

Funktioniert derselbe Ansatz bei Drupal oder Joomla?

Ja. Die Methode ist plattformunabhängig: Inhaltselemente klassifizieren, URLs mappen, Schema erhalten, Redakteure schulen, Cutover mit Rollback. Die konkrete Tooling-Auswahl unterscheidet sich.

Möchten Sie ein TYPO3-zu-WordPress-Audit?

Senden Sie den aktuellen TYPO3-Footprint, die Redakteurszahl und die Locale-Matrix. Ich sage, ob die Migration in einem oder zwei Quartalen realistisch ist.

Migrations-Audit anfragen