Von TYPO3 v12 auf v14 — der Sprung, der jetzt ansteht.

Welches Ziel sinnvoll ist.

Die Frage lautet nicht „v13 oder v14“, sondern „wie lange soll Ruhe sein“. v13 wird noch bis Ende 2027 versorgt — bei einem Upgrade, das Monate Vorlauf braucht, bleibt davon wenig übrig. v14 reicht bis Mitte 2029, mit kostenpflichtiger Verlängerung darüber hinaus.

Für v13 als Ziel spricht nur ein Fall: Eine geschäftskritische Extension gibt es noch nicht für v14, und es gibt keinen Ersatz. Dann ist v13 der Zwischenhalt — mit der klaren Erwartung, dass der nächste Sprung in gut einem Jahr folgt. Diese Entscheidung gehört dokumentiert, damit sie nicht in Vergessenheit gerät.

Direkt oder über v13.

Technisch lässt sich von v12 direkt auf v14 gehen — der Weg ist vorgesehen. Die Upgrade-Schritte bauen zwar aufeinander auf, werden beim direkten Sprung aber nacheinander abgearbeitet. In der Praxis spricht meist nichts dagegen, und der direkte Weg spart einen vollständigen Testdurchlauf.

Für den Zwischenschritt über v13 spricht, wenn die Installation groß und unübersichtlich ist: Dann lassen sich Probleme leichter zuordnen, weil weniger gleichzeitig passiert. Der Preis dafür ist ein zweiter kompletter Durchlauf mit Test und Abnahme.

Was sich ändert.

Der letzte Punkt ist der, der eigenen Code trifft: Was in v12 noch mit einer Warnung funktionierte, ist in v14 weg. Genau deshalb sind Eigenentwicklungen und angepasste Templates der aufwendigste Teil.

Die überarbeitete Oberfläche ist kein technisches, aber ein organisatorisches Thema: Plane eine Stunde Einweisung für die Redaktion ein. Sonst landen die ersten Wochen nach dem Livegang als Supportanfragen bei dir.

Extensions prüfen.

Das ist der Teil, der über Aufwand und Zeitplan entscheidet. Gehe die Liste im Erweiterungsmanager durch und sortiere in vier Gruppen:

1. Gibt es für v14 — aktualisieren, Änderungsprotokoll lesen.
2. Gibt es nicht, wird nicht gebraucht — entfernen. Der beste Fall, und häufiger als gedacht.
3. Gibt es nicht, Funktion wird gebraucht — Ersatz suchen oder Anpassung kalkulieren.
4. Eigenentwicklung — Aufwand schätzen, Dokumentation suchen.

Für Gruppe zwei lohnt eine klare Frage an alle Beteiligten: Vermisst jemand etwas, wenn das weg ist? Wenn nach zwei Wochen niemand widerspricht, ist die Antwort klar. Diese Aufräumrunde senkt den Aufwand oft mehr als jede technische Optimierung (Extensions bewerten).

Templates und Frontend.

Bei einer Installation mit eigenem Template ist das der zweitgrößte Posten. Die Vorlagensprache bleibt im Kern dieselbe, aber einzelne Funktionen und Schnittstellen ändern sich — und was in v12 nur eine Warnung erzeugte, bricht in v14. Der Aufwand hängt davon ab, wie nah das Template am Standard gebaut wurde.

Gute Nachricht für Installationen mit einem gekauften, gepflegten Theme: Dort liefert der Hersteller meist eine passende Fassung. Schlechte Nachricht für selbst gebaute Templates aus der Zeit vor v10: Die brauchen Zuwendung. Plane dafür einen eigenen Posten ein, statt es im Gesamtaufwand untergehen zu lassen.

Der Ablauf.

1. Bestandsaufnahme: Version, PHP, Extensions, Templates, Eigenentwicklungen (Upgrade-Kosten).
2. Serverumgebung klären: Unterstützt der Hoster die nötige PHP-Version?
3. Backup von Dateien und Datenbank, Wiederherstellung testen.
4. Testumgebung als Kopie der Live-Installation aufsetzen.
5. Aufräumen: nicht genutzte Extensions und Altdaten entfernen.
6. Upgrade in der Testumgebung, dann Caches, Datenbankabgleich, Upgrade-Wizard vollständig.
7. Testen lassen — technisch von dir, fachlich von der Redaktion.
8. Livegang außerhalb der Hauptzeiten, mit Rückweg.
9. Nachkontrolle über zwei Wochen, Protokolle im Blick.

