We have many custom extensions. Does this still work?

Yes, but with honesty about the effort. Custom extensions without tests, without clear architecture and with direct core patches are the most expensive variant — with or without an agent. The refactoring agent surfaces such places and prioritises them. The decision “rewrite or migrate” is then made by a human, with our findings.

How much faster does this actually get?

For a typical mid-sized TYPO3 installation with 8–15 custom extensions, the analysis phase shrinks from 1–2 weeks to 1–2 days, the migration phase from 4–6 weeks to 2–3 weeks. The time saved has not “disappeared” — it goes into validation and polish, which ultimately raises quality.

What about extensions the vendor has abandoned?

The extension compatibility agent recognises orphaned packages and suggests three routes: a fork with minimal adjustments, replacement with an equivalent active extension, or an in-house solution. Which route fits depends on the feature scope and the project relevance.

Does this also work for Sylius 1.x → 2.x?

Yes. The 1.x → 2.x leap is deliberately the use case where the agentic architecture has the greatest leverage — the Symfony jump, the API Platform migration, React Admin as the new default. Here, structured agent analysis replaces what would otherwise be the typical months of guesswork.

What about data migrations — can an agent handle that?

The migration agent plans and validates schemas, generates migration scripts and simulates upgrade paths against a copy snapshot of your database. Sign-off on production data migration is, however, made by a human. Data loss is a decision we do not delegate.

Agentic Upgrades für TYPO3 und Sylius

Wie wir Major-Upgrades — z. B. TYPO3 13 → 14 oder Sylius-Sprünge — mit spezialisierten KI-Agenten neu denken. Vom Ausnahmezustand zum kontinuierlich beherrschbaren Prozess.

29. April 2026

Die Realität von Major-Upgrades

Major-Upgrades in Systemen wie TYPO3 oder Sylius gehören zu den anspruchsvollsten Aufgaben im Betrieb komplexer Webplattformen. Sie sind selten „nur ein Versionssprung“ — sondern fast immer ein Eingriff in APIs, Extension-Ökosysteme, Datenmodelle, Build- und Deployment-Prozesse.

TYPO3

Entfernte oder veränderte APIs.
Anpassungen in Extensions (oft mehrere gleichzeitig).
Änderungen an TypoScript und Configuration.
Migration von Datenbankstrukturen.
Deprecation-Auflösung über mehrere Versionen hinweg.

Sylius

Symfony-Versions-Sprünge.
Änderungen im Dependency-Tree (Composer).
Anpassungen in Plugins und Custom Code.
Frontend- und API-Veränderungen.
Potenziell komplexe Migrationspfade.

Das Problem dabei ist nicht nur die Menge der Änderungen — sondern deren Wechselwirkungen.

Warum klassische Tools hier scheitern

Typische Tools liefern Deprecation-Logs, Composer-Konflikte und (oft fragmentierte) Dokumentation. Was sie nicht liefern: Priorisierung, Kontextverständnis, konkrete Migrationsstrategien, belastbare Entscheidungsgrundlagen. Senior-Engineering wird zum Flaschenhals.

Unser Ansatz: spezialisierte KI-Agenten pro System

Wir setzen nicht auf einen großen Agenten, sondern auf domänenspezifische Agenten, die TYPO3- bzw. Sylius-spezifisches Wissen nutzen.

Agentic Upgrade für TYPO3

1. Deprecation-Analyse-Agent

Aggregiert Logs aus Install Tool, Extension Scanner usw.
Mappt Deprecated APIs auf konkrete Code-Stellen.
Priorisiert nach Impact (Core vs. Extension vs. Custom Code).

2. Extension-Kompatibilitäts-Agent

Prüft alle installierten Extensions auf Versions-Kompatibilität.
Erkennt verfügbare Updates, verwaiste Extensions, notwendige Forks oder Ersatzlösungen.

3. Refactoring-Agent

Führt gezielte Code-Transformationen durch — API-Änderungen, Namespaces, Konfigurationsmigrationen.
Arbeitet inkrementell statt im Big-Bang-Modus.

4. Migrations-Agent

Plant und validiert Datenbank-Migrationen.
Simuliert Upgrade-Pfade.
Minimiert Downtime-Risiken.

5. Validierungs-Agent

Führt funktionale und integrative Tests aus.
Erkennt Regressionen auch außerhalb klassischer Testfälle.

Agentic Upgrade für Sylius

1. Dependency-Agent

Analysiert Composer-Constraints.
Plant Upgrade-Reihenfolge (Symfony → Sylius → Plugins).
Löst Konflikte strategisch statt durch Trial-and-Error.

2. Plugin-Agent

Prüft Kompatibilität aller Plugins.
Erkennt Breaking Changes in Drittanbieter-Code.
Schlägt Alternativen oder Anpassungen vor.

