Kurz und einfach erklärt
Jede große Fassung eines Programms für Websites bekommt nur eine Zeit lang Updates. Danach gibt es keine Korrekturen mehr, auch nicht für die Sicherheit.
Der Beitrag nennt die Enddaten für häufige Programme. Er zeigt auch, wie viel Zeit Sie für einen Wechsel brauchen.
Die Website läuft am Stichtag einfach weiter. Darum merkt man das Ende oft nicht.
Wir führen für jede Website eine Liste mit Programm, Fassung und Enddatum. Den Wechsel planen wir früh genug ein.
Ein Shop merkt nichts davon, wenn seine Hauptversion aus der Herstellerpflege fällt. Der Warenkorb rechnet weiter, der Checkout nimmt Bestellungen an, das Fehlerprotokoll bleibt leer. Was an diesem Tag endet, steht nicht im Shop, sondern im Kalender des Herstellers: Für diese Version erscheinen danach keine Korrekturen mehr, auch keine sicherheitsrelevanten. Für die drei quelloffenen Systeme, die neben den Shopsystemen die meisten deutschen Auftritte tragen, liegen die Daten fest und öffentlich vor - der 30. April 2026 (TYPO3 GmbH) für TYPO3 v12, der 13. Oktober 2026 (Joomla! Project) für die reguläre Fehlerbehebung in Joomla 5.x und der 9. Dezember 2026 (Drupal-Release-Zeitplan) für Drupal 10. Drei Enddaten in einem einzigen Jahr, und keines davon erzeugt von selbst eine Meldung im Betrieb.
Das Wichtigste in Kürze
- TYPO3 v12 verliert am 30. April 2026 (TYPO3 GmbH) die reguläre Pflege. Sicherheitskorrekturen gibt es danach nur noch über das kostenpflichtige ELTS-Programm, längstens bis zum 30. April 2030 (TYPO3 GmbH).
- Bei Joomla 5.x endet die reguläre Fehlerbehebung am 13. Oktober 2026 (Joomla! Project). Danach folgt ein Jahr mit reinen Sicherheitskorrekturen, das am 12. Oktober 2027 (Joomla! Project) ausläuft.
- Drupal 10 erreicht am 9. Dezember 2026 (Drupal-Release-Zeitplan) das Ende seiner Lebensdauer. Der Zeitplan hält ausdrücklich fest, dass nach diesem Datum keine neuen Releases (Drupal-Release-Zeitplan) dieser Reihe mehr erscheinen.
- TYPO3 v13 LTS wird bis zum 31. Dezember 2027 (TYPO3 GmbH) regulär gepflegt. Wer jetzt von v12 dorthin springt, kauft damit rund fünfzehn Monate Ruhe - der nächste Termin steht schon fest.
- Ein Versionssprung braucht Vorlauf: Bestandsaufnahme, Freigabe aller Erweiterungen, Testlauf auf einer Kopie, Wartungsfenster. Sechs Monate vor dem Enddatum fällt die Entscheidung, nicht die Umsetzung.
Was aus der Pflege fallen im Betrieb bedeutet
Hersteller quelloffener Systeme veröffentlichen ihre Lebenszyklen als Kalender, nicht als Zusage im Einzelfall. Jede Hauptversion bekommt beim Erscheinen zwei Daten mit auf den Weg: das Ende der regulären Pflege und, falls vorhanden, das Ende einer Nachlaufphase. Bis zum ersten Datum korrigiert der Hersteller Fehler jeder Art - Funktionsfehler, Fehlverhalten im Zusammenspiel mit neuen Laufzeitfassungen und Sicherheitslücken. Nach diesem Datum verengt sich der Kanal oder er schließt ganz. Was dabei nie passiert: eine Meldung im Shop. Kein Hinweis in der Oberfläche, kein Eintrag im Protokoll, kein fehlgeschlagener Auftrag. Der Betrieb bleibt exakt so, wie er am Tag davor war.
Genau daraus entsteht die Verwechslung, die diesen Beitrag nötig macht. Ein Aktualisierungslauf, der meldet, dass keine neuere Fassung vorliegt, sieht von innen aus wie „alles aktuell". Er bedeutet in Wahrheit nur, dass für diese Reihe nichts mehr erscheint. Beide Zustände sind ununterscheidbar, solange niemand nachschlägt, bis wann die eingesetzte Hauptversion überhaupt noch beliefert wird. Die Sicherheitsupdates laufen still ins Leere, und der erste Hinweis darauf kommt in aller Regel von außen: aus einer Schwachstellenmeldung, aus einer Anfrage des Versicherers oder aus einem Vorfall.
Drei Zustände, die im Alltag verwechselt werden
Der Kalender: welches Datum für welche Version gilt
TYPO3 führt seine Daten maschinenlesbar in einer öffentlichen Schnittstelle. Für v12, die in vielen gewachsenen Auftritten noch läuft, steht dort der 30. April 2026 (TYPO3 GmbH) als Ende der Pflege durch die Community und der 30. April 2030 (TYPO3 GmbH) als Ende des verlängerten Supports. Die Nachfolgereihe v13 LTS erschien im Oktober 2024 und wird bis zum 31. Dezember 2027 (TYPO3 GmbH) regulär gepflegt, der verlängerte Support endet am 31. Dezember 2030 (TYPO3 GmbH). Die aktuelle Reihe v14 LTS kam am 21. April 2026 (TYPO3 GmbH) heraus, wird bis zum 30. Juni 2029 (TYPO3 GmbH) gepflegt und ist über den verlängerten Support bis zum 30. Juni 2032 (TYPO3 GmbH) abgedeckt. Wer die Wahl hat, springt darum nicht auf v13, sondern gleich auf v14: Der Aufwand ist derselbe, der gewonnene Zeitraum ist eineinhalb Jahre länger.
Drupal arbeitet anders. Der Release-Zeitplan des Projekts koppelt das Ende einer Hauptversion an das Erscheinen der übernächsten. Drupal 12 wird in der Woche des 7. Dezember 2026 (Drupal-Release-Zeitplan) veröffentlicht, und in derselben Woche endet die Lebensdauer von Drupal 10 - am 9. Dezember 2026 (Drupal-Release-Zeitplan). Dass der Zeitplan dazu ausdrücklich festhält, es werde danach keine neuen Releases (Drupal-Release-Zeitplan) von Drupal 10 mehr geben, ist der entscheidende Satz: Anders als bei TYPO3 gibt es hier keine gekaufte Verlängerung, die den Termin nach hinten schiebt. Bereits benannt ist auch, dass 10.6.0 (Drupal-Release-Zeitplan) die letzte Nebenversion der Reihe ist. Wie so ein Ende im Rückblick aussieht, zeigt Drupal 7: Der Support endete am 5. Januar 2025 (Drupal-Release-Zeitplan), Jahre nachdem das Datum bekannt war.
| System und Hauptversion | Reguläre Pflege bis | Danach noch Korrekturen bis |
|---|---|---|
| TYPO3 v12 | 30. April 2026 (TYPO3 GmbH) | ELTS bis 30. April 2030 (TYPO3 GmbH) |
| TYPO3 v13 LTS | 31. Dezember 2027 (TYPO3 GmbH) | ELTS bis 31. Dezember 2030 (TYPO3 GmbH) |
| TYPO3 v14 LTS | 30. Juni 2029 (TYPO3 GmbH) | ELTS bis 30. Juni 2032 (TYPO3 GmbH) |
| Drupal 10 | 9. Dezember 2026 (Drupal-Release-Zeitplan) | danach keine neuen Releases (Drupal-Release-Zeitplan) |
| Joomla 5.x | 13. Oktober 2026 (Joomla! Project) | Sicherheitskorrekturen bis 12. Oktober 2027 (Joomla! Project) |
| Joomla 6.x | 17. Oktober 2028 (Joomla! Project) | Sicherheitskorrekturen bis 16. Oktober 2029 (Joomla! Project) |
Joomla trennt beide Phasen sauber und nennt sie auch so. Für die Reihe 5.x endet die reguläre Fehlerbehebung am 13. Oktober 2026 (Joomla! Project), die Phase mit ausschließlich sicherheitsrelevanten Korrekturen am 12. Oktober 2027 (Joomla! Project). Die Reihe 6.x, seit dem 14. Oktober 2025 (Joomla! Project) verfügbar, folgt demselben Muster: reguläre Fehlerbehebung bis zum 17. Oktober 2028 (Joomla! Project), Sicherheitskorrekturen bis zum 16. Oktober 2029 (Joomla! Project). Ein viertes System gehört in dieselbe Liste, auch wenn sein Zeitplan nicht in derselben Form maschinenlesbar vorliegt: Wer Contao betreibt, führt dessen Reihen im selben Register mit; die Wartung für Contao folgt derselben Logik aus Enddatum, Vorlauf und Wartungsfenster.
Zwischen kein Support und verlängerter Pflege
TYPO3 ist das einzige der drei Systeme mit einem eigenen, kostenpflichtigen Programm für die Zeit nach der Community-Pflege. Es heißt Extended Long Term Support und liefert Sicherheits- und Kompatibilitätskorrekturen für eine Reihe, die offiziell nicht mehr betreut wird. Der Hersteller beschreibt den Umfang so: bis zu drei Jahre (TYPO3 GmbH) fortgesetzte Unterstützung für jede Organisation, für offizielle Partner bis zu vier Jahre. Gebucht wird in Abschnitten von jeweils ein Jahr (TYPO3 GmbH), wobei zwei oder drei Abschnitte auf einmal möglich sind. Das ist kein Ersatz für einen Versionssprung, sondern eine bezahlte Verlängerung der Entscheidungsfrist - sinnvoll, wenn der Sprung inhaltlich vorbereitet ist, der Termin aber nicht in die Saison passt.
Die Security-only-Phase bei Joomla ist etwas anderes, auch wenn sie ähnlich klingt. Sie ist Teil des regulären Zyklus, kostet nichts und beginnt automatisch, wenn die Fehlerbehebung endet. Was in dieser Phase fehlt, sind Korrekturen an Funktionsfehlern und Anpassungen an neue Laufzeitfassungen. Genau das wird im Shopumfeld schnell zum Problem: Kommt eine neue PHP-Fassung, wird die alte Reihe nicht mehr angepasst, und der Versionssprung hängt plötzlich am Fahrplan der Laufzeitumgebung statt am eigenen. Wie sich diese zweite Frist planen lässt, steht im Beitrag zum Umgang mit PHP-Endterminen.
Das Enddatum ist nicht der Termin - der Vorlauf ist es
Aus dieser Rechnung folgt für 2026 ein unbequemer Befund. Wer im September 2026 noch auf TYPO3 v12 steht, hat das Enddatum bereits überschritten und befindet sich entweder im verlängerten Support oder im ungepflegten Betrieb. Wer Joomla 5.x einsetzt, hat bis zum Ende der Fehlerbehebung noch gut zwei Wochen und danach zwölf Monate mit Sicherheitskorrekturen - das ist der Vorlauf, mehr nicht. Und wer Drupal 10 betreibt, hat bis zum harten Ende noch rund zweieinhalb Monate. Drei Systeme, drei sehr unterschiedliche Dringlichkeiten, ein gemeinsamer Nenner: Die Entscheidung hätte im Frühjahr fallen müssen.
Warum ein ungepflegtes System teurer ist als der Sprung
Die Kostenrechnung eines aufgeschobenen Versionssprungs sieht auf dem Papier gut aus: keine Projektzeit, keine Testläufe, kein Wartungsfenster. Sie ändert sich, sobald man die Gegenseite dazunimmt. Das Ausnutzen bekannter Schwachstellen ist inzwischen der häufigste Einstiegsweg in Unternehmensnetze und liegt bei 31 % (Verizon) der ausgewerteten Vorfälle mit ermitteltem Erstzugang - vor dem Diebstahl von Zugangsdaten. Und die Behebung dauert: Bis eine als kritisch geführte Schwachstelle vollständig geschlossen ist, vergehen im Median 43 Tage (Verizon). Diese 43 Tage setzen voraus, dass es überhaupt eine Korrektur gibt. Für eine Version ohne Herstellerpflege ist der Zähler unendlich.
Die Gegenseite ist dabei deutlich schneller als der Betrieb. Zwischen der Aufnahme einer ausgenutzten Schwachstelle in den einschlägigen Katalog und ihrer massenhaften Ausnutzung liegen im Median fünf Tage (Verizon). Gleichzeitig werden nach Zahlen des Bundesamts für Sicherheit in der Informationstechnik täglich durchschnittlich 119 (BSI) neue Schwachstellen bekannt. Eine ungepflegte Hauptversion nimmt an diesem Rennen nicht mehr teil - sie steht still, während der Katalog wächst. Was dagegen hilft, ist kein zusätzlicher Schutzwall, sondern ein Kalender, der den Sprung erzwingt, bevor der Zustand eintritt. Wie der laufende Abgleich zwischen Meldung und eigener Fassung aussieht, beschreibt der Beitrag zum Umgang mit Schwachstellenmeldungen.
System und Hauptversion
Je Auftritt das System, die laufende Hauptversion und die genaue Nebenversion. Ohne diese drei Angaben lässt sich kein Enddatum zuordnen, sondern nur vermuten.
Enddatum der Pflege
Das Datum aus der Herstellerquelle, nicht aus der Erinnerung. Bei TYPO3 steht es in der öffentlichen Schnittstelle, bei Drupal und Joomla im veröffentlichten Zeitplan.
Vorlaufmarke
Eine zweite Marke drei bis sechs Monate vor dem Enddatum. Sie markiert den Zeitpunkt der Entscheidung und gehört in denselben Kalender wie die Wartungsfenster.
Freigabe der Erweiterungen
Für welche Zielfassung ist jede eingesetzte Erweiterung freigegeben? Der Sprung entscheidet sich am schwächsten Glied, nicht am Kern des Systems.
Laufzeitumgebung
Die Fassung der Skriptsprache hat ihre eigene Frist und läuft unabhängig vom System. Beide Fristen gehören nebeneinander, sonst kollidieren sie im selben Quartal.
Zuständigkeit und Nachweis
Je Frist eine benannte Person und ein Protokolleintrag mit Datum und Entscheidung. Ohne Nachweis bleibt später nur die Rekonstruktion aus der Erinnerung.
Die Laufzeitumgebung verdient dabei einen eigenen Satz, weil ihre Frist die des Systems regelmäßig überholt. Jede Reihe der Skriptsprache wird zwei Jahre lang (The PHP Group) vollständig unterstützt und danach zwei weitere Jahre (The PHP Group) ausschließlich mit kritischen Sicherheitskorrekturen versorgt. Vier Jahre also, und dieser Takt läuft unabhängig davon, welches CMS darüber liegt. Wer beide Kalender nebeneinander legt, sieht sofort, welche Quartale doppelt belastet sind - und verschiebt eines der beiden Vorhaben, bevor sie im selben Wartungsfenster landen.
Was das Gesetz zum Unterstützungszeitraum sagt
Seit dem Cyberresilienzgesetz ist der Unterstützungszeitraum nicht mehr nur eine Frage der Herstellerkultur, sondern eine rechtliche Größe. Die Verordnung schreibt für Produkte mit digitalen Elementen einen Zeitraum von mindestens fünf Jahren (Amtsblatt der EU) vor und verlangt, dass sein Ende dem Käufer beim Erwerb genannt wird, wobei der Monat und das Jahr (Amtsblatt der EU) genügen. Für quelloffene Systeme, die ohne kommerzielle Absicht bereitgestellt werden, gelten Ausnahmen; für die Erweiterungen und Themes, die ein Betreiber dazukauft, gilt das in aller Regel nicht. Die praktische Folge ist dieselbe: Das Enddatum wird zu einer Angabe, die man verlangen und dokumentieren kann, statt sie zu schätzen.
Unbeschadet Unterabsatz 2 beträgt der Unterstützungszeitraum mindestens fünf Jahre.
Für den Betrieb heißt das: Wer heute ein Erweiterungspaket oder ein Theme beschafft, fragt nach dem Ende des Unterstützungszeitraums und trägt die Antwort in dasselbe Register ein, in dem auch die Systemfristen stehen. Wie eng die beiden zusammenhängen, zeigt sich beim Sprung: Eine Erweiterung ohne Freigabe für die Zielfassung hält den gesamten Auftritt auf der alten Reihe fest. Der Beitrag zu den Lizenzfristen von Erweiterungen beschreibt diese zweite Fristenebene im Detail; das Register unten führt beide zusammen.
#!/usr/bin/env bash
# Versionsregister auswerten: abgelaufene Pflege und alles im Vorlauffenster melden
set -euo pipefail
REGISTER="/srv/wartung/versionen.csv"
# Spalten: auftritt;system;hauptversion;pflege_bis;vorlauf_tage;verantwortung
HEUTE=$(date +%s)
tail -n +2 "$REGISTER" | while IFS=';' read -r auftritt system version bis vorlauf wer; do
ende=$(date -d "$bis" +%s)
rest=$(( (ende - HEUTE) / 86400 ))
if [ "$rest" -lt 0 ]; then stufe="OHNE PFLEGE"
elif [ "$rest" -le "$vorlauf" ]; then stufe="VORLAUF"
else stufe="ok"
fi
[ "$stufe" = "ok" ] && continue
printf '%-11s %-24s %-9s %-7s %5d Tage bis %s %s\n' \
"$stufe" "$auftritt" "$system" "$version" "$rest" "$bis" "$wer"
done
Wie viel Vorlauf ein Versionssprung wirklich braucht
Der Aufwand eines Sprungs hängt weniger am Kern als an allem, was darum herum gewachsen ist. Ein Auftritt mit zwei Dutzend Erweiterungen, eigenen Vorlagen und einer Anbindung an die Warenwirtschaft braucht eine andere Planung als eine schlanke Installation. Was sich aber in beiden Fällen gleich verhält, ist die Reihenfolge: Erst steht der Bestand, dann die Freigabelage, dann der Testlauf, dann der Termin. Wer diese Reihenfolge umdreht und mit dem Termin beginnt, bekommt regelmäßig einen Sprung, der am Abend vor der Freigabe an einer einzigen nicht portierten Erweiterung scheitert.
- Bestand je Auftritt aus der laufenden Installation ausgelesen: System, Hauptversion, Nebenversion, Fassung der Laufzeitumgebung.
- Enddatum der Pflege je Hauptversion aus der Herstellerquelle notiert, mit Datum des Abgleichs und Fundstelle.
- Vorlaufmarke gesetzt - drei bis sechs Monate vor dem Enddatum, abhängig von der Größe des Auftritts.
- Freigabelage je Erweiterung geprüft: Gibt es eine Fassung für die Zielversion, und wird sie noch gepflegt?
- Eigene Vorlagen und Anpassungen auf harte Abhängigkeiten zur alten Reihe durchgesehen.
- Sprung zuerst auf einer Kopie gefahren; wie eine solche Testumgebung sauber aufgesetzt wird, gehört zur Vorbereitung dazu.
- Regressionslauf über die tragenden Wege - Katalog, Warenkorb, Checkout, Rechnungsstellung -, wie im Beitrag zu Tests nach Updates beschrieben.
- Rücksprungpunkt gesichert und einmal wiederhergestellt; ein ungeprüfter Backup-Stand ist kein Rücksprungpunkt.
- Wartungsfenster außerhalb der Hauptsaison gelegt und mit allen Beteiligten abgestimmt.
- Entscheidung, Datum und Verantwortliche protokolliert, damit der Nachweis später ohne Rekonstruktion vorliegt.
Zwei Punkte aus dieser Liste werden am häufigsten übersprungen. Der erste ist die Freigabelage der Erweiterungen: Sie entscheidet über die Machbarkeit und wird trotzdem oft erst im Testlauf geprüft. Der zweite ist der Rücksprungpunkt. Ein Sprung über eine Hauptversion hinweg ändert das Datenbankschema; ohne getesteten Rückweg ist der Abbruch keine Option mehr, sobald die Migration begonnen hat. Beides kostet vorher eine Stunde und nachher ein Wochenende.
Vier Wege, wenn das Datum näher rückt
Springen
Der Regelfall. Auf die nächste gepflegte Hauptversion wechseln, und zwar auf die jüngste, nicht auf die nächstliegende. Bei TYPO3 bedeutet das heute v14 LTS statt v13 LTS: derselbe Aufwand, ein um eineinhalb Jahre längerer Zeitraum. Der Sprung gehört in ein geplantes Wartungsfenster mit vorbereitetem Rückweg, nicht in eine Nachtaktion nach einer Schwachstellenmeldung.
Verlängern
Nur bei TYPO3 möglich und nur als Zeitkauf. Der verlängerte Support liefert Sicherheits- und Kompatibilitätskorrekturen für die alte Reihe, während der Sprung vorbereitet wird. Sinnvoll, wenn der Termin fachlich feststeht, aber in die Hauptsaison fällt. Nicht sinnvoll als Dauerzustand: Das Enddatum des Programms ist ebenfalls gesetzt.
Umziehen
Wenn der Sprung an einer Erweiterung scheitert, die es für die Zielversion nicht mehr gibt, und kein Ersatz in Sicht ist. Dann steht die Frage nach dem System selbst an. Das ist das teuerste der vier Verfahren und braucht den längsten Vorlauf - gerade deshalb gehört die Entscheidung an den Anfang und nicht ans Ende der Frist.
Absichern
Die Zwischenstufe, wenn nichts davon sofort möglich ist. Zugänge einschränken, den Verwaltungsbereich abschirmen, Sperrregeln vor die bekannten Schwachstellen legen und die Erreichbarkeit engmaschig im Monitoring führen. Das verschafft Wochen, keine Jahre, und ersetzt den Sprung nicht.
Der Regelfall. Auf die nächste gepflegte Hauptversion wechseln, und zwar auf die jüngste, nicht auf die nächstliegende. Bei TYPO3 bedeutet das heute v14 LTS statt v13 LTS: derselbe Aufwand, ein um eineinhalb Jahre längerer Zeitraum. Der Sprung gehört in ein geplantes Wartungsfenster mit vorbereitetem Rückweg, nicht in eine Nachtaktion nach einer Schwachstellenmeldung.
Nur bei TYPO3 möglich und nur als Zeitkauf. Der verlängerte Support liefert Sicherheits- und Kompatibilitätskorrekturen für die alte Reihe, während der Sprung vorbereitet wird. Sinnvoll, wenn der Termin fachlich feststeht, aber in die Hauptsaison fällt. Nicht sinnvoll als Dauerzustand: Das Enddatum des Programms ist ebenfalls gesetzt.
Wenn der Sprung an einer Erweiterung scheitert, die es für die Zielversion nicht mehr gibt, und kein Ersatz in Sicht ist. Dann steht die Frage nach dem System selbst an. Das ist das teuerste der vier Verfahren und braucht den längsten Vorlauf - gerade deshalb gehört die Entscheidung an den Anfang und nicht ans Ende der Frist.
Die Zwischenstufe, wenn nichts davon sofort möglich ist. Zugänge einschränken, den Verwaltungsbereich abschirmen, Sperrregeln vor die bekannten Schwachstellen legen und die Erreichbarkeit engmaschig im Monitoring führen. Das verschafft Wochen, keine Jahre, und ersetzt den Sprung nicht.
Welcher Weg der richtige ist, entscheidet sich an zwei Fragen: Wie lange trägt die eingesetzte Reihe noch, und wie weit ist die Freigabelage der Erweiterungen? Sind beide Antworten bekannt, ist die Entscheidung in einer Sitzung getroffen. Fehlt eine davon, wird aus der Entscheidung ein Projekt. Für den Fall, dass die Frist bereits überschritten ist und eine Meldung ins Haus steht, gilt der kurze Weg über den Notfall-Support - er ersetzt aber keine Planung, sondern kauft nur Zeit.
Was davon in den Wartungsvertrag gehört
Ein Versionsregister, das nur beim Onboarding gefüllt und danach nicht mehr angefasst wird, ist nach zwölf Monaten wertlos. Nebenversionen wandern, Erweiterungen kommen hinzu, die Laufzeitumgebung wird vom Hoster angehoben. Deshalb gehört der Abgleich in den laufenden Takt: einmal im Monat der Bestand gegen die Installation, einmal im Quartal die Enddaten gegen die Herstellerquellen. Beides sind kurze Vorgänge, wenn sie regelmäßig stattfinden, und ein Projekt, wenn sie zwei Jahre liegen bleiben.
Im Wartungsvertrag lassen sich diese Punkte benennen, ohne dass daraus eine Fristzusage wird: der monatliche Abgleich, die Vorlaufmeldung an eine benannte Adresse, das reservierte Wartungsfenster im Quartal und der dokumentierte Stand je Auftritt. Wer mehrere Systeme betreibt, führt eine Liste statt vier - die Fristen von TYPO3, Drupal und Joomla unterscheiden sich im Datum, nicht im Verfahren. Ein Blick in die Leistungsübersicht zeigt, welche dieser Posten fest im Takt laufen und welche fallweise beauftragt werden.
Stiller Zustand
Der Auftritt läuft weiter, die Korrektur kommt nicht mehr. Von innen und von außen ist das nicht sichtbar, bis die Lücke ausgenutzt wird.
Kettenwirkung
Eine Erweiterung ohne Freigabe für die Zielversion hält den gesamten Auftritt auf der alten Reihe fest - und damit auch alle anderen Bausteine.
Zwei Kalender
System und Laufzeitumgebung haben getrennte Fristen. Liegen sie im selben Quartal, wird aus zwei planbaren Vorhaben ein unplanbares.
Schemawechsel
Ein Sprung über eine Hauptversion ändert das Datenbankschema. Ohne geprüften Rücksprungpunkt ist der Abbruch ab der Migration keine Option mehr.
Nachweislast
Versicherer und Prüfungen fragen nach dem Zustand zum Vorfallzeitpunkt. Ohne Protokoll aus dem Register bleibt nur die Erinnerung.
Saisonlage
Das Enddatum fragt nicht nach dem Weihnachtsgeschäft. Fällt es in die Hauptsaison, muss der Sprung davor liegen - oder der Zeitkauf davor entschieden sein.
Der Nachweis ist dabei mehr als Formsache. Nach einem Vorfall ist die erste Frage, ob das System zum Zeitpunkt des Vorfalls noch vom Hersteller beliefert wurde. Ein Register mit Datum, Fassung und Entscheidung beantwortet sie in einer Minute; ohne dieses Register wird daraus eine Rekonstruktion aus Rechnungen und Erinnerungen, die niemandem gefällt. Dieselbe Frage taucht in Ausschreibungen auf, in Prüfungen und in jedem Gespräch über eine Cyberpolice. Sie kostet nichts, solange die Antwort gepflegt wird.
Der nächste Schritt
Der Einstieg ist eine einzige Zeile je Auftritt: System, Hauptversion, Enddatum der Pflege, Vorlaufmarke, zuständige Person. Für die meisten Bestände ist diese Liste an einem Vormittag fertig, und sie beantwortet sofort die Frage, welche Auftritte in den nächsten zwölf Monaten einen Sprung brauchen. Danach folgt die Reihenfolge: zuerst die Auftritte, deren Enddatum bereits überschritten ist, dann die mit Enddatum im laufenden Jahr, dann der Rest. Wer wissen will, wie so eine Übernahme im Bestand abläuft, findet die Schritte in der Preisübersicht und in einem kurzen Gespräch schneller als in jeder Aufstellung.
Quellen und Studien
Verwandte Artikel
Serverumzug ohne Bestellverlust: Ablauf für Shops
Resolver liefern alte DNS-Antworten teils 1 bis 3 Tage weiter aus. So zieht ein Shop um, ohne Bestellungen, Cronjobs oder Zahlungsmeldungen zu verlieren.
Hoster oder Wartung: Wer im Shop was aktualisiert
Wo die Zuständigkeit des Hosters endet und die Wartung beginnt: eine Matrix über alle Schichten des Shops, Fragen an den Hoster und klare Übergabepunkte.
Supportende im Unterbau: Betriebssystem und Datenbank
Debian 11, MariaDB 10.6 und MySQL 8.0 sind 2026 aus der Pflege gefallen. So erfassen Sie Distribution, Datenbank und PHP und planen die Sprünge mit Vorlauf.