Migration von TYPO3 zu Payload: ein Leitfaden für 2026 zum Ende des kostenlosen v12-Supports

Der kostenlose Community-Support für TYPO3 v12 LTS endete am 30. April 2026. Ab dem 1. Mai 2026 liefert die TYPO3-Community keine Wartung und keine Sicherheitsupdates mehr dafür aus, sodass eine v12-Website nun ohne kostenlose Patches läuft. Das macht die Website an dem Tag, an dem das Datum verstreicht, nicht kaputt, aber es setzt eine Uhr in Gang, und anders als bei manchen End-of-Life-Daten gibt es hier mehr als eine sinnvolle Antwort.

Wenn Sie eine TYPO3-v12-Website betreiben, ist das Nützlichste in diesem Jahr, die Weggabelung vor Ihnen klar zu verstehen, denn TYPO3 bietet Ihnen einen echten Weg innerhalb des Ökosystems ebenso wie einen Ausstieg, und beide sind legitim.

Wir arbeiten mit React und Next.js und bauen auf Payload CMS. Wir werden diese Voreingenommenheit durchgehend offenlegen, und wir werden ebenso fair darüber sein, wo ein Verbleib in der TYPO3-Welt die bessere Entscheidung ist, denn für viele TYPO3-Bestände ist sie das. Dieser Leitfaden legt die drei echten Optionen dar, was eine TYPO3-Migration schwerer oder leichter macht, als sie aussieht, was ein Wechsel von TYPO3 zu Payload tatsächlich umfasst und wie Sie entscheiden.

Ihre drei echten Optionen

TYPO3 gibt Ihnen zum Ende des kostenlosen v12-Supports drei echte Möglichkeiten, und anders als bei manchen Plattformen verdienen die mittleren beiden ernsthafte Beachtung.

1. Upgrade auf TYPO3 v13 oder v14 LTS. Das hält Sie im TYPO3-Ökosystem, und es gibt zwei unterstützte Ziele. TYPO3 v13 LTS erhält kostenlose Sicherheitsupdates bis Ende Dezember 2027. TYPO3 v14 LTS ist das aktuelle Flaggschiff-Release, mit Fehlerkorrekturen bis Dezember 2027 und kostenlosen Sicherheitsupdates bis Ende Juni 2029, bietet also den längeren Vorlauf der beiden. v12 nach vorne zu bringen ist echte Arbeit, aber es ist schrittweise Arbeit entlang eines Pfades, den TYPO3 dafür vorsieht, kein Neubau auf eine neue Architektur.
2. Kostenpflichtiges ELTS als Brücke kaufen. Die TYPO3 GmbH verkauft Extended Long Term Support, ein kostenpflichtiges Abonnement, das Sicherheits- und Kompatibilitätsupdates für eine Version fortführt, nachdem deren kostenloser Community-Support endet. Für v12 läuft es drei zusätzliche Jahre, mit einem exklusiven vierten Jahr für TYPO3-Partner, womit das sicher betreibbare Fenster äußerstenfalls bis zum 30. April 2030 reicht. Das ist legitimer Spielraum statt einer Sackgasse, und es verschafft Zeit, einen größeren Wechsel nach Ihrem eigenen Zeitplan zu planen.
3. Auf einen anderen Stack wechseln. Wenn die Gründe, TYPO3 zu verlassen, über diese eine Frist hinausgehen, ist das Ende des kostenlosen Supports ein natürlicher Moment für den Wechsel. Ein Headless-CMS wie Payload ist die Option in dieser Kategorie, die wir am besten kennen.

Die ehrliche Einordnung lautet: Die Optionen eins und zwei halten Sie auf TYPO3, und nur Option drei ist ein Abschied. Damit geht es bei der Entscheidung weniger um die Frist als darum, ob Sie überhaupt auf TYPO3 bleiben wollen.

Was TYPO3-Bestände festhält

Bevor Sie einen Abschied abwägen, hilft es zu wissen, was eine TYPO3-Website tatsächlich an ihrem Platz hält, denn genau diese Dinge bemessen eine Migration.

