Aber wie sieht es mit dem Umstieg von bestehenden Installationen aus?

Diese Frage ist in der Tat gar nicht so einfach zu beantworten.
Man könnte sie zunächst reduzieren auf die Motivation, also: WARUM würde man überhaupt umsteigen wollen und den Releasewechsel auf sich nehmen?

Die vielen Faktoren, die hier hineinspielen, lassen sich im Wesentlichen in drei Bereiche unterteilen:

a) Sicherheit: Wenn für die bestehende Installation keine Sicherheitsupdates mehr bereitgestellt werden, dann ist es ohne Wenn und Aber allerhöchste Zeit für den Releasewechsel. Details hierzu finden Sie unter www.bitmotion.de/LTS

b) Sonstige Zwänge: Verschiedene technische Gründe können dazu führen, dass das vorhandene Release nicht mehr weiterverwendet werden kann. Beispiele sind Versionswechsel im Hosting-Unterbau (z.B. PHP-Version), aber etwa auch verwendete TYPO3-Extensions, deren Support für sehr alte Versionen eingestellt wird.

c) Verbesserungen und Neuerungen: Starke positive Motivation kommt oft aus dem, was das jeweilige neue Release eigentlich ausmacht, nämlich Dinge wie neue oder optimierte Funktionen, zukunftssichereres Innenleben sowie verbesserte Benutzerfreundlichkeit.

Die grundlegende Entscheidung, die individuell bewertet werden muss, ist:

• Habe ich ein eher statisches System und eine Modernisierung gibt mir wenig Wert, so versuche ich tendenziell, große zeitliche Abstände zwischen den Releasewechseln zu haben. Idealerweise kombiniere ich denn irgendwann dann doch notwendigen Umstieg dann gleich mit einem Relaunch.
• Gilt mein Interesse jedoch einem ständig möglichst aktuellen TYPO3 (z.B. um Update-Stau zu vermeiden, um immer den besten Leistungsumfang zur Verfügung zu haben, oder um stattfindende Erweiterungsentwicklungen immer möglichst zukunftssicher zu realisieren), so sind die verbleibende Fragen eher im Bereich „Wann nach Release macht der Umstieg für mich Sinn?“, „wie führe ich ihn am besten durch?“ bzw. „Kopple ich den technischen Umstieg an inhaltliche Neuerungen?“

Ablauf und Aufwand

Nun ist es auf der anderen Seite wichtig zu verstehen, wie solch ein Releasewechsel eigentlich vonstatten geht und wieviel Aufwand dies bedeuten könnte.
Schauen wir uns den „Releasewechsel“ also einmal etwas genauer an – was ist da zu tun? Man könnte hier vereinfach in diese Bereiche unterteilen:

1. Austausch des Kernsystems (noch am ehesten vergleichbar mit einem „Word-Update“) samt Anpassung aus die daraus direkt entstehenden Veränderungen.
2. Aktualisierung der Erweiterungsmodule, z.B. durch Update eines vorhandenen öffentlichen Moduls auf eine Version, die mit dem neuen TYPO3 kompatibel ist (oder falls eine solche Version nicht verfügbar ist: Austausch und Umbau auf ein völlig anderes Modul mit passender Funktionalität), aber auch: Aktualisierung der selbstentwickelten Module auf das neue TYPO3. Generell darf nicht unterschätzt werden, dass mit zunehmendem Alter eines Moduls ein „mit minimalen Mitteln im neuen TYPO3 lauffähig machen“ immer aufwändiger und ineffizienter wird – ggf. kann daher für einzelne Module eine Neuentwicklung ratsam sein.
3. Modifikationen in Konfiguration und Vorlagen („TYPO3-Integration“) – Dies umfasst oft viele kleinere Anpassungen, kann aber auch umfangreich sein – z.B. beim Austausch des verwendeten Vorlagensystems („Template Engine“) und daher ggf. auch teilweise automatisiert ablaufen.
4. Nicht zu vergessen ist auch, dass die sorgfältige Qualitätssicherung abzustimmen ist und nicht zuletzt auch, dass oft im Zuge des Releasewechsel auch Änderungswünsche adressiert werden.

Was bedeutet dies nun für den Aufwand? Schlechte Nachrichten: Es bedeutet vor allem, dass er viel schwerer abschätzbar ist als eine Neuentwicklung. Und nie ganz klein sein wird, mit mehreren Tagen muss man immer rechnen – je nach Alter und Komplexität der Installation auch deutlich mehr.

Übrigens wird man diese Umstellung nur in Ausnahmefällen am „lebenden Objekt“ durchführen (verbunden mit Offline-Zeit); bei allen ernsthaften Websites wird man alle Vorbereitungen auf einer Kopie des Echtsystems durchführen, testen, und diese Kopie dann zum Echtsystem machen.

Zusammenfassung: Typische Strategien

a) Immer das aktuelle Release verwenden
+ Modernste Features und Benutzerfreundlichkeit
+ Aktuellste Technik
+ Zugriff auf modernste Erweiterungsmodule
+ Bugfix-Support nicht nur für Security-Bugs

b) Release bis zum Ende des öffentlichen Supports verwenden
+ Seltenere Releasewechselprojekte
+ Keine Kosten für kostenpflichtige Supportverlängerung

c) Release bis zum Ende der kostenpflichtigen Supportverlängerung verwenden
+ Sehr seltene Releasewechselprojekte
– Releasewechsel dann aber sehr aufwändig

d) Releasewechsel an Relaunch koppeln
+ Wirtschaftlichste Alternative (falls anwendbar – je nach Relaunch-Strategie)
+ U.a. gut, da mit dem Relaunch ohnehin oft Dinge obsolet werden, die man sonst aufwändig auf das neue TYPO3 aktualisiert hätte

Zum Schluss noch einige Worte zur Zeitplanung: Wir raten generell dazu, etwas Zeit nach der Erstveröffentlichung einer neuen LTS-Version vergehen zu lassen. So ist bei Veröffentlichung Anfang April z.B. das dritte Quartal ein guter Zeitraum. Bitte beachten Sie aber auch, dass viele Anwender auf diese Idee kommen könnten – also sprechen Sie besser frühzeitig mit Ihrer Agentur.
Und wie immer gilt: Bitte vergessen Sie auch nicht den ggf. entstehenden Zeitbedarf z.B. für redaktionelle Überarbeitung, Tests und sonstige Abstimmung – bedenken Sie also auch frühzeitig die Urlaubsplanung etc. auf Ihrer Seite!