TYPO3 ist im DACH Raum nie ein zufälliges System gewesen. Behörden, Universitäten, Industrieunternehmen mit Multi Domain Aufbau und große Verbände haben es seit den frühen 2000er Jahren gewählt, weil es genau das löste, was klassisches WordPress lange nicht konnte: saubere Mehrsprachigkeit, granulare Rechte, Multi Site und Multi Tree out of the box. Im Jahr 2026 sieht der Markt anders aus. Dieser Artikel ist ein ehrlicher Blick darauf, wann eine Migration von TYPO3 nach WordPress wirtschaftlich und redaktionell sinnvoll ist und wann nicht. Er ist nicht neutral, sondern polemisch im besten Sinne, also mit klarer Position und nachprüfbaren Fakten.
TL;DR
- TYPO3 12 LTS ist seit dem 4. Oktober 2023 verfügbar, TYPO3 13 ist die aktive Entwicklungslinie, das Projekt lebt.
- WordPress 6.7 und höher ist die Referenz für 2026 und betreibt laut W3Techs rund 43 Prozent aller Websites weltweit.
- Der WordPress block editor existiert seit WordPress 5.0 vom Dezember 2018, die REST API seit WordPress 4.7 vom Dezember 2016.
- Multi Site, Multi Domain und Mehrsprachigkeit sind bei TYPO3 Kernfunktionen, bei WordPress eine Frage von Multisite plus Polylang oder WPML.
- Migration lohnt sich nicht pauschal. Sie lohnt sich, wenn Talentverfügbarkeit, Redaktionskomfort und Frontend Geschwindigkeit das technische Profil von TYPO3 überholen.
Wo TYPO3 historisch stark war
TYPO3 ist in Deutschland, Österreich und der Schweiz aus drei Gründen groß geworden. Erstens hat es früh ein Mehrsprachigkeitsmodell mitgeliefert, das ohne Plugin auskam. Eine Seite, mehrere Sprachversionen, klare Übersetzungsrelationen, das war 2010 bei WordPress noch unrealistisch. Zweitens deckt TYPO3 Multi Site und Multi Domain im Kern ab. Eine Installation, mehrere Page Trees, mehrere Domains, getrennte Redaktionen mit getrennten Rechten. Drittens ist das Rechte und Rollen System feinkörnig genug, um in Behörden, Hochschulen und Industriekonzernen die internen Freigabeprozesse abzubilden, einschließlich Workspaces für unveröffentlichte Versionen.
In genau diesen Segmenten ist TYPO3 in der DACH Region groß geworden. Universitäten mit Fakultätsbereichen, kommunale Verwaltungen mit Bürgerportalen, Industriekonzerne mit Konzernportal plus Tochtergesellschaften, Bundesländer mit Ministerien. Die TYPO3 Association, mit Sitz in der Schweiz, bündelt diesen Markt seit 2004 und sorgt für Stabilität, die für öffentliche Auftraggeber relevant ist. Wer 2010 ein deutsches Landratsamt digitalisierte, kam an TYPO3 schwer vorbei.
Diese historische Stärke ist real und wird in keiner ehrlichen Diskussion weggeschoben. Sie ist allerdings nicht die ganze Geschichte für 2026.
Was sich 2018 bis 2025 verschoben hat
Im Dezember 2018 erschien WordPress 5.0 mit dem block editor, intern als Gutenberg bekannt. Das war kein kosmetischer Wechsel, sondern eine Verschiebung des redaktionellen Modells. Seiten werden seitdem aus Blöcken zusammengesetzt, Block Patterns erlauben wiederverwendbare Layouts, Full Site Editing seit WordPress 5.9 vom Januar 2022 erweitert das Konzept auf Templates, Header und Footer. Der Effekt ist hart messbar: redaktionelle Teams ohne Entwicklerhintergrund publizieren heute selbst komplexe Layouts.
Bereits zwei Jahre früher, im Dezember 2016, hatte WordPress 4.7 die REST API in den Kern aufgenommen. Damit ist WordPress seitdem ein vollwertiges Headless CMS. Astro Frontends, Next.js Apps, native Mobilanwendungen, alle ziehen ihre Inhalte über dieselbe API. TYPO3 hat mit Headless TYPO3 eine vergleichbare Geschichte, aber das Ökosystem an Frontend Frameworks, die out of the box gegen WordPress sprechen, ist um Größenordnungen breiter.
Parallel dazu hat sich die Marktdurchdringung weiter zugunsten von WordPress entwickelt. Die häufig zitierte Zahl von rund 43 Prozent aller Websites weltweit kommt von W3Techs und wird von Automattic in offiziellen Materialien bestätigt. Diese Zahl ist nicht nur Statistik, sondern Talent Indikator. In Berlin, München, Wien, Zürich, Hamburg und Köln finden sich auf jedes TYPO3 Stellenangebot mehrere WordPress Bewerber. Wer 2026 eine Senior TYPO3 Entwicklerin sucht, muss länger suchen, höher zahlen und längere Bindungsfristen akzeptieren als bei WordPress. Das ist kein Werturteil über Qualität, sondern eine Frage der Marktverfügbarkeit.
Hinzu kommt die Geschwindigkeit, mit der das WordPress Ökosystem auf neue Standards reagiert. WCAG 2.2, BFSG, NIS2, DORA, Core Web Vitals, all das hat in den letzten Jahren Plugins, Themes und Best Practice Vorlagen produziert, die in TYPO3 zwar existieren, aber selten in derselben Reife. Ein Beispiel ist die Verbreitung von WCAG 2.2 fertigen Themes oder die Tiefe der Cloudflare Workers Integrationen. Wer einen tieferen Blick auf den Edge Layer haben möchte, findet ihn in unserem Artikel zu Cloudflare Workers für WordPress und WooCommerce.
Wann sich Migration lohnt
Eine Migration von TYPO3 nach WordPress lohnt sich nicht aus Mode, sondern auf Basis einer Entscheidungsregel. Wir wenden bei WPPoland fünf Kriterien an. Sind drei oder mehr erfüllt, ist Migration die wirtschaftlich vernünftige Antwort.
Erstens, das Redaktionsteam ist nicht entwicklernah. Wenn Inhalte heute über Tickets bei der Agentur landen, weil TypoScript Anpassungen nötig sind, kostet das Geschwindigkeit und Geld. WordPress mit block editor und gut konfigurierten Block Patterns reduziert diese Abhängigkeit deutlich.
Zweitens, die Site lebt von Content Marketing. Blog, Knowledge Base, Whitepaper, Webinare, Case Studies, all das produziert WordPress in höherer Frequenz. Wer mehr als zwei substanzielle Inhalte pro Woche veröffentlicht, profitiert von WordPress in der täglichen Arbeit.
Drittens, die Frontend Performance steht unter Druck. Core Web Vitals sind ein Ranking Faktor, und das WordPress Ökosystem hat den größten Stack an Edge, Caching und Build Lösungen entwickelt. Wer auf 100 zu 100 abzielt, findet im WordPress Universum mehr fertige Bausteine als in TYPO3.
Viertens, die Talentverfügbarkeit limitiert das Projekt. Wenn die Suche nach TYPO3 Senior Profilen mehrere Monate dauert und die Stundensätze deutlich über dem WordPress Mittel liegen, ist das ein wirtschaftliches Signal. Eine ehrliche Sicht auf nearshore Standards für DACH Projekte findet sich in unserem Artikel zu Senior Engineers aus Polen.
Fünftens, die Zielarchitektur ist headless. Wer ohnehin auf ein modernes Frontend in Astro oder Next.js wechselt, hat im WordPress Ökosystem mehr und reifere Brücken. Unser Pillar Artikel zu Headless WordPress als Service beschreibt das Modell im Detail.
Wann TYPO3 bleiben darf
Polemik ohne Gegenposition ist Marketing, nicht Beratung. Es gibt vier klare Fälle, in denen TYPO3 die richtige Wahl bleibt und ein Migrationsprojekt unverhältnismäßig wäre.
Erstens, die Site ist in einem öffentlichen Beschaffungsverfahren festgelegt worden, in dem TYPO3 explizit gefordert ist, etwa in Rahmenverträgen von Bundesländern. Eine Migration gegen Vertragslage zu fordern ist betriebswirtschaftlich unsauber.
Zweitens, das interne Team ist tief im TYPO3 Universum trainiert, hat Workspaces, Workflows und Multi Tree Aufbauten dauerhaft im Griff und produziert damit gute Geschwindigkeit. Eine Migration verbrennt in diesem Fall internes Wissen für unklaren Mehrwert.
Drittens, die Mehrsprachigkeit ist sehr komplex, beispielsweise mit acht oder mehr Sprachen, gemeinsamen Inhalten zwischen Sprachen, regionalen Varianten und einem Mehrtenant Aufbau über Domains hinweg. WordPress kann das mit Polylang oder WPML, aber die Komplexität wird nicht verschwinden, sondern nur verlagert.
Viertens, die individuelle Extbase Logik ist tief mit fachlichen Prozessen verzahnt, etwa in Hochschulportalen mit Modulhandbüchern oder in Behördensystemen mit Vorgangsbearbeitung. Diese Logik in WordPress neu zu bauen kann teurer sein als TYPO3 weiter zu pflegen.
Wenn keiner dieser Fälle vorliegt und die Migrationskriterien überwiegen, geht es um den Pfad.
Migrationspfad konkret
Wir teilen TYPO3 zu WordPress Migrationen in vier Phasen. Diese Phasen kosten unterschiedlich viel Zeit, müssen aber alle stattfinden, sonst entstehen die Fehler, die wir im nächsten Abschnitt beschreiben.
Phase eins ist das Audit. Hier wird der bestehende TYPO3 Stand vollständig kartiert. Welche Page Trees, welche Domains, welche Sprachversionen, welche Extensions, welche TypoScript Konfigurationen, welche Workflows, welche Rollen, welche externen Anbindungen. Das Audit produziert ein Inventar mit URLs, Metadaten, Sprachrelationen und Custom Datenmodellen. Ohne dieses Inventar ist alles, was danach kommt, geraten.
Phase zwei ist das Content Model Mapping. WordPress denkt in Posts, Pages, Custom Post Types und Taxonomien. TYPO3 denkt in Page Trees, Inhaltselementen und Records. Das Mapping entscheidet, welche TYPO3 Inhaltselemente zu Gutenberg Blöcken werden, welche zu Reusable Blocks und Block Patterns, welche zu ACF Feldern, welche zu Custom Post Types. Ein typisches Mapping in DACH Projekten umfasst News, Pressemitteilungen, Stellenangebote, Standorte, Veranstaltungen und Mitarbeitende. Diese Phase ist die intellektuell anspruchsvollste, weil sie das redaktionelle Denken neu strukturiert.
Phase drei ist die eigentliche technische Migration. Hier laufen Skripte, die TYPO3 Datenbanken auslesen, Inhalte transformieren und in WordPress Strukturen schreiben. Wir nutzen üblicherweise eine Kombination aus direktem Datenbank Zugriff über Read Only Replicas und WP CLI Importern. Bilder werden mit ihren Renditions übernommen, Mehrsprachigkeit wird über Polylang oder WPML aufgebaut, abhängig vom Zielprofil. Die Skripte sind idempotent, das heißt sie können mehrfach laufen ohne Duplikate zu erzeugen.
Phase vier ist SEO und Redirect Strategie. Hier wird sichergestellt, dass jede alte URL eine 301 Antwort liefert, die zu einer äquivalenten neuen URL führt. Strukturierte Daten werden neu aufgesetzt, hreflang Tags vollständig gemappt, XML Sitemaps neu erzeugt. Diese Phase ist nicht optional und nicht nachträglich, sondern wird parallel zu Phase drei vorbereitet. Wer Lust auf eine tiefere Sicht auf SEO Muster im headless Setup hat, findet sie in unserem Artikel zu SEO patterns for headless WordPress.
Was bei der Migration meistens schiefgeht
Wir haben in den letzten Jahren genug TYPO3 zu WordPress Projekte gesehen, um die fünf häufigsten Fehler benennen zu können. Sie sind alle vermeidbar, wenn das Audit ehrlich ist.
Erstens, URL Erhalt wird unterschätzt. TYPO3 generiert URLs aus Page Tree Pfaden, oft mit deutschen Sonderzeichen, oft mit langen Hierarchien. Wer beim Wechsel die URL Struktur ohne Redirect Map flach klopft, verliert Rankings für Monate. Die Lösung ist eine vollständige URL Liste vor dem Cutover, mit eindeutiger Quelle und Ziel pro Eintrag, ausgeliefert über die Webserver Konfiguration oder Cloudflare Page Rules.
Zweitens, Multi Tree zu Kategorie Mapping wird zu naiv gedacht. Ein Page Tree in TYPO3 ist nicht dasselbe wie eine WordPress Kategorie. Page Trees enthalten Hierarchien, Permissions, Sprachvarianten und Inhaltselemente. Eine Kategorie ist eine Taxonomie. Wer das eins zu eins mappt, verliert Information. Die saubere Lösung ist eine Mischung aus Custom Post Types, Taxonomien und Pages mit Parent Relationen.
Drittens, mehrsprachige Fragmente werden vergessen. TYPO3 erlaubt Sprachüberlagerung von einzelnen Inhaltselementen, ohne die ganze Seite zu duplizieren. WordPress Lokalisierung über Polylang oder WPML duplicates standardmäßig die Seite. Wenn das Mapping diese Differenz nicht modelliert, fehlen plötzlich Übersetzungen für Header, Footer oder Teaser Blöcke, weil sie als globale Snippets in TYPO3 gepflegt waren.
Viertens, individuelle Extbase Datenmodelle werden zu spät übersetzt. Wer in TYPO3 eine eigene Extension für, sagen wir, Veranstaltungen mit Frühbucher Logik, Sitzplatzkapazitäten und Wartelisten gebaut hat, kann diese nicht über einen generischen Importer ziehen. Die Logik muss in einen Custom Post Type plus REST Endpoints übersetzt werden, idealerweise mit eigenen Validierungsregeln. Wer das in den letzten zwei Wochen vor Cutover entdeckt, verschiebt den Termin.
Fünftens, Bild Renditions werden vergessen. TYPO3 generiert Renditions für unterschiedliche Größen und Crops über sein File Abstraction Layer. WordPress hat sein eigenes Sizes System. Wenn die Migration nur die Originale überträgt und die Renditions zur Laufzeit beim ersten Aufruf neu erzeugt werden, sieht die Site nach Cutover für Tage langsam aus. Lösung ist eine Vorab Generierung der Größen über WP CLI direkt nach dem Import.
Was wir bei WPPoland anbieten
Wir begleiten DACH Unternehmen und Public Sector Organisationen seit Jahren bei TYPO3 zu WordPress Migrationen, mit besonderem Fokus auf Headless Architekturen. Unser Modell trennt redaktionelle Arbeit von der Frontend Auslieferung. WordPress bleibt die Redaktion, das Frontend läuft auf Astro oder Next.js, ausgeliefert über Cloudflare Workers. Das gibt Behörden und Mittelständlern die Geschwindigkeit, die sie für Core Web Vitals brauchen, ohne den Redaktionskomfort von WordPress aufzugeben.
Wir sprechen Deutsch, Polnisch und Englisch in den Projektteams, dokumentieren Architekturen so, dass Compliance Teams sie prüfen können, und liefern WCAG 2.2 sowie BFSG fertige Templates aus. Konkrete Preise hängen vom Profil ab, vom Inventar bis zum Multi Site Aufwand. Wer wissen möchte, wie unser Service Modell konkret funktioniert, findet die Übersicht auf unserer Seite zu Headless WordPress als Service und kann direkt mit dem Team sprechen.
Wo dieser Artikel hineinpasst
Dieser Artikel ist kein einzelnes Stück, sondern Teil eines DACH Clusters zu WordPress Migrationen, Compliance und Performance. Wer hier eingestiegen ist, findet die Anschlussstücke in folgenden Texten.
Für die Architektur nach der Migration ist Headless WordPress als Service der Pillar. Für die technische Auslieferung über den Edge Layer empfiehlt sich Cloudflare Workers für WordPress und WooCommerce. Für Public Sector Anforderungen sind WCAG, BFSG und EAA sowie NIS2 und DORA Pflichtlektüre. Für Talentfragen liefert unser Text zu Senior Engineers aus Polen den nearshore Kontext.
Englischsprachige Vertiefungen für CTOs und technische Leitungen finden sich in Headless WordPress: Next.js vs Astro, in der Economics of Headless WordPress und in den SEO patterns for headless WordPress. Für die persönliche Position des Autors zur DACH WordPress Strategie steht das Profil von Mariusz Szatkowski bereit.
TYPO3 hat eine Heimat in DACH, das ist Fakt. WordPress hat 2026 die größere Reichweite, das größere Talentbecken und das breitere Ökosystem, auch das ist Fakt. Migration ist kein Glaubensbekenntnis. Sie ist eine Rechnung mit fünf Variablen. Wer ehrlich rechnet, kommt zu einer klaren Antwort.