TypoScript und Fluid lassen sich nirgendwohin portieren. TYPO3 wird über TypoScript konfiguriert, seine eigene deklarative Konfigurationssprache, und seine Seiten werden über Fluid gerendert, seine eigene Template-Engine. Für keines von beidem gibt es eine Entsprechung, die Sie auf eine andere Plattform mitnehmen könnten. Bei jedem Wechsel weg von TYPO3 wird die in TypoScript ausgedrückte Logik ebenso neu gebaut wie die in Fluid geschriebenen Templates, statt übertragen zu werden.

Der Bestand an Extensions ist die Prüfung, die das Projekt bemisst. Die Fähigkeiten von TYPO3 stammen größtenteils aus Extensions, installiert aus dem TYPO3 Extension Repository oder selbst gebaut. Die tatsächliche Komplexität einer Website steckt in dieser Liste. Nehmen Sie vor jeder Entscheidung jede Extension auf, halten Sie fest, welche aktiv gepflegt werden, welche eigene Entwicklungen sind und welche tragend sind, denn dieser Bestand ist der mit Abstand beste Indikator dafür, wie viel Arbeit jede Option bedeutet.

Tief verschachtelte Seitenbäume sind eine Frage der Modellierung. TYPO3 ordnet Inhalte in einem Seitenbaum, der tief werden kann und viel Struktur und Logik in seiner Hierarchie trägt. Der Wechsel zu einem System, das um Collections mit strukturierten Inhalten herum gebaut ist, bedeutet zu entscheiden, wie dieser Baum zu Typen und Beziehungen wird, und das ist eine Modellierungsaufgabe, keine Kopie.

Seien Sie fair zu dem, was TYPO3 gut kann

Die Handhabung von Mehrsprachigkeit und Multi-Site in TYPO3 ist wirklich stark, und sie ist ein großer Teil des Grundes, warum Unternehmen im gesamten deutschsprachigen Markt es einsetzen. Viele Websites und viele Sprachen aus einer Installation heraus zu verwalten, mit feiner Kontrolle darüber, wie Übersetzungen und Site-Konfigurationen zueinander stehen, macht TYPO3 seit Jahren gut und gibt es nicht leichtfertig auf. Jeder ehrliche Vergleich beginnt damit, das anzuerkennen, denn ein Team, das einen Wechsel abwägt, muss wissen, dass es diese Fähigkeit anderswo selbst übernehmen würde, statt sie geschenkt zu bekommen. Wenn mehrsprachige Multi-Site-Verwaltung auf diesem Niveau der Kern dessen ist, was Ihre TYPO3-Installation für Sie leistet, spricht das für einen Verbleib, und es gehört vor allem anderen abgewogen.

TYPO3 ist außerdem kostenlos und quelloffen unter der GNU General Public License, wird von einer großen Community aktiv gepflegt, und die kostenpflichtigen ELTS- und Supportangebote stehen neben dem freien Kern, statt ihn zu verschließen. Es zu verlassen ist eine Entscheidung über Passung, keine Flucht vor einer Lizenz.

Was Payload tatsächlich ist

Payload ist ein quelloffenes CMS und Anwendungsframework auf Basis von Next.js und TypeScript, aktiv gepflegt, MIT-lizenziert und kostenlos selbst zu hosten, ohne Gebühr pro Nutzer oder pro Jahr. Einige seiner Eigenschaften sind für ein Team, das einen Wechsel weg von TYPO3 abwägt, unmittelbar relevant.

Sie modellieren Inhalte im Code. In Payload werden Ihre Collections, Felder und Zugriffsregeln in TypeScript geschrieben, in Ihrem Repository, unter Versionskontrolle. Die Form Ihrer Inhalte ist der Code selbst, sodass sie sich wie der Rest der Anwendung prüfen, vergleichen und ausliefern lässt, statt in einer eigenen Konfigurationssprache und einem Admin-Schema zu liegen.

