1) Content & Informationsarchitektur
Wenn Seitenbaum, Content-Modelle und Workflows passen: Upgrade. Wenn Sie ohnehin alles neu strukturieren müssen: Relaunch (oder Hybrid).
Entscheidungshilfe · Kosten/ROI · Risiken · SEO · Zeitplan
TYPO3 Relaunch oder Upgrade?
So treffen Sie die richtige Entscheidung – ohne teure Umwege
In vielen Projekten ist die eigentliche Frage nicht „können wir upgraden?“, sondern: Upgrade oder Relaunch – was ist wirtschaftlich und technisch sinnvoll? Diese Seite hilft Ihnen, die Entscheidung strukturiert zu treffen – mit Kriterien, typischen Szenarien, Kosten-/Risiko-Treibern und einer Checkliste.
Antwort i. d. R. binnen 24–48 h (Mo–Fr) · NDA/AVV möglich
Faustregel
Upgrade lohnt sich meist, wenn…
- die Inhalte & Struktur grundsätzlich passen (kein kompletter Neuaufbau)
- Design/UX nur evolutionär angepasst werden soll
- es viele individuelle Extensions gibt, die Sie behalten wollen
- SEO-Risiko und Time-to-Value gering bleiben sollen
- Upgrades in planbaren Schritten möglich sind (v10→v12→v13 etc.)
Faustregel
Relaunch ist oft sinnvoll, wenn…
- Informationsarchitektur, Content & UX grundlegend neu gedacht werden müssen
- das Setup historisch gewachsen und nicht mehr reparierbar ist (extreme Tech-Debt)
- viele Legacy-Extensions / Hacks vorhanden sind, die niemand mehr verantworten möchte
- ein neues Designsystem/Frontend „von Grund auf“ geplant ist (z. B. Headless/SPA)
- ein Plattform-Wechsel (z. B. TYPO3→Headless oder anderes CMS) bewusst gewünscht ist
In der Praxis ist es oft keine Entweder-oder-Frage: Der schnellste Weg ist häufig „Upgrade zuerst, Relaunch später“ – weil Sie dadurch Risiken reduzieren, Security gewinnen und das Team wieder arbeitsfähig machen, bevor Sie das große Re-Design starten.
Die 8 wichtigsten Faktoren für die Entscheidung
Diese Punkte entscheiden oft stärker als „Version alt“ oder „Design gefällt nicht“.
2) Individuelle Extensions & Integrationen
Viele eigene Extensions + Schnittstellen sprechen eher für Upgrade/Refactor. Ein Relaunch bedeutet oft: alles neu bauen – inklusive Abhängigkeiten & Tests.
3) Risiko & Security (EOL/ELTS)
Wenn Security-Fixes dringend sind, ist ein „Upgrade-First“ oft die schnellste Risikoreduktion – selbst wenn später ein Relaunch folgt.
4) Release-Fähigkeit (CI/CD, Tests, Deployment)
Wenn Deployments chaotisch sind, eskaliert jeder Relaunch. Erst Stabilität (Build/CI/CD/Tests), dann große Änderungen – sonst wird das Projekt zum Dauerrisiko.
5) SEO- & Tracking-Risiko
Relaunch kann Rankings kosten (URLs, Inhalte, interne Verlinkung, Render-Setup). Upgrade ist SEO-seitig oft risikoärmer, solange Templates nicht komplett umgekrempelt werden.
6) Backend-UX für Redaktion
Wenn Workspaces, Rollen, TCA, Content-Elemente „nicht mehr tragbar“ sind, kann ein gezielter Refactor im Upgrade viel erreichen – ohne kompletten Relaunch.
7) Budget & Timeline
Upgrade ist oft der planbarere Schritt (klarer technischer Scope). Relaunch ist eher ein Produktprojekt (Stakeholder, UX, Inhalte, Iteration) und dadurch schwerer fix zu kalkulieren.
8) Team & Ownership
Wenn Know-how fehlt oder Tech-Leads fehlen, ist ein großer Relaunch riskant. Ein Audit + Upgrade in Sprints stabilisiert zuerst und baut Wissen/Ownership auf.
3 pragmatische Wege aus der Praxis
Diese Pfade sieht man in echten Projekten am häufigsten – abhängig davon, wo Sie gerade stehen.
Sicherster Weg
Upgrade zuerst, Relaunch später
Erst Stabilität, Security und saubere Deployment-Basis schaffen. Danach Design/Content iterativ modernisieren.
- • schnellere Risikoreduktion
- • weniger SEO-Risiko
- • bessere Planbarkeit
Meist gebucht
Hybrid: Upgrade + gezielter Redesign-Scope
Upgrade inklusive Template-Modernisierung „bis zur Schmerzgrenze“ – aber ohne kompletten Content-Rebuild.
- • moderne UX, aber kein „Big Bang“
- • Content-Elemente / Module konsolidieren
- • Performance/SEO direkt mitziehen
Radikal
Relaunch komplett neu
Wenn Content, UX, Architektur und Governance ohnehin neu müssen – dann besser konsequent neu planen.
- • höchster Scope/Stakeholder-Aufwand
- • größte SEO/Migrationskomplexität
- • lohnt, wenn Strategie sich ändert
Was treibt Kosten & Aufwand wirklich?
Nicht der „Relaunch an sich“ ist teuer – sondern der Scope dahinter. Und beim Upgrade sind es nicht „nur die Core-Files“, sondern die Abhängigkeiten drumherum.
Upgrade-Kostentreiber
- • Anzahl & Komplexität individueller Extensions
- • Composer/Deployment-Modernisierung (falls Legacy)
- • Tests fehlen → mehr manueller Aufwand
- • Upgrade-Sprünge (v6→v13) → Breaking Changes
- • Integrationen (CRM/ERP/Suche) müssen migriert werden
Relaunch-Kostentreiber
- • neue Informationsarchitektur + Content-Neuaufbau
- • Designsystem + Komponentenbibliothek
- • Tracking/Consent/Analytics neu konzipieren
- • SEO-Migration (URLs, Redirects, Canonicals, IA)
- • Stakeholder-Schleifen + Abstimmung
Praxis-Tipp: „Kosten explodieren“, wenn beides vermischt wird
Der Klassiker: Man startet ein Upgrade – und unterwegs kommt „ach, wenn wir schon dabei sind…“ (neue Features, neues Design, neue Struktur, neues Tracking). Das kippt Planbarkeit. Besser: technisch stabilisieren und Design/Content als separaten Scope führen (oder als bewusstes Hybrid-Projekt mit klaren Grenzen).
Checkliste: Upgrade oder Relaunch in 15 Minuten bewerten
Wenn Sie 10 von 12 Punkten klar beantworten können, haben Sie meist schon ein deutliches Bauchgefühl – und eine rationale Grundlage.
Upgrade spricht eher dafür, wenn…
- □ Content-Struktur ist okay und kann bleiben
- □ URLs sollen möglichst stabil bleiben (SEO)
- □ Individuelle Extensions sind wertvoll & sollen weiterleben
- □ Team will schnell Security & Wartbarkeit verbessern
- □ Design/Frontend kann iterativ modernisiert werden
- □ Governance/Backend-UX kann schrittweise optimiert werden
Relaunch spricht eher dafür, wenn…
- □ Seitenbaum & Inhalte müssen grundsätzlich neu strukturiert werden
- □ neues Designsystem + neue UX ist gesetzt
- □ viele Legacy-Hacks/Alt-Extensions sollen komplett weg
- □ Plattform/Architektur soll sich ändern (z. B. Headless)
- □ Content wird ohnehin neu erstellt / konsolidiert
- □ Stakeholder sind bereit für Iteration & Abstimmung
Wenn Sie unsicher sind: Audit = kürzester Klarheits-Booster
Ein kompaktes Audit liefert Ihnen eine Entscheidungsvorlage (Risiken, Aufwand S/M/L, Roadmap) und verhindert die typischen Eskalationen. In 5–10 Tagen wissen Sie, ob „Upgrade-first“, „Hybrid“ oder „Relaunch“ sinnvoll ist.
FAQ: Relaunch vs. Upgrade
Typische Fragen, die in Projekten sehr oft kommen.
Kann man ein Upgrade „wie einen Relaunch“ nutzen? ›
Ja – aber nur mit klaren Grenzen. Wenn Upgrade + neues Design + neue Features + neue Inhalte gleichzeitig passieren,
steigt das Eskalationsrisiko stark. Besser: Upgrade + gezielte Modernisierung (Hybrid) oder Upgrade-first.
Ist ein Relaunch immer teurer als ein Upgrade? ›
Meist ja – weil Relaunch ein Produkt-/Organisationsprojekt ist. Es gibt aber Fälle, in denen die Altbasis so teuer ist,
dass ein sauberer Neubau wirtschaftlicher wird. Entscheidend ist: Scope & Abhängigkeiten.
Was ist das größte Risiko beim Relaunch? ›
SEO/Tracking-Migration und Scope-Creep („wenn wir schon dabei sind…“). Außerdem unterschätzen Teams oft,
wie viele fachliche Entscheidungen (Inhalte, Struktur, Freigaben) im Relaunch stecken.
Wann ist „Upgrade-first“ die beste Strategie? ›
Wenn Security/EOL, Release-Chaos oder Wartungskosten akut sind. Mit einer stabilen Basis können Sie danach
Design/Content iterativ verbessern – ohne dass jedes Deployment ein Risiko wird.
Upgrade oder Relaunch – lieber kurz klären, statt Monate zu verlieren
Wenn Sie möchten, schauen wir gemeinsam kurz auf Ihre TYPO3-Version, Extensions, Ziele und Timeline – und wählen den Weg, der Budget, Timing und Risiko sauber im Griff behält.
Unverbindlich · vertraulich · auf Wunsch mit NDA/AVV