3. Code-Migrations-Agent

Refactored Symfony APIs, Event-Listener und -Subscriber, Service-Definitions.
Berücksichtigt projektspezifische Architektur.

4. API-/Frontend-Agent

Validiert API-Verhalten nach Upgrade.
Erkennt Contract-Brüche.
Unterstützt bei Anpassungen im Frontend.

5. Szenario-basierter Test-Agent

Führt reale Business-Flows aus — Checkout, Payment, Order Management.
Bewertet nicht nur „funktioniert / funktioniert nicht“, sondern Systemverhalten.

Der entscheidende Unterschied

Früher: Checklisten. Manuelle Analyse. Iteratives Debugging. Hoher Zeit- und Risikoaufwand.

Heute: Strukturierte Analyse durch Agenten. Automatisierte Refactorings. Kontextbasierte Entscheidungen. Nachvollziehbare Upgrade-Pfade.

Wir haben das Upgrade von einem Projekt in einen reproduzierbaren Prozess überführt.

Was das konkret bedeutet

Planbarkeit. Major-Upgrades werden kalkulierbar — auch bei großen Installationen.

Geschwindigkeit. Was früher Wochen dauerte, lässt sich oft in Tagen strukturieren und umsetzen.

Qualität. Weniger Regressionen, bessere Testabdeckung, klarere Entscheidungen.

Transparenz. Jeder Schritt ist dokumentiert — erkannte Probleme, getroffene Entscheidungen, durchgeführte Änderungen.

Grenzen und Realität

So leistungsfähig Agenten sind — sie haben Voraussetzungen: saubere Codebasis, funktionierende Tests, klare Architektur, disziplinierte Dependency-Pflege. Ohne diese Grundlagen wird auch ein KI-gestützter Ansatz ineffizient.

Fazit

Major-Upgrades in TYPO3 und Sylius bleiben anspruchsvoll — aber sie müssen kein unkalkulierbares Risiko mehr sein. Mit Agentic Upgrades haben wir Komplexität strukturiert, Wissen operationalisiert und Entscheidungen automatisiert. Vom „Upgrade als Ausnahmezustand“ hin zu einem kontinuierlich beherrschbaren Prozess.

TYPO3 13 → 14 oder Sylius-Sprung steht an?

Wenn ihr ein Major-Upgrade plant und es kalkulierbar machen wollt, schauen wir uns euer Setup gemeinsam an. 30 Minuten, an eurer Codebasis, ehrliche Einschätzung. Kostenfrei, unverbindlich.

Häufige Fragen

Was uns Kundinnen und Kunden zu Major-Upgrades mit KI-Agenten am häufigsten fragen — offen beantwortet.

Wir haben viele Custom-Extensions. Funktioniert das trotzdem?+

Ja, aber mit Ehrlichkeit beim Aufwand. Custom-Extensions ohne Tests, ohne klare Architektur und mit direktem Core-Patch sind die teuerste Variante — egal ob mit oder ohne Agent. Der Refactoring-Agent macht solche Stellen sichtbar und priorisiert sie. Die Entscheidung „neu schreiben oder migrieren“ trifft danach ein Mensch mit unserem Befund.

Wie viel schneller wird das wirklich?+

Bei einer typischen mittelgroßen TYPO3-Installation mit 8–15 Custom-Extensions verkürzt sich die Analyse-Phase von 1–2 Wochen auf 1–2 Tage, die Migrations-Phase von 4–6 Wochen auf 2–3 Wochen. Die eingesparte Zeit ist nicht „verschwunden“ — sie geht in Validierung und Polish, was am Ende die Qualität hebt.

Was passiert mit Extensions, die der Hersteller aufgegeben hat?+

Der Extension-Kompatibilitäts-Agent erkennt verwaiste Pakete und schlägt drei Wege vor: Fork mit minimaler Anpassung, Ersatz durch eine gleichwertige aktive Extension, oder Inhouse-Lösung. Welcher Weg passt, hängt vom Funktionsumfang und der Projektrelevanz ab.

Funktioniert das auch für Sylius 1.x → 2.x?+

Ja. Der Sprung 1.x → 2.x ist bewusst der Use Case, in dem die Agentic-Architektur den größten Hebel hat — Symfony-Sprung, API-Platform-Migration, React-Admin als neuer Standard. Hier ersetzt strukturierte Agenten-Analyse das ansonsten typische monatelange Rätselraten.

Was ist mit Datenmigrationen — kann das ein Agent?+

Der Migrations-Agent plant und validiert Schemas, generiert Migrations-Scripts und simuliert Upgrade-Pfade gegen einen Kopie-Snapshot eurer DB. Den Sign-off auf produktive Datenmigration macht aber ein Mensch. Datenverlust ist eine Entscheidung, die wir nicht delegieren.