Ihr CMS und Ihr Frontend sind ein Projekt. Seit Version 3.0, veröffentlicht im November 2024, installiert sich Payload direkt in eine Next.js-Anwendung, sodass CMS und Frontend eine Codebasis teilen und in einem Deploy ausgeliefert werden. Für ein Team, das PHP, TypoScript und Fluid verlässt, führt das den Stack auf eine Sprache über Frontend und Backend hinweg zusammen.

Der Stack ist JavaScript und TypeScript. Das ist ein Vorteil, wenn Ihr Team bereits dort ist oder dorthin will, und ein Preis, wenn Ihre Leute tief in PHP stecken und zufrieden sind. Payload wurde im Juni 2025 von Figma übernommen und bleibt quelloffen und in aktiver Entwicklung, sodass hinter dem Projekt ein gut finanziertes Unternehmen steht und eine MIT-Lizenz, die den Code unabhängig davon bei Ihnen belässt.

TYPO3 v12 vs. v13 vs. v14 vs. ELTS vs. Payload

	TYPO3 v12	TYPO3 v13 LTS	TYPO3 v14 LTS	TYPO3 v12 ELTS	Payload
Kostenloser Support	Endete 30. April 2026	Sicherheit bis Dezember 2027	Sicherheit bis Juni 2029	Kostenpflichtiges Abo	Aktiv, quelloffen
Kern-Stack	PHP	PHP	PHP	PHP	Next.js, TypeScript
Templating	Fluid / TypoScript	Fluid / TypoScript	Fluid / TypoScript	Fluid / TypoScript	Next.js (React)
Wechsel nötig	Frist verstrichen	Schrittweises Upgrade	Schrittweises Upgrade	Keiner (Brücke)	Neubau
Mehrsprachig / Multi-Site	Stark, nativ	Stark, nativ	Stark, nativ	Stark, nativ	Selbst gebaut oder integriert
Lizenz	GPL, freier Kern	GPL, freier Kern	GPL, freier Kern	GPL-Kern + bezahlter Support	MIT, frei
Bindung	Ökosystem	Ökosystem	Ökosystem	Ökosystem	Der Code gehört Ihnen

Die Tabelle ist ein Ausgangspunkt. Die Zeile, die am meisten entscheidet, ist „Wechsel nötig“: Drei dieser Optionen halten Sie auf TYPO3, und nur Payload verlangt einen Neubau, weshalb die eigentliche Frage lautet, ob Sie im Ökosystem bleiben wollen. Unter den Zielen innerhalb des Ökosystems kauft v14 den längsten kostenlosen Vorlauf.

Wie eine Migration von TYPO3 zu Payload abläuft

Wenn Sie sich für den Abschied entscheiden, zerfällt die Arbeit in fünf Etappen. Keine davon ist exotisch, und die erste bestimmt, wie schwer die übrigen werden.

Zuerst die TYPO3-Instanz prüfen

Bevor Daten bewegt werden, kartieren Sie, was Sie haben. Der Bestand an Extensions steht im Zentrum: jede Extension aus dem Repository, jede eigene Extension und was jede davon tatsächlich tut. Daneben erfassen Sie Ihre Inhaltstypen, die Form des Seitenbaums, jede TypoScript-Konfiguration, die echte Logik trägt, die Fluid-Templates, Integrationen von Drittanbietern, geplante Aufgaben sowie das mehrsprachige und Multi-Site-Setup. In dieser Prüfung stecken die Überraschungen, und sie jetzt zu finden ist weit billiger, als sie beim Umschalten zu finden.

Den Seitenbaum auf Payload-Collections abbilden

In TYPO3 leben Ihre Inhalte im Seitenbaum und in Extension-Datensätzen. In Payload leben sie in Collections, jede definiert als TypeScript-Konfiguration mit typisierten Feldern, Beziehungen und Zugriffsregeln.

Die Abbildung ist selten eins zu eins, und darin liegt die Chance. Das Ende des kostenlosen Supports ist ein guter Moment, das Inhaltsmodell in Ordnung zu bringen, das Sie schon lange in Ordnung bringen wollten, sodass aus einem tief verschachtelten Zweig des Seitenbaums eine schlanke Collection plus Beziehungen wird, die abbilden, wie die Inhalte heute tatsächlich genutzt werden. Ein TYPO3-News-Datensatz zum Beispiel wird zu einer Payload-Collection:

import type { CollectionConfig } from 'payload'

export const News: CollectionConfig = {
  slug: 'news',
  admin: { useAsTitle: 'title' },
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'slug', type: 'text', required: true, unique: true },
    { name: 'body', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'authors' },
    { name: 'publishedAt', type: 'date' },
  ],
}

Diese Konfiguration ist das gesamte Schema. Sie erzeugt die Datenbanktabellen, die Admin-Oberfläche und vollständig typisierte API-Antworten, und sie liegt in Ihrem Repository, wo sie mit dem übrigen Code geprüft und ausgeliefert wird.

Inhalte und Medien migrieren

Sind die Ziel-Collections definiert, schreiben Sie ein Migrationsskript, das aus TYPO3 liest und über Payloads Local API schreibt, die serverseitigem Code erlaubt, Datensätze direkt abzufragen und anzulegen, ohne HTTP-Umweg. Sie holen Datensätze aus der TYPO3-Datenbank, überführen jeden in die neue Form, behandeln die mehrsprachigen Varianten ausdrücklich, damit keine Sprache verloren geht, und legen sie in Payload im Code an. Die Medien wandern zu Ihrem gewählten Speicher-Adapter, ob S3, Vercel Blob oder ein anderer Anbieter, und das Skript schreibt die Verweise unterwegs um. Weil der Import über Payloads eigene API statt über rohes SQL läuft, fangen Validierung und Hooks fehlerhafte Altdaten während der Migration ab statt nach dem Launch.

Das Frontend in Next.js neu bauen

Wenn Sie auf Payload sind, sind Sie auf Next.js, sodass das Frontend eine React-Anwendung ist, die Inhalte über die Local API liest. Fluid-Templates und TypoScript-Rendering-Logik lassen sich nicht portieren; sie werden als React-Komponenten neu gebaut. Für eine Website mit einem klar umrissenen Satz von Templates ist das planbare Arbeit, und sie ist meist der größte einzelne Brocken des Projekts. Das mehrsprachige und Multi-Site-Verhalten neu zu bauen, das TYPO3 Ihnen nativ gegeben hat, gehört ebenfalls hierher, und es ist echter Umfang, den man einplanen muss, statt ihn vorauszusetzen.

Weiterleitungen, SEO und QA

Die Migration ist nicht fertig, wenn die Inhalte gelandet sind. Bilden Sie jede alte TYPO3-URL auf ihren neuen Pfad ab und richten Sie 301-Weiterleitungen ein, damit die aufgebaute Sichtbarkeit in der Suche erhalten bleibt. Übernehmen Sie Metadaten, Canonical-Tags, Sitemaps und strukturierte Daten und achten Sie besonders auf die URLs je Sprache. Testen Sie dann gegen die alte Website, Seite für Seite und Sprache für Sprache: Inhaltsgleichheit, Weiterleitungen, Formulare, Integrationen und Core Web Vitals. Diese Etappe schützt den Traffic, der das ganze Projekt rechtfertigt, also planen Sie dafür echte Zeit ein.

Wie lange es dauert und was es kostet

Migrationszeitpläne folgen eher der Komplexität als der Plattform. Als grober Richtwert landet eine kleine oder mittelgroße TYPO3-Website im Bereich von drei bis sechs Monaten, und ein großer, stark erweiterter, mehrsprachiger Aufbau läuft sechs bis zwölf Monate. Der Bestand an Extensions und die Zahl der aktiven Sprachen schieben ein Projekt in diesem Bereich nach oben; eine sauberere Website mit einem aufgeräumten Inhaltsmodell landet weiter unten.

