Wie viel kostet ein TYPO3 Update?

Ein TYPO3-Update ist mehr als das Einspielen einer neuen Core-Version. In der Praxis hängt der Aufwand (und damit der Preis) stark davon ab, wie „gewachsen“ ein System ist: Welche TYPO3-Version läuft aktuell, welche Extensions sind im Einsatz, wie viele Eigenentwicklungen gibt es und welche externen Systeme sind angebunden. Wer diese Faktoren sauber betrachtet, kann den Aufwand realistisch einschätzen und Überraschungen im Projekt vermeiden.

Wichtige Faktoren für die Kostenkalkulation

1. Wie alt ist die aktuelle TYPO3-Version?

Je größer der Versionssprung, desto mehr technische Änderungen müssen berücksichtigt werden. Ein Update von einer relativ aktuellen LTS-Version (z. B. v12 → v13) ist meist deutlich planbarer als ein Sprung über mehrere Hauptversionen (z. B. v9 → v13/v14). Bei älteren Systemen treffen häufig mehrere Themen zusammen: veraltete PHP-Versionen, ältere Template-/Extension-Architekturen, Legacy-TypoScript oder nicht mehr unterstützte APIs. Das erhöht den Analyse- und Migrationsaufwand, aber vor allem auch die Testzeit, weil sich viele „kleine“ Änderungen im Zusammenspiel bemerkbar machen.

2. Wie viele und vor allem welche Extensions werden genutzt?

Nicht nur die Anzahl, sondern vor allem die Art der Extensions entscheidet über den Aufwand. Ein System mit wenigen, etablierten Standard-Extensions (z. B. news, powermail, redirect) lässt sich meist gut aktualisieren. Kritischer wird es, wenn viele Extensions tief ins System eingreifen (z. B. Frontend-Login-Workflows, komplexe Inhaltelemente, Routing, Solr/Elasticsearch, Form-Framework-Erweiterungen, Individual-Backend-Module). Solche Erweiterungen beeinflussen häufig zentrale TYPO3-APIs und erfordern bei Versionswechseln mehr Anpassung und intensivere Tests.

3. Third-Party-Extensions (TER) vs. Eigenentwicklungen

Hier liegt in vielen Projekten der größte Kostentreiber:

• TER-/Third-Party-Extensions: Wenn eine Extension aktiv gepflegt wird und eine kompatible Version für die Ziel-TYPO3-Version existiert, ist die Migration oft relativ gut kalkulierbar: Update via Composer/TER, Konfiguration prüfen, testen.

• Eigenentwicklungen: Jede Eigenextension muss manuell geprüft und für die neue TYPO3-Version kompatibel gemacht werden. Dazu gehören Code-Anpassungen (API-Änderungen, PHP-Anpassungen), TCA/TSconfig, Fluid-Templates, Custom-ViewHelpers, Scheduler-Tasks, Hooks/Events usw. Je mehr Eigenlogik, desto höher der Aufwand.

   

4. Gibt es für TER-Extensions kompatible Versionen?

Ein zentraler Schritt der Update-Planung ist ein „Extension-Audit“: Für jede eingesetzte TER-Extension wird geprüft, ob es eine Version gibt, die offiziell zur Zielversion passt (z. B. TYPO3 v13 oder v14). Wenn ja, wird die Extension aktualisiert und getestet. Wenn nein, gibt es typischerweise drei Wege:

1. Extension ersetzen (wenn es eine moderne Alternative gibt)
2. Extension patchen/anpassen (wenn der Code überschaubar ist und Lizenz/Repo das zulässt)
3. Funktion entfernen (wenn sie nicht mehr benötigt wird)

Dieser Punkt ist in der Praxis extrem wichtig, weil „nicht kompatible“ Extensions ein Update blockieren können – oder später zu Bugs führen, die erst im Betrieb auffallen.

5. Was tun mit Eigenentwicklungen und nicht gepflegten Third-Party-Extensions?

Eigenentwicklungen müssen in jedem Fall aktiv migriert werden. Zusätzlich gilt: Third-Party-Extensions ohne kompatible Version müssen entweder angepasst oder abgelöst werden. Hier lohnt sich oft ein pragmatischer Ansatz: Zuerst bewerten, wie kritisch die Funktion ist, wie groß der Anpassungsaufwand wäre und ob es am Markt eine etablierte Alternative gibt. Ein sauberer Ersatz kann langfristig günstiger sein als ein „dauerhaftes Mitziehen“ einer ungepflegten Extension bei jedem Major-Update.

6. Externe Schnittstellen: mehr Abstimmung, mehr Tests

Schnittstellen zu Drittsystemen erhöhen den Aufwand oft erheblich – weniger wegen der reinen Codeänderung, sondern wegen Koordination und Test. Typische Beispiele sind CRM/ERP-Anbindungen, Newsletter-Tools, Single-Sign-On, Zahlungsanbieter, PIM-Systeme, Jobbörsen, DAM/Media-Services oder individuelle REST-APIs. Hier müssen nicht nur TYPO3-seitig Anpassungen geprüft werden, sondern auch:

• Versionen und Änderungen auf der Gegenseite
• Testaccounts, Testdaten, Testumgebungen
• Abstimmung mit externen Dienstleistern
• Abnahmetests mit klaren Testfällen