Upgrade statt Flickwerk
Wenn v10 noch produktiv läuft, entstehen Wartungsrisiken meist an mehreren Stellen gleichzeitig: Core, PHP, Extensions, Build-Tools und individuelle Integrationen.
TYPO3 v10 LTS · Legacy-Modernisierung · v14 LTS · PHP, Composer, Extensions & Tests
Ein Upgrade von TYPO3 v10 auf v14 ist meist kein kleines Core-Update, sondern eine technische Modernisierung: Extensions, PHP-Version, Composer-Abhängigkeiten, Sitepackage, Backend-Workflows und Tests müssen zusammen betrachtet werden. Ziel ist ein belastbarer Pfad zur aktuellen LTS-Generation, ohne das Live-System unnötig zu riskieren.
Einordnung
Der direkte Zielstand v14 lohnt sich, wenn ohnehin eine größere technische Bereinigung ansteht: alte Drittanbieter-Extensions, individuelle Content-Elemente, ein gewachsenes Sitepackage, unklare Deployment-Prozesse oder Support-Druck. Ein Zwischenschritt kann intern nötig sein, aber das fachliche Ziel sollte heute meist die aktuelle LTS-Generation sein.
Wenn v10 noch produktiv läuft, entstehen Wartungsrisiken meist an mehreren Stellen gleichzeitig: Core, PHP, Extensions, Build-Tools und individuelle Integrationen.
Nicht jedes v10-System muss neu gebaut werden. Oft reicht ein strukturierter Upgrade-Pfad mit gezieltem Refactoring und klar begrenztem Frontend- oder Extension-Umbau.
Roadmap
1. Audit
Versionen, Extensions, Composer, PHP, Datenbank, Templates, Schnittstellen und Risiken erfassen.
2. Pfad
Upgrade-Schritte, Branches, Datenmigrationen, Extension-Ersatz und Testfenster festlegen.
3. Umsetzung
Deprecations, Extensions, Sitepackage, PHP-Code, Fluid-Templates und Build-Prozesse aktualisieren.
4. Go-Live
Smoke-Tests, Redaktionscheck, Monitoring, Backup, Rollback-Plan und Nachbetreuung absichern.
Veraltete Extensions werden nicht blind mitgeschleppt. Ich prüfe, ob Update, Ersatz, Eigenentwicklung oder Funktionseinbau in den Core-nahen Bereich sinnvoll ist.
Alte Fluid-Patterns, TypoScript, CSS/JS-Builds und Content-Elemente werden so angepasst, dass sie in v14 wartbar, performant und redaktionell sicher bleiben.
Solr/Elasticsearch, DAM, CRM, SSO, Formularstrecken und Importprozesse brauchen eigene Testfälle, damit das Upgrade keine versteckten Prozessbrüche erzeugt.
Gerade bei größeren Versionssprüngen zählt ein prüfbarer Ablauf: Staging, Smoke-Tests, Redaktionsabnahme, Monitoring und ein realistischer Rückweg.
Schicken Sie mir Version, Hosting-Setup, Extension-Liste oder einen kurzen Problemabriss. Ich melde mich mit einer ersten Einschätzung und einem sinnvollen nächsten Schritt.