Über die Kostenform lohnt es sich, deutlich zu sein. Eine Migration ist ein einmaliger Projektaufwand, und auf TYPO3 zu bleiben ist ebenfalls nicht kostenlos: Ein Upgrade auf v13 oder v14 ist echte Entwicklungsarbeit, und ELTS ist ein wiederkehrendes kostenpflichtiges Abonnement. Wo Payload die laufende Rechnung verändert, ist der Kern ohne Lizenzgebühr, sodass Sie nach dem Launch für Infrastruktur zahlen statt für Supportansprüche. Ob diese Ersparnis einen Neubau wert ist, hängt stark davon ab, wie hoch Sie die nativen Stärken von TYPO3 bei Mehrsprachigkeit und Multi-Site bewerten, die Sie neu bauen würden.

Beginnen Sie früh mit der Planung. Die meisten Teams wollen zwölf bis achtzehn Monate Vorlauf, um Erkundung, Plattformentscheidung, Migration und SEO-Erhalt zu bewältigen, ohne das Umschalten zu überstürzen. Da der kostenlose v12-Support bereits geendet hat, ist ELTS oder ein Upgrade auf v13 oder v14 oft die sinnvolle Brücke, die diesen Vorlauf kauft, unabhängig davon, welches Ziel Sie am Ende wählen.

Wann Sie auf TYPO3 bleiben sollten

Payload ist nicht für alle die richtige Antwort, und für viele TYPO3-Bestände ist Bleiben die bessere Entscheidung. Vier Situationen sprechen dafür.

1. Sie haben kürzlich auf v13 oder v14 aktualisiert. Wenn Sie bereits auf v13 LTS sind, haben Sie kostenlosen Sicherheitssupport bis Ende Dezember 2027, auf v14 LTS bis Ende Juni 2029. So oder so besteht kein unmittelbarer Druck. Nutzen Sie diesen Vorlauf, um bewusst zu planen, statt auf das v12-Datum zu reagieren.
2. Ihr Extension-Bestand ist umfangreich, aber gesund. Ein großer Bestand aktiv gepflegter, gut passender Extensions ist ein Vermögenswert, keine Last. Wenn er leistet, was Sie brauchen, und aktuell bleibt, ist ihn anderswo neu zu bauen ein Aufwand ohne entsprechenden Nutzen.
3. Sie haben ein internes TYPO3-Team. Wenn Ihre Entwickler in TYPO3, PHP, TypoScript und Fluid produktiv sind und Ihnen das Einstellen auf diesen Stack leichtfällt, tauscht der Wechsel zu TypeScript ein eingespieltes Team gegen eine Ersparnis, die es womöglich nicht schätzt.
4. ELTS deckt eine Roadmap ab, die Sie ohnehin haben. Wenn Ihre Pläne bis 2027 oder darüber hinaus reichen und ELTS v12 über dieses Fenster hinweg sicher hält, kann der Kauf der Brücke die rationale, störungsarme Wahl sein, während größere Entscheidungen warten.

Die Wahl läuft also darauf hinaus, ob die Plattform passt. Wenn die native Handhabung von Mehrsprachigkeit und Multi-Site in TYPO3 zentral für das ist, was Sie tun, und Ihr Team im Ökosystem zu Hause ist, ist Bleiben, ob auf v13, v14 oder ELTS, eine solide Entscheidung. Wenn Sie lieber Ihren Stack besitzen, Ihr Inhaltsmodell im Code schreiben, CMS und Frontend als eine Next.js-Anwendung betreiben und auf TypeScript konsolidieren wollen, ist das der Fall für Payload, und das ist die Arbeit, die wir machen.

Wo WAYF hineinpasst

WAYF ist offizieller Payload-Partner und Top Contributor, und wir haben Content-Plattformen auf Payload und Next.js für Unternehmen, öffentliche Institutionen und schnell wachsende Teams gebaut. Die Migration weg von Alt- und End-of-Life-Systemen ist ein Kernstück unserer Arbeit. Das Ende des kostenlosen TYPO3-Supports löst dieses Jahr bei vielen Teams dieselbe Überprüfung aus, und wir helfen ihnen, die Entscheidung ehrlich zu treffen, einschließlich der Fälle, in denen ein Verbleib auf v13, v14 oder ELTS die richtige Antwort ist, und führen die Migration dann aus, wenn sie es nicht ist: die Prüfung, das Inhaltsmodell, den Datenumzug mit intakten Sprachen, das Next.js-Frontend und das SEO-sichere Umschalten.