Schritt sieben wird am häufigsten gekürzt und rächt sich am häufigsten. Die Redaktion findet Dinge, die in keinem technischen Test auffallen — genau dafür ist sie da.

Realistischer Zeitplan.

Für eine überschaubare Installation mit wenigen Standard-Extensions und gepflegtem Theme: ein bis zwei Wochen von Bestandsaufnahme bis Livegang, mit einigen Tagen echter Arbeitszeit. Für eine typische gewachsene Mittelstandsinstallation mit eigenem Template und einem Dutzend Extensions: vier bis acht Wochen Durchlaufzeit, weil Abstimmung, Tests und Nachbesserungen Zeit brauchen. Für große Installationen mit Eigenentwicklungen und mehreren Mandanten: ein Quartal und mehr.

Der Faktor, der den Zeitplan am meisten beeinflusst, ist nicht die Technik, sondern die Verfügbarkeit von Entscheidungen: Wer kann sagen, dass eine Extension wegfallen darf? Klär das vorher, dann halbiert sich die Durchlaufzeit.

Die Stolpersteine.

• PHP-Version auf der Kommandozeile weicht von der im Webserver ab — Befehle laufen, die Website nicht (Update-Fehler).
• Upgrade-Wizard nicht vollständig durchgelaufen — Felder fehlen, Listen bleiben leer.
• Caches nicht geleert, alter erzeugter Code bleibt aktiv (Cache leeren).
• Site-Konfiguration nicht geprüft — Unterseiten liefern 404 (Seite nicht gefunden).
• Bildverarbeitung auf dem neuen Server nicht eingerichtet (Bilder fehlen).
• Mailversand nach dem Sprung nicht getestet (E-Mails).

Nach dem Sprung.

Zwei Dinge gehören direkt im Anschluss erledigt. Erstens: die laufende Pflege aufsetzen, damit der nächste Sprung kleiner wird — Sicherheitsupdates innerhalb der Hauptversion sind schnell eingespielt, wenn jemand zuständig ist (TYPO3-Wartung). Zweitens: dokumentieren, was gemacht wurde, welche Extensions entfallen sind und warum. Beim nächsten Mal ist das die Abkürzung — und wenn jemand anderes übernimmt, die halbe Miete.

Und wenn sich bei der Bestandsaufnahme herausstellt, dass der Aufwand in keinem Verhältnis zum Nutzen steht, gehört die Grundsatzfrage auf den Tisch, bevor Geld fließt: Ist TYPO3 für diese Website noch das richtige System (TYPO3 oder WordPress)?

Wenn du nicht weiterkommst.

Wenn du von v12 kommst und wissen willst, was der Sprung in deinem Fall bedeutet, mache ich die Bestandsaufnahme. Schreib mir mit Domain, TYPO3-Version und einer kurzen Beschreibung — du bekommst eine ehrliche Einschätzung, ob ich der Richtige bin. Den Überblick über alle Themen gibt TYPO3-Fehler beheben. Wenn sich am Ende herausstellt, dass ein Wechsel die bessere Lösung ist: TYPO3 zu WordPress.

Orientierungswerte, keine Fixpreise — nach einem kurzen Gespräch bekommst du ein Festpreisangebot.

Wer hilft.

Ich bin Manuel Killert, Web-Entwickler aus Quakenbrück. Mein Schwerpunkt liegt auf WordPress — an TYPO3-Installationen arbeite ich dort, wo es um Betrieb und Fehlersuche geht: Ausfälle, Serverthemen, Datenbank, Mailversand, Updates und die Frage, wie es mit einer alten Installation weitergehen soll. Das sind die Probleme, bei denen die Ursache meist nicht im System selbst liegt, sondern darunter. Geht es um tiefe Entwicklung in TYPO3 — eigene Extensions, komplexe Mehrsprachigkeit, große Redaktionssysteme —, sage ich dir das offen und empfehle jemanden, der genau das macht. Ehrlich beraten heißt für mich auch, eine Anfrage abzugeben.