Wenn Sie ein Upgrade auf v13 oder v14 oder ELTS gegen einen Wechsel zu Payload abwägen, sehen wir uns Ihre tatsächliche TYPO3-Instanz an und sagen Ihnen, welcher Weg passt.

Buchen Sie ein Gespräch, und wir sagen Ihnen, ob Payload der richtige Schritt für Ihre Website ist.

FAQ

1. Wann endete der Support für TYPO3 v12 LTS?

   Der kostenlose Community-Support für TYPO3 v12 LTS endete am 30. April 2026. Ab dem 1. Mai 2026 stellt die TYPO3-Community keine Wartung und keine Sicherheitsupdates mehr dafür bereit. Der kostenpflichtige Extended Long Term Support (ELTS) der TYPO3 GmbH liefert über dieses Datum hinaus mehrere Jahre lang weiter Sicherheitskorrekturen.

2. Soll ich auf TYPO3 v13 oder v14 aktualisieren oder wegmigrieren?

   Alles ist vertretbar. Sowohl v13 als auch v14 LTS halten Sie im Ökosystem und sind schrittweise Upgrades statt Neubauten. TYPO3 v13 LTS hat kostenlosen Sicherheitssupport bis Ende Dezember 2027; TYPO3 v14 LTS ist das aktuelle Flaggschiff und läuft bis Ende Juni 2029, bietet also den längeren Vorlauf. Wegzumigrieren ergibt Sinn, wenn Ihre Gründe zu gehen über diese eine Frist hinausgehen. Wenn die Stärken von TYPO3 bei Mehrsprachigkeit und Multi-Site für Ihre Website zentral sind, ist ein Upgrade oft die bessere Entscheidung.

3. Was ist TYPO3 ELTS?

   ELTS, Extended Long Term Support, ist ein kostenpflichtiges Abonnement der TYPO3 GmbH, das Sicherheits- und Kompatibilitätsupdates für eine TYPO3-Version fortführt, nachdem deren kostenloser Community-Support endet. Für v12 läuft es drei zusätzliche Jahre, mit einem exklusiven vierten Jahr für TYPO3-Partner, womit das Fenster äußerstenfalls bis zum 30. April 2030 reicht. Es funktioniert als legitime Brücke, während Sie einen größeren Wechsel planen.

4. Kann man von TYPO3 zu einem Headless-CMS wie Payload migrieren?

   Ja. Sie prüfen den Bestand an Extensions, bilden den Seitenbaum auf Payload-Collections ab, die in TypeScript definiert sind, schreiben ein Migrationsskript, das Inhalte und Medien über Payloads API importiert und die Sprachen dabei ausdrücklich behandelt, bauen das Frontend in Next.js neu und richten 301-Weiterleitungen ein, um die SEO zu erhalten.

5. Wie lange dauert eine Migration von TYPO3 zu Payload?

   Als grober Richtwert brauchen kleine und mittelgroße Websites drei bis sechs Monate und große, stark erweiterte, mehrsprachige Websites sechs bis zwölf. Der Bestand an Extensions und die Zahl der aktiven Sprachen sind die wesentlichen Treiber.

6. Ist Payload CMS kostenlos?

   Payload ist quelloffen unter der MIT-Lizenz und kostenlos selbst zu hosten. Sie zahlen nur für Ihre eigene Infrastruktur, etwa Datenbank, Dateispeicher und Node-Hosting. Es gibt keine jährliche Plattformlizenzgebühr. Der Kern von TYPO3 ist ebenfalls kostenlos und quelloffen unter der GPL; das kostenpflichtige ELTS und der Support stehen daneben.

---

Quellen: TYPO3 v12 LTS end of free support, TYPO3 ELTS for v12.4, TYPO3 v13 LTS release announcement, TYPO3 v14 LTS release announcement, TYPO3 Development Roadmap, TYPO3 open source licenses, Payload GitHub, Payload, Figma: Welcoming